AlastairC

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.

WCAG 3 December 2024 Update & Thoughts from the Co-Chairs

2024-12-11T00:00:00Z

Introduction

The Accessibility Guidelines Working Group (AG) has updated the W3C Accessibility Guidelines (WCAG) 3 Working Draft. This post presents an overview of this update as well as AG co-chairs thoughts on the standard’s direction.

The December 2024 update includes three guidelines that were used to explore how WCAG 3 might be structured:

These guidelines are still developing and need a lot more work before they are ready to use. The AG would like feedback from you on whether the content organization and the labels (guidelines, foundational requirements, supplemental requirements, and assertions) make sense.

Key questions for you to consider when reading the 3 developing guidelines:

Does this overall approach help you understand what needs to be done to make content accessible?
How can it be improved?

The update also includes changes to the conformance section such as the overall approach to conformance and Section 3.1.1 Only accessibility-supported ways of using technologies. You may notice that explanatory content from previous versions is no longer in WCAG 3. This content has been moved to the Explainer for WCAG 3, which was also updated.

Key question for you to consider when reading the conformance section:

Do you have concerns about the direction conformance is moving?

We publish twice a year to give you visibility into the working group progress and an opportunity to give feedback. We welcome constructive comments on the direction conformance is developing. We recommend reading this post, the conformance section, and the explainer before sending feedback.

Should you wish to provide feedback after reading, please file a GitHub issue or send an email to public-agwg-comments@w3.org (comment archive). Please create 1 GitHub issue or send 1 email per topic – it makes our work much easier which leads to faster standards creation.

Caveats

These may seem dull but these pointers are really important to remember.

The majority of this draft is still Exploratory. Even the most mature portions have only just moved into the Developing stage of our content maturity process. We expect them to remain in Developing for a while.

What does that mean? It means this draft content will change.

The Accessibility Guidelines Working Group wants public feedback on WCAG 3 early and often.

Remember:

This WCAG 3 draft doesn’t replace WCAG 2. WCAG 2 is used around the world and will still be required by different countries for a long time to come.
Public feedback is an important part of the W3C process and the Accessibility Guidelines Working Group (AG) takes the comments we receive seriously.
If you want to learn more about WCAG 3, please read the WCAG 3 Introduction.

Do not use this draft content as a standard or revise your accessibility program and goals to meet the contents written in this draft. We are not there yet! If anyone tells you otherwise, they are uninformed or lying.

WCAG 3 Structure

From here on, the content reflects the co-chairs thoughts about the direction this draft is taking. Not all AG members may agree but we hope it gives insight into the general direction and progress made.

The proposed structure relies on Guidelines broken out into Requirements and Assertions. AG will be discussing including Recommendations.

Guidelines

Guidelines are written as user-centered outcome statements to make them easy to understand. These had been called Outcomes before and these were at various levels of detail. This draft clarifies the structure of Guidelines and Requirements.

Guidelines are organized into groups based on what is typically tested by that guideline. POUR (perceivable, operable, understandable, and robust) is an excellent way to teach guidelines but many people reorganize WCAG 2 Success Criteria (SC) to facilitate testing. The Web Accessibility Initiative (WAI) plans on building a tool that tags WCAG 3 requirements and allows users to reorganize them by POUR or other tags.

Requirements

Requirements are comparable to Success Criteria. AG changed the name so they are easily distinguishable as the required portion of this standard. Requirements can be tested with repeatable results, though just like in WCAG 2, the requirements may need manual testing and educated judgement.

Requirements are further divided into:

Foundational Requirements – These requirements present core needs that must be met to support people with disabilities. These may be met by authors, operating systems, browsers, or assistive technology but they must be met. AG expects the list of Foundational Requirements will be similar to A & AA WCAG 2.2 with additional support for disabilities not included there. For example, AG is exploring requirements that only apply to specific languages or writing systems. These requirements would include conditions and a plan for internationalization.
Supplemental Requirements – These requirements may include meeting a higher threshold than the Foundational requirements (think enhanced color contrast in WCAG 2) or they may best apply in specific situations.

Assertions

Assertions have been discussed in previous drafts and continue to be an important part of WCAG 3. When making a conformance claim, assertions would allow the writer to state that they used a process to improve or verify accessibility such as using an accessible design system, assistive technology testing, usability testing, or plain language testing.

We are still working out how assertions will fit. For this draft they are included under Guidelines but they may be moved into their own section as we are finding that the same assertion covers multiple guidelines. You can read more about Assertions in Section 5.3 of the WCAG Explainer.

Recommendations

The group will be discussing adding in recommendations. Recommendations are best practices that improve accessibility but are not reliably testable. These have some overlap with Assertions and the group will need to spend time discussing this option and and trying these out before making a decision. You can also join the discussion about recommendations on GitHub.

The Goldilocks Organization Problem

One of the complexities in WCAG 2 is that a single sentence SC includes layers and layers of complexity. That makes the SC hard to write and hard to understand. We are attempting to break the complexity out into separate parts and create a structure that helps readers understand when to use each part. The challenge is finding the best balance between testability and complexity.

As we worked through this, decision trees became very helpful for the group. We have included some decision trees in this draft to get public feedback.

From a chair perspective, we don’t think the current organization is quite right though we do think it is on the right track. Some items we think need more work include:

Moving the details that support testing out of the How To documents and Methods and back into the normative document.
Refining decision trees by writing more examples.
Trying out decision trees that include all the Requirements, Assertions and Recommendations that could support the guideline. In the current draft the decision trees only include the Foundational Requirements.

WCAG 3 Conformance

The AG has decided that:

“The most basic level of conformance will require meeting all of the Foundational Requirements. This set will be somewhat comparable to WCAG 2.2 Level AA.

Higher levels of conformance will be defined and met using Supplemental Requirements and Assertions. AG will be exploring whether meeting the higher levels would work best based on points, percentages, or predefined sets of provisions (modules).”

This short statement reflects a lot of research and testing to narrow down the approach. As a reminder, this is still in draft. The AG will spend the first half of next year working on the guidelines. The AG may, after testing, decide against this approach but this is the direction we will be moving until we prove it doesn’t work.

Like WCAG 2, WCAG 3 will have a set of core requirements and an extra set of requirements. Unlike WCAG 2, conformance levels won’t map directly to those sets. The most basic level of conformance to the standard will be the Foundational Requirements plus some subset of the Supplemental Requirements and Assertions.

AG will be exploring whether the author should select which Requirements and Assertions to meet in order to reach a certain number based on points or percentages OR whether AG will create modules of related content for authors to meet based on certain criteria. For example, a module about plain language may be more important for educational materials than for other types of materials.

As an example of how this might work, the most basic level of conformance (Bronze perhaps) might ask that content meets all the Foundational Requirements and 10% of the Supplemental Requirements OR all the Foundational Requirements and a plain language module. It is worth noting that many plain language requirements are being worked on as Foundational, rather than Supplemental requirements or assertions. However, some will likely fall into the optional grouping.

WCAG 3 can only recommend conformance to its own technical specification. It will be up to governments to write that conformance into law. One of the biggest risks of the proposed approach is that the legal standard will simply point to the Foundational Requirements, mimicking WCAG 2. However, the AG deemed that risk less severe than the risk that entire groups of people with disabilities would be left out if the conformance model gave authors the ability to choose which requirements to meet without constraints.

Accessibility Supported

WCAG 2 includes the concept of accessibility supported and conforming alternate versions but in our experience they rarely comes up in conversation outside the working group.

In WCAG 3, we are working to make these ideas much more visible. WCAG provides guidance for authors, not operating systems, browsers, or assistive technology. That said, whenever publicly available user agents like these are able to support accessibility requirements it reduces the burden on the author.

In WCAG 2, the AG does not write guidance that user agents already support. There is no criteria for visible pointers because pointers are typically visible. The challenge with this gap is that when new technologies are developed, there is no complete list of criteria for new technology to meet. We are exploring the idea of using the decision trees in part to allow WCAG 3 to age gracefully by providing a list of criteria that user agents and new technologies can use to support accessibility. If user agents meet WCAG 3 guidance, authors could then focus on not breaking that support rather than building it in. Next Steps

AG will spend the next 6 months focusing on moving all the guidance to the developing stage. This will include removing some guidance that needs additional research and looking for research partners willing to conduct that research. At the same time, we will be working to refine the structure in this draft and continue to address difficult topics such as third party content and complex, rapidly updating content.

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

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