AlastairC

Starting in Accessibility is like the Hype Cycle

2026-10-21T00:00:00Z

My brain loves to draw comparisons across fields, especially if they are visually based. The Gartner hype cycle was created in the '90s to represent the maturity, adoption, and social application of specific technologies.

The thing is, I see quite a similar curve when people get into accessibility. Looking back, I think I went through this myself.

Most people know very little about accessibility to start with, unless they have a friend of relative with a disability they know well.

There is some triggering event, which could be meeting someone with a disability and seeing how they use technology. It might be training. I got a message on LinkedIn today thanking me for sparking their interest and getting them into accessibility, which is lovely to hear.

But, once someone dives into the topic there is a certain zeal that people often have. You might hear sentiments such as "make everything accessible!", "Why are people ignoring this?!", "anyone against accessibility must be evil!" (despite the fact they themselves didn't know about it until quite recently).

After a few months of fighting the good fight but not really getting anywhere, they enter the "trough of disillusionment", becoming frustrated and possibly burnt out. "It's so hard!", "no-one listens to me about this!".

Hopefully, and this is something we can help with, people get to what I would call the "zen of enlightenment". Understanding that there is more work than can be done, but progress is better than aiming for perfection. Every little win makes life easier for some people. If we focus on the most important things, prioritise, we can make a difference.

As someone who's run a lot of training, I try to help people past the trough of disillusionment as quickly as possible. I think that's something we could all look out for and assist with.

WCAG process for assigning levels

2026-09-15T00:00:00Z

This post is my own opinion and observations. I'm not writing this with my AGWG co-chair hat on, although I can't really get away from that being a major part of my perspective.

How provisions are assigned to a level is an important topic. Provisions means "success criteria" in WCAG 2, and "requirements" in WCAG 3. It does depend on the conformance approach. For example, if there is one level then it is an in/out discussion. If there are multiple levels it would need more mechanisms to categorise them.

In WCAG 2 the A, AA and AAA levels were used to signal importance, i.e. the things at level A were more important than level AA. In practice A and AA got smooshed together because they were both required by regulators, but that wasn't a forgone conclusion when WCAG 2.0 was released. In the conformance section of WCAG 2 it says that AAA is not recommended for compliance in regulations, and regulators took that on board. The group has no say over how the standard is used by regulators, but levels were a "hook" they could use to decide how much of the standard to require.

Consensus process

In WCAG 2 the level was determined by consensus of the group (as in, Accessibility Guidelines Working Group). The participants of the group are people with disabilities, people from accessibility testing companies, invited experts, and people from large W3C member organisations such as Microsoft, Google, and CVS Pharmacy.

With that consensus process, in the best cases, it was based what people could live with by discussing the details and balancing user-needs and author feasibility. In the worst case it would be the path of least objections. Anything at A or AA level had to be possible to do by any person or organisation across all possible scenarios. If it was a good thing to do but not possible in some scenarios, it would be put at the AAA level.

Principles

There were principles (recorded on the wiki).

whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can’t make content accessible)

whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)

whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week’s training or less)

whether the Success Criterion would impose limits on the “look & feel” and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors)

whether there are no workarounds if the Success Criterion is not met

Basically, the more important it was (across scenarios) to the user the higher the level, the more difficult/expensive it was to accomplish the lower the level.

However, even with principles there are many edge cases, the variety of digital interfaces and user-circumstances makes it impossible to apply a simple rubric.

An important factor I've not seen mentioned before is: If something is very good for the user in 90% of the cases, but irrelevant or bad for users in 10% of the cases, we can’t include that at the levels taken up by regulation.

If 10% of authors get sued over something that doesn’t help users it would undermine the use of the standard. Often we can create exceptions so it doesn’t apply to the 10%, but not always.

Regulatory uptake

There was a very, very long discussion on this for WCAG 2 in 2024. I’d like to highlight something I wrote there:

It is a stakeholder process, not a scientific one. Producing something that satisfies the various stakeholders can't be done by a pre-set formula. I think places like the EU parliament are looking for this kind of process! It means we have done the work of balancing user and industry needs which makes implementing regulations easier.

The difficulty is that if we only used a metric of what matters to users, WCAG would not be taken up by laws and regulations. Then it wouldn't be used by as many people. We’ve seen this dynamic repeatedly: An over-reach by an accessibility standard creates a push-back from industry, and regulators back-off from that standard.

A minor version of this is that some jurisdictions create exceptions to particular requirements, e.g. In some parts of Canada there are exceptions for live captions and audio description. The more that happens the less useful WCAG becomes because it is not a consistent standard internationally.

One of the key benefits of WCAG at W3C is that our group includes user-advocates and industry representatives (sometimes in the same person). We do the work of establishing the best requirement that can be achieved in practice. That is a key factor in the success of WCAG, why it gets taken up legally, and why so many people use it.

If that sounds bleak, my consolation is that we’re making progress on providing better guidance to regulators in WCAG 3, and better ways to integrate recommendations that go beyond conformance. These are really the key to having WCAG be enforced (and therefore seen by the most people) and get better accessibility advice in front of people.

I don't have comments on here, but there are posts on Linkedin or Mastadon that could be used for that...

WCAG 3 update - conformance

2026-09-10T00:00:00Z

Cross posted from Linkedin, and this refers to the Sept 10th 2026 WCAG 3 draft.

Overview

We are excited to share a new draft of WCAG 3 that includes an updated approach to conformance!

The Requirements for WCAG 3 include both:

facilitating adoption into law, regulation, or policy, and
motivating organizations to go beyond minimal accessibility requirements.

These two, slightly competing goals, have led the group to explore many (many, many) approaches to leveling and scoring within the conformance model. Only two of the many possibilities have been published for more consideration. Neither have provided both the flexibility and support for harmonization that the group desires. Harmonization refers to international regulation around accessibility adopting requirements based on the same core standard. The goal of harmonization is to make it easier for everyone to meet and adopt accessibility practices, particularly when working across regulatory environments such as the United States, Canada, China, and the European Union.

The conformance model in this draft changes the approach from trying to fix everything within conformance to balancing flexibility and harmonization by adding reporting tiers alongside conformance.

In this draft, conformance is only a single level. The requirements included in this level are comparable to WCAG 2.2 A & AA, though there are additions to better support people with low vision, cognitive, and auditory disabilities. Every requirement will be tagged so it fits within a reporting tier based on the highest predicted impact, without taking context into account. These tiers lead up to and beyond conformance and can be used for reporting or potentially, compliance. Regulators could, in theory, choose to enforce a higher tier in certain situations such as for public sector, educational or healthcare digital products.

Every tier below conformance is an optional reporting tier that builds up to Conformance. Every tier above Conformance shows a commitment to creating more accessible experiences. The higher tiers include assertions about content-related-processes such as usability testing and assertions about organization-related-processes such as training. They also include supplemental requirements.

Background on the conformance change

Thank you to everyone who has provided feedback on previous conformance proposals. We read the issues filed and commentary online when we find it. We appreciate thoughtful, constructive feedback in any form. We do not appreciate false marketing that misleads people into thinking WCAG 3 will be here in the immediate future. Please continue to work towards meeting WCAG 2.2 A & AA and encourage others to do the same! WCAG 3 is built on that and won’t be lowering those requirements.

Feedback from the public and from the Accessibility Guidelines Working Group led to the current change in approach. We realized that we had been trying to provide a mechanism to have a larger impact but were constrained by the narrow scope of what conformance allows. To understand this, it may be helpful to revisit some terminology within the context of WCAG 3.

Conformance refers to whether something satisfies the requirements listed within the guidelines. Conformance directly relates to the standard. Individual requirements may include exceptions or caveats, but conformance does not. Something is either conformant or it is not.
Compliance refers to how well something meets law, regulation, policy, contract, or procurement requirements. Compliance typically relates to regulation and policy. Compliance can include exceptions, time frames, and other caveats that conformance does not.

We often refer to conformance as the ruler and compliance as the rule that uses the ruler. The marks on a ruler do not change, but a regulator can require different target measurements for different scenarios and specify how much wiggle room is allowed when measuring.

Previous conformance models have tried to provide more flexibility within conformance (the ruler) to allow regulators flexibility while still promoting harmonization. This proposed approach steps away from that. It keeps conformance narrowly scoped to a single level that everyone can harmonize around but provides flexibility through tagging requirements for reporting tiers. We also intend to provide Notes (less formal publications, like the current WCAG-EM) to suggest ways to use this tagging in testing, reporting, and regulation.

Questions about this draft

For the Sept 10th 2026th draft:

Does this proposed conformance approach, which sets a single conformance level and uses tags to provide reporting tiers below and above that level, improve upon the conformance approach in previous drafts?
An alternate proposal in the Explainer uses the tags to generate a score above and below conformance. What pros and cons do you see for each approach?
In your role, how would you leverage reporting tiers leading to conformance or above conformance?

Next Steps

If you want to weigh in on the revised WCAG 3 conformance approach:

Read the Introduction to WCAG 3, the Conformance Section, and the alternate proposal in the Explainer.
To provide input, please file issues on GitHub. If you are unable to use GitHub, send email to public-agwg-comments@w3.org.

Remember: WCAG 3 is still in development and it will be a few more years before it is done. Focus on meeting WCAG 2.2 and disregard advertising claims that reference WCAG 3.

New website for AlastairC

2026-09-10T00:00:00Z

Welcome! After a decade or so of wanting to, I've finally updated the underpinnings of the site.

It's gone from Wordpress on a virtual server that I managed (not very well), to an 11ty built static site hosted on Netlify.

The design is pretty similar, with just a change of background picture, but there are a few other things:

Thanks to Zach Leatherman's "Base blog" it has automatic atom feed, a navigation widget, tags, and dark mode. I did cut-down the CSS and re-arrange things to my ancient coding skill's liking, but it was a great start.
Thanks to Marc Jenkins' Wordpress to 11ty migration advice all the blog posts are migrated, and should be redirected to the right place.
I removed a lot of old "pages" content which is of no use to anyone anymore. If you really want it, I linked to the web-archive version of it.
I still need to work out where to put large video files and reference them properly, so the presentations aren't quite whole yet.
No comments. Sorry, that didn't come across in the migration, although I do have them in an XML file somewhere. I might look into a front-end solution to linking up social media posts that reference the article, but it's not a high priority for me.

Any comments, questions, issues, please get in touch from one of the methods on the Contact page.

AI and Accessibility presentation

2025-11-27T00:00:00Z

I added a presentation on AI for good accessibility, but it's not a post, so I'm adding this post to make it more findable from my homepage!

WCAG 3 March 2026 Update

2025-09-04T00:00:00Z

The Accessibility Guidelines Working Group (AGWG) has updated the WCAG 3 working draft. It now includes initial Developing content for most of the requirements. These will evolve a great deal over the next few years. The draft also includes a proposed conformance model. The content of the working draft is not ready for use but it is ready for your comments!

The AGWG updates the WCAG 3 working draft every 6 months for public feedback. Public review and comment is an important part of creating the best possible standard. You can learn more about the draft by reading the WCAG 3 Introduction. The draft includes questions for public feedback but as co-chairs, we would particularly like feedback on the following:

Are there user needs which are not covered? In other words, what requirements are missing?
WCAG 3 is more granular and uses “applies when” and “except when” statements. Do you find WCAG 3 requirements easier to understand than WCAG 2.2 success criteria? What do you suggest to improve readability?
We have introduced assertions. Would organizations you are associated with be comfortable stating that they completed a process such as a plain language review of their content, either in a public accessibility statement or an accessibility conformance report?
Could you use the proposed conformance model? What are the positive and negative points?

To provide feedback, please open a new issue in the WCAG 3 GitHub repository. Create a separate GitHub issue for each topic, rather than commenting on multiple topics in a single issue. If you are unable to use GitHub, please email your comments to public-agwg-comments@w3.org (comment archive).

Rachael, Alastair, & Adam (AGWG co-chairs)

This article was originally published on WhollyAccessible.org, but has been moved here for posterity.

WCAG 3 September 2025 Update

2025-09-04T00:00:00Z

The Accessibility Guidelines Working Group (AG) has updated the W3C Accessibility Guidelines (WCAG) 3 Working Draft. This update is a first step towards publishing a full draft at the Developing level. In this draft, the AGWG has moved many guidelines, requirements and assertions to Developing. Those that are still Exploratory have been kept in the Editor’s draft.

When you review this draft, please keep in mind that this is a partial list of draft Guidelines, Requirements and Assertions. This content can and will change.

As always, please start your review by reading the WCAG 3 Introduction. You will also find About this draft in WCAG 3 helpful.

The question everyone is likely asking is “When will WCAG 3 be complete?” We are working towards a schedule that will be available at the end of this year or early next year along with the next publication. You can follow the WCAG 3 Timeline for more detailed updates.

If this is the first post from the co-chairs you’ve read, the more detailed post from last December may also be helpful.

Rachael, Alastair, & Chuck (AGWG co-chairs)

This article was originally published on WhollyAccessible.org, but has been moved here for posterity.

WCAG 3, increment or overhaul?

2025-06-23T00:00:00Z

It's charter time for the Accessibility Guidelines Working Group, well, in 6 months, but we have to start the planning well in advance!

The charter (see the last charter) defines what we work on, and to some degree how we work on it. A question the group is considering is what approach to take to the next 2 years of work.

In the last charter we agreed to go full-steam ahead on WCAG3, an overhaul of the guidelines. That's going reasonably well, and we're tracking the plan.

A question has been raised though: Should we be incrementally updating WCAG 2 instead?

The question of starting point came up before our last charter point, I have a strong opinion on it, but I didn't have these points written down from then.

I have to take my "chair hat" off here, this is my personal opinion. The following points may influence other people (kinda the point of writing them down), but as chair I'll go with the group's decision.

I think that overhauling WCAG is necessary for the next version, not just to meet our goals, but there are several practical advantages compared to iterating on WCAG 2.

There are several options in the group discussion, but I'm focusing on whether we overhaul the whole thing, or go bit by bit from WCAG 2.

The concerns I have with an incremental approach from WCAG 2 are:

Cascade effect

Criteria in WCAG 2 have adjacent scopes, some even overlap in scope, therefore replacing some will cascade the re-writing across criteria.

Definitions also cascade across normative and non-normative text. Change a definition, the scope of all the criteria which use it can potentially change. A key definition that almost everyone wants to replace is "web page", which really doesn't work in some important scenarios. It's used explicitly in 11 criteria, and 'conforming alternate version', where the alternative has to be available from the page. If that changes, many things change across the spec.

A proposed addition to WCAG 2 is the concept (from WCAG 3) of assertions. Doing so would need some sort of system to integrate it into conformance, otherwise it's just extra content for people to ignore.

I'm not really sure how that could work in a WCAG 2.0 context, as the current model is pass/fail for each provision. Individual assertions were not something WCAG 3 was going to require by default (they would score towards a higher level of conformance).

A lot of the difficulty we had when updating to WCAG 2.1 and 2.2 was not being able to change the pre-existing text. We had to slot things into the current structure without changing other things. Therefore we had very careful additions only, with almost no changes to the existing text.

Overall, every change is likely to trigger other changes and take longer.

Repeated re-writing

Something I've learned from large website re-structuring projects is that re-structuring means re-writing. Often people want to "lift and shift", but when the content connects to each other, relies on certain things, it all needs review and revision.

I have a strong feel that cross-checking the whole at each increment is probably more work than doing it once across a fresh version. At least with a fresh version you can make lots of changes quickly as it is pre-publication.

Publication overhead

Assuming we wanted the incremental version to get to where the overhaul is going, it would take longer simply due to publication timescales. Publishing to a recommendation is around 6 months if there are no major objections or hold-ups.

I appreciate the W3C's thorough process, but for a spec that is used as one-whole thing (rather than modules), it does incentivize larger publications.

Local maxima problem

Sometimes you have to move through a design, past where it gets worse, to get to the better design. This concept is the "local maxima", probably an old concept but I noticed it in metrics-driven design by Joshua Porter.

I worry that patching in concepts from WCAG 3 into WCAG 2 would fall into that trough, adding complexity without as much benefit.

Marketing

Part of the success of WCAG 2 is that it has been referenced around the world by various laws, regulations, and legal cases. Those processes run even more slowly than the standards process. Getting them to move onto a (backwards incompatible) new version will take a lot. It needs to be a big push to an obviously better new thing.

An incremental update (that isn't simply a backwards compatible addition) is a difficult sell. It adds friction without the benefit of a new approach. From previous experience, legislators tend to wait for the next big thing.

Follow Up Questions: WCAG 3 CSUN Talk

2025-04-04T00:00:00Z

The Accessibility Guidelines Working Group chairs and staff presented “WCAG 3: The True Story!” at CSUN 2025. Due to time constraints, we were not able to answer all of the audience’s questions. We’ve posted the questions and answers below.

Q1 Research Accepted

You cited needing not just academic research. Does this mean peer review is not as much a concern for that research? Yes, I am thinking about APCA.

We are looking for research that:

Provides transparent research methodology and results,
Uses a methodology that makes sense for the research objectives, and
Presents unbiased evidence.

We recognize that well-done usability testing and other work can meet these criteria. While we value peer reviewed academic research, we will accept other research resources when they address the research questions.

The research question depends on the requirement under discussion. For example, we often need to know whether to include a requirement or not, so the research needs to establish that the requirement helps people with disabilities.

Some requirements, such as colour-contrast or target size, sit on a continuum or include tradeoffs. For some people, the larger the target size the better, but requiring large target sizes will impact how many items can be included in a certain space. This also impacts the feasibility of certain designs. It can also negatively impact low-vision users who zoom in a lot as they can’t fit as many controls on screen.

Research is helpful to establish where on the continuum is best for what proportion of users (knowing that some will always want the maximum). Then there is a process of working with other stakeholders (e.g. design teams, people who work on brand guidelines) to work out what is feasible and realistic. There is also the option of enabling customisation rather than changing the default appearance.

Because of all these factors, the type and amount of research needed will vary by the requirement.

Q2 AI Impact

Do you envision advances in AI as impacting any part of WCAG 3?

We assume it will have a large impact on how accessibility requirements are met. The structure we’re using allows for user-agents to meet requirements, so it shouldn’t require updates to the core guidelines when new technologies become widely available.

Q3 ARIA Use

How does the WAI Application pattern guide fit into the requirements? We are often pointed to that as the only way to meet a guideline in some cases.

Assuming this means the ARIA patterns, they are a way (a “method”) of meeting a requirement. They may not be the only way to meet something, but often they are a known-supported way to achieve something (e.g. tabs).

Q4 Conformance Reporting

Will conformance reports indicate if and where barriers may exist ? A more robust version of “comments” in the current VPAT?

The VPAT is not a W3C product. WCAG 2 doesn’t require conformance statements. Instead it presents the required parts of an optional conformance statement. That will likely be the same for WCAG 3. We haven’t defined the format of WCAG 3 conformance statements, but could certainly take input from other areas like VPAT and (EU) Public-Sector accessibility statements.

Q5 Web Based Documents

Would your web-only charter cover web-based documents such as PDFs?

WCAG 2.0 currently includes PDFs when they are at a URL, so are considered web-content. AG is designing WCAG 3 so that these will still be considered web based documents. The structure of WCAG 3 should also make it easier to apply requirements to non-web content, even though web technologies remain our focus.

Q6 Accessibility Needs

What have been the most challenging accessibility needs to incorporate into a written standard?

Requirements that rely on context. For example, some requirements require certain spacing to support reading but the spacing needed will vary based on the writing system used (Japanese, Arabic, etc.)

Q7 Improvements to WCAG 2

What high level aspects of WCAG 2.x were you looking to improve

The WCAG3 explainer outlines the goals, and as we already have WCAG2, that works to show what we’re trying to improve. This includes a desire to:

address more disability needs than WCAG 2,
incorporate publishing requirements and emerging technologies such as web XR (augmented, virtual, and mixed reality) and voice input,
facilitate maintenance, so that the new model will be more enduring over time as technologies evolve, and
include additional information about the ways web technologies need to work with authoring tools, user agents, and assistive technologies.

Q8 Scope

Is the scope of WCAG 3 only web, or is it being created to be applicable to native apps, documents and other technologies?

The scope, under the W3C is “web technologies”. However, we are taking an approach of having general user-requirements at the top-level, and it should be possible to use the framework and requirements and fill in other technology-specific methods that are not included as part of WCAG 3.

Q9 Number System

Are we maintaining the number system for the new criteria?

No.

Slightly longer answer: We do have numbers assigned to the sections which contain guidelines, but we do not intend to apply numbers to the specific requirements while writing the standard. There is a cognitive overhead in trying to remember or interpret the numbers, and as we go through the drafting process they would change often. When we are done, we will discuss possibly adding some type of number system back in.

Q10 Retrospective

What came out of the retrospective on monday, what were some of the themes discussed?

Most discussion was about how we work. There is a lot of parallel work being done right now so we need to coordinate effectively. All of the substantive discussions are public, for example, after the retro we ran a workshop/meeting to work on the replacement definition for web-page.

Q11 Informative Methods

You mentioned that methods are informative, is that a finalized decision?

Nothing is finalised, however, it is very likely that methods would be informative as they need to be updated regularly. Making methods normative would make it much harder to update, as it would have to go through a long publishing and review process.

Rachael, Alastair, & Chuck (AGWG co-chairs)

This article was originally published on WhollyAccessible.org, but has been moved here for posterity.

CSUN 2025 conference notes

2025-03-28T00:00:00Z

The CSUN ATC conference is one of the largest accessibility related conferences in the world. (It stands for "California State University in Northridge", the conference name is actually "Assistive Technology Conference".)

I'm going to give my impressions of the conference and talks in roughly chronological order, so read on if you are curious or just want links to lots of new accessibility resources.

I last went to the CSUN conference back in 2014 (roundup), so it's been a while. I have to admit that San Diego was a nicer location, but then we're here for the people, so a hotel in Anaheim isn't the end of the world.

Accessibility Guidelines Working Group

On the Monday we met to do a retro (how have we been working, can we improve etc.), and then discussed how to define "views". We need a unit of conformance for use in the guidelines and conformance statements, and web-page is getting increasingly difficult to use for this.

After a long discussion going through the pitfalls of the previous definitions (page and view), we ended up going with UI-context.

Keynote

Gabrielle Giffords was the keynote speaker, who after a very traumatic injury had to re-learn how to talk. It was run as an interview by her speech therapist who could also fill in some of the medical and therapeutic aspects. It was so popular that I ended up in an overflow room watching a big screen.

Accessibility in the AI ecosystem

Jenny Lay-Flurrie gave a little history, both of accessibility innovations (e.g. toothbrushes originally being invented for people with mobility impairments) and her own (starting at MS on Hotmail).

Microsoft's accessibility efforts use a hub and spoke model, where each division is responsible for accessibility, with a central team to support. The need to meet compliance (e.g. EAA deadline is 109 days away), but that is the floor, not the ceiling.

Training on accessibility is mandatory, and some is available publicly for free. But they like to go beyond that, for example, including options in games for people afraid of spiders, and she showed a slider that would reduce the realism of an in-game spider.

As per the title, there was a long section on how MS is using AI to improve their services. Part of that was for Be my eyes, who are using AI to answer questions through the Disability Answer Desk, and 70% of questions could be answered by AI, and more quickly.

Jenny pulled up a gnarly chart and challenged the audience to run it though a AI assistant to see what it came up with.

The image I fed into ChatGPT:

Chat GPT's output:

The chart shows Microsoft's Q1 FY25 Income Statement, highlighting revenue, costs, operating profit, and net profit.Revenue Breakdown:

Total Revenue: $65.6B (+16% YoY)
Major revenue sources:
Server (Azure, etc.): $22.2B (+23% YoY)
Microsoft 365 Commercial: $20.4B (+13% YoY)
Gaming (Xbox): $5.6B (+43% YoY)
Windows & Devices: $4.3B (0% YoY)
LinkedIn: $3.2B (+7% YoY)
Search (Bing, etc.): $3.2B (+7% YoY)
Other: $5.5B (+6% YoY)

Cost & Profit Breakdown:

Gross Profit: $45.5B (69% margin, +2pp YoY)
Cost of Revenue: $20.1B
Operating Expenses: $14.9B
Operating Profit: $30.6B (47% margin, +1pp YoY)
Net Profit: $24.7B (38% margin, +2pp YoY)

Expense Breakdown:

Tax: $5.6B
Other: $0.3B
R&D: $7.5B (12% of revenue, flat YoY)
S&M (Sales & Marketing): $5.7B (9% of revenue, flat YoY)
G&A (General & Administrative): $1.7B (3% of revenue)

The company achieved solid revenue growth driven by significant increases in Gaming (+43%) and Server (+23%) segments, resulting in strong operating and net profit margins.

That seems good, I couldn't spot any mistakes or misinterpretation.

There are also other things coming, like live audio description (in Seeing AI), and working with other companies to improve speech recognition for people with speech-impacting disabilities, and a "speak for me" project.

Avoiding the pitfalls of shift-left

Another Microsoft presentation, with three obviously knowledgeable and engaging speakers (Alli Hirt, Erin Lucas, Manika Malhotra). However, I struggled with it a bit. It's a very wide topic, so it was necessarily quite high level. I felt like I know that you need things like prioritization techniques, but without the detail on how to achieve those goals I didn't get much out of it.

Probably a good one for change-managers (or other managers), less so for practitioners.

Sustained web accessibility (design systems)

David Cox presented about design systems as a way to improve accessibility, but with some research and testing to see whether it actually has made a difference for companies with a design system.

It involved a good overview of when design systems should help (e.g. where you have large or multiple teams and have the budget to do it), and what success factors to look for.

It also included research (including a large spreadsheet) about how well some well-known design systems do, and how accessible the corporate homepage is. The correlation was not good, as in, a good design system wasn't a good predictor of homepage accessibility.

However, there are a lot of confounding variables, such as whether the people creating the homepage even use the design system!

Anecdotally, if we (Nomensa) are testing a UK Government website that uses the GDS components (properly), we either half the cost or increase the scope compared to a similar site not using the component system. If we have far fewer issues to find and report it simply doesn't take as long, and the design-system usage is a strong signal that will be the case.

Google keynote

This was a rattle through new and upcoming features of interest:

Live captions - can now include vocal emphasis and things for sound effects, and live transcribe can work offline.
Hearing aids - UX improvements such as making the battery info easier to find.
Android Lookout - reads out details of the real world, improved OCR, and guidance on framing for selfies. You can also go into a mode where you pick something you're looking for, wave your phone around and it helps you find it.
Talkback - added image descriptions with Gemini AI, for any image on your screen. It's automatic for unlabelled images (on the Pixel 9), or activate manually from any phone.
Contrast adaptions (Android 15) - can make it brighter, outline text, add a solid background, and preserve the colours of links.
Face-control (Chromebooks) - device face tracking as a pointer mechanism.
PDFs - scanned PDFs are automatically OCRed. They mentioned something about PDFs previously being rendered as canvas elements, and that is changing. However, I wasn't clear if that was for all PDFs, or just scanned and OCRed PDFs.
Read aloud (Chrome browser) - built into Chrome now on Chromebooks, coming to Mac and Windows soon.
Improved image descriptions (Chrome) - E.g. before it was "art, graphic", now "art, appears to be bowl of fresh fruits in a bowl".
Page zoom (Chrome on Android) - can now set text-size as well as (pinch to) zoom.
Google drive - Dark mode coming soon.
Maps - improved walking instructions, and a "lens" icon to show features around you such as ATMs.
Google Wallet - improved instructions for scanning IDs.

These and more at the Google accessibility resource hub.

Practical research

By Kavana Ramesh, UX researcher at Fable. The premise was that people are intimidated by including people with disabilities in research. It can be new, more complex, and you need to adjust methodology. There are organisational barriers, not just barriers for individuals, but the focus of this talk is the individual barriers.

There was a "build a burger" metaphor, which I didn't find that helpful, but injected a little fun. There was lots of good advice on running research with people with disabilities. The only area I might pick up on was a comment around "Make sure you allow the person to be the expert of their AT", which is true up to a point. However, there is a massive variety of expertise with assistive technology, and I would aim to included non-expert participants as well and you have to account for participants knowledge level when presenting results.

It's a small point in an otherwise good presentation.

WCAG 3, the true story!

This was the presentation I helped to give, with Rachael (Co-Chair), Chuck Adams (Co-Chair) and Kevin White (Staff Contact): WCAG 3 overview presentation. It isn't new content if you've been following along at home, but the talk was a chance to provide an overview and open up for questions.

We had quite a few questions which we answered live, and published responses as well.

Packaging accessibility (Amazon)

This talk by Shadi Abou-Zahra, Di Wu, Marilyn Hoss, and Chris Baldomero was talking about Amazon's push to less paper, less plastic, less friction, more accessibility.

As someone recently asked to evaluate packaging and hardware, it was interesting to see the approach was fairly similar, but they were able to include some user-research for certain things, such as how to include QR codes. For Blind and Low-Vision folks (BLV), paper instructions may not be at all useful, so getting to digital versions is key. Apparently a 20mm sized QR code with 8 raised areas (making a square) was the best way to guide people to the right instructions.

The presentation wrapped up with some useful guidelines for overall packaging and instructions, I don't know if the presentation will be available, but those guidelines will probably appear (in some form) as part of the EAA role-out.

When accessibility actively harms

This was essentially an accessibility auditor's howl of protest at weird thing developers have done when trying to make sites more accessible. The presentation is fairly self-explanatory, if you know what Grange Hill is.

There was nothing new from my point of view (having done or QAed 1000s of audits over 2 decades), but it was very amusing for me and at least three other Brits in the audience.

Digital accessibility legal update

There were a few legally oriented talks at CSUN, but Lainey Feingold's gets the appropriate keynote slot at the start of Thursday.

There's a good (captioned and signed) video of the legal update. It is US-centric, but even in Europe it's worth keeping tabs on the US situation as so much software and services come from the US.

My takeaways were that:

Despite all the problems with the current US administration, quite a lot of accessibility is baked into laws that would take time to remove, executive orders should not be able to affect that.
There's a lot of state and local laws/regulations that are still in effect.
A lack of enforcement (centrally) can have a big effect, as can Judges chipping away.
Some states have pretty high standards in their regulations, and typically companies work to the most stringent state's level so they can sell everywhere.

Overall, Lainey's presence and presentation is somewhere between a therapy session and a call to activism, and very welcome in the current climate.

Redefining Design - Accessibility as a Growth Opportunity

Pawel Wodkowski (from Atlassian but not speaking for them) wants to adjust how we talk to or encourage designers. Compliance doesn't work for a designer. They want to learn something new, something they haven't done before, and opportunity to grow.

It was an interesting presentation, I was already onboard with the premise, but he also shared some of the metrics they use internally to establish accessibility adoption across teams.

TV Accessibility - BBC

One of my favorite sessions, this was reporting on research, so a meaty topic with lots of detail.

The BBC conducted its first large-scale disability study to explore accessibility in TV applications, focusing on video-on-demand services and HTML5/JavaScript-based apps like iPlayer.

The research used a mixed-methods approach, including surveys, interviews, usability testing, and technical evaluations of how screen readers interact with HTML elements.

The two main groupings shown in the research were older participants (over 1,000), and people recruited specifically for having accessibility needs (over 100).

Content availability is the primary factor in service selection for both sighted and blind/low-vision users. However, people with a broad range of accessibility needs prioritized accessibility features more than older adults did. Device preference also varied, with older participants favoring smart TVs and those with accessibility needs more often using mobile devices and streaming hardware for better accessibility options.

Shared viewing experiences presented unique challenges, as accessibility needs sometimes conflicted. For example, settings often lacked flexibility, preventing simultaneous use of captions and audio descriptions. Users expressed frustration with inconsistent navigation, complex menus, and varying search interfaces across apps. Voice control was another barrier, with some users—especially those with strong accents—finding it unreliable, reinforcing exclusivity in design.

Screen reader support was inconsistent, with different models interpreting content differently. Testing across top-rated TVs and streaming devices revealed unpredictable results in announcing headings, lists, and landmarks, making TV navigation harder than on desktops or mobile devices.

In response, the BBC is developing accessibility guidelines tailored to TV interfaces, recognizing that traditional web standards like WCAG do not fully apply to this context. Their approach is built on three principles: understanding the audience, acknowledging TV-specific constraints, and collaborating with industry partners. These guidelines aim to provide practical solutions for developers, ensuring better integration of accessibility features across TV platforms. The BBC intends to publish these guidelines once they are fully developed, helping to create a more inclusive viewing experience for all users.

Testing Mobile Apps: Tools, Techniques and Best Practices

For these types of sessions I tend to just note the best tips I didn't already know, but the whole Testing Mobile apps presentation is available, thank you John Lilly!

iOS

You can turn on captions in the VoiceOver settings, which helps with sharing videos
Full Keyboad Acess doesn't play nicely with VoiceOver, one or the other. Android is ok for this. (I don't think I'd tried to use them together before!)
Testing for 200% size text: Set to the third notch from the end (this seems higher than my setting, I tested this a while back with screenshots and a pixel measure.)
Testing contrast: Using the Quicktime player to display on desktop can have a slight colour shift which can throw it off by 0.01. If it's close, stick with a screenshot.

Android

The main tip was to try the (free) Android Accessibilty Inspector. It's like a dev tools for Android apps. Gives info on what Talkback would announce. Also shows whether it is native or a webview.

I asked a question about how you adjust focus-styles in iOS and android, John replied that in android you're looking for the "on-focus" modifier, and change the visual style. In iOS you can change the global accent colour, but that only changes the default colour.

Wrap up

Overall CSUN is a great, quite intense conference (for a someone who's on the introversion end of the scale), which combined with jet lag made it really tiring. I had just about switched timezone on the day I left.

I'm not a big fan of the Anaheim area, it's basically a conference center and hotels next to Disney Land, so unless you're combining it with a Disney trip there isn't much to see or do locally. However, it seemed that Paul Adam was better at finding places to eat and things to do.

As you can tell from the copious notes above, there are so many good sessions I can't really complain! There are also booths from various companies where you can try things out. For example, I had a quick play with the built in screenreader, magnifier, and lazer-eye viewfinder on certain Sony cameras.