Accessibility Supported

[alastc]

“Accessibility Supported” is a term used in WCAG 2.x to mean:

"supported by users' assistive technologies as well as the accessibility features in browsers and other user agents"

It further defined

"the Web content technology is used must be supported by users' assistive technology (AT)".

Problem to solve

How does an author know that meeting a guideline will work in practice with user-agents that are used by real people?

(Related: On a larger scale, how do regulators know that meeting a conformance level will work for their public?)

Previous suggestions from the sub-group

WCAG 3 could:

• acknowledge the limitations and advantages of methodology-based testing;
• explicitly encourage third-party accreditation;
• discourage testing processes which are not validated by end-users;
• provide a conformance model that deems a documented testing processes as sufficient, or explicitly disavow such an approach;
• provide an example of ‘Accessibility Statements’ that can be used by organizations to detail the ‘accessibility supported’;
• provide strategies for determining the possible matrices of user agents (e.g. browsers) and assistive technologies (e.g. screen readers) to make the testing process easier;
• provide pointers on the ‘way to achieve Accessibility Supported’ of WCAG requirements;
• create a testing database with a basic set of test files and allow anyone to contribute additional test files for the database.

Questions to answer

Firstly: Do we need a similar concept in WCAG3, or is there another way?

See the pros and cons that the previous sub-group created (summary version).

Assuming we keep the concept in some form:

• Should AT testing be part of the methods / tests?
• Should conforming to a spec (e.g. HTML+ARIA) be sufficient?
• Should the concept apply to technologies (e.g. ARIA) or features (e.g. aria-live).
• What happens when a guideline is partially supported by user-agents?
  • What if a user-agent feature (that fulfills the guideline) is hidden or not well known. Who's problem is that to solve?
• How popular does an AT need to be in order to count as supported?
  • And how much responsibility is on the user to know what they should be using?
• An example is the use of CSS media features. Is it ok to assume users with a need (e.g. reduced motion) have that setting applied? These features can massively expand the level of testing needed if there are many variations of each page/thing.
• What if a particular technology does unexpected things? E.g. reader-mode drops certain content.
• Should a conformance claim include what assumptions were made about user-agents / accessibility support?
• How would this concept apply when the product conforming operates in a closed environment (e.g. kiosks, or intranets where staff have a particular set of AT they can use).
• How would an author (/ conformance claimant) know what AT people might use with their product? (And who is responsible for working that out? See also support baseline in WCAG-EM)

Next step

Plenty of work has been put into exploring the issues around accessibility support, what we need now is proposals for WCAG 3. The previous sub-group outlined some options, but there maybe other options we should consider.

If you have an idea or proposal for how this could/should work in WCAG3, please comment below.

There is a 2nd draft proposal about tying it to levels, and an alternate approach.

[mraccess77]

I think we need a similar concept. I wonder if an assertion at the outcome level could be an appropriate place for this - although this feels redundant and this is why I believe WCAG 2.x put it at a higher level under the conformance model requirements. The Methods/tests are related as it often comes down to the techniques and implementation used. I don't think conformance to the spec can be enough though as user agents don't always implement the spec fully or there is ambiguity - for example, the html form validation is different in different browsers.

[bruce-usab]

@mraccess77 by conformance to the spec are you meaning WCAG or markup validation or both? I agree that 2.x conforming content can still have accessibility barriers. Accessibility Supported (or not, in the 2.x context) can only mitigate the gap. IMHO that gap is small enough to be tolerable, and worth the benefit that non-SME can develop accessible code by following WCAG and do so without relying upon AT.

[mraccess77]

I was referring to implementing things in standard ways perhaps with the HTML or some other (e.g. ARIA) specification. For example, you might be able to use browser based x,y - but theoretically if that x,y doesn't work with any commonly used screen readers then it shouldn't be acceptable. I'm not saying it has to work with all or even multiple - but if it doesn't work with any commonly used ones then it seems like that technique is not accessibility supported and allowing it to meet WCAG is problematic. There are ARIA examples of this as well where x,y ARIA property is not sufficiently supported by any commonly used screen readers yet is in the ARIA spec as a way to do something.

[jspellman]

I don't think conformance to the spec can be enough though as user agents don't always implement the spec fully or there is ambiguity - for example, the html form validation is different in different browsers.

The problem is when AT implements the code differently, or there is a bug in an AT that has been outstanding for years. We had a use case from a member where they could not get a web app to work in JAWS and NVDA because of a long-reported bug in JAWS. Authors need some protection from AT that is out of their control. The subgroup thought that complying to the spec was the best we could do. Perhaps that could be a last resort, e.g. give authors a list of things to do to remediate the problem and if they have filed a bug that the AT has not fixed after a year (just for example) then they are not responsible. I like the idea of adding it to the accessibility statement so that users know that they did their best to work with the AT.

[bruce-usab]

I agree that WCAG conformance should be a safe harbor for authors.

[chaals]

I like @alastc's approach below - at a low level you can assume WCAG conformance is enough, at higher levels you need to actually check.

Because the relevant tools that people have, change over time. It's not obvious this group has the resources to track tools even in english, let alone the languages that the world relies on.

That means we can describe some kind of procedure that provides a high degree of certainty that what an author does is useful, but we're less likely to be able to maintain a checklist that includes those details.

[mraccess77]

In the US CVAA has this idea of nominal cost third party technology that is allowed. I could imagine with AI and tools that initially AI solutions may be available to meet but not affordable to many globally and thus meeting with AI enabled tools that are not available to some folks may not be a reliable way.

Meeting the spec as a safe harbor is good - but a safe harbor isn't required and so if you don't use that safe harbor then you may still need to meet accessibility supports for bronze.

[chaals]

the Communications and Video Accessibility Act?

I think it is helpful to provide a definition of something that has a sense of "if you don't manage to do at least this much, you very clearly failed to meet the minimum bar - thanks for playing. But we should be clear that's the entry point to the task of providing accessibility. Accessibility is not a simple binary proposition, even for one single user, let alone hundreds of millions with vary different situations, or even hundreds who might be expected to use a typical "long-tail" website.

I don't think we are in a position to provide a binary "this is good enough" statement, and we should be clear about that.

I think we are in a position to note that there are things that represent egregious failure if not dealt with, and for all requirements at any level it is important that we explain the impact on people with disabilities clearly.

Although I strongly object to us trying to directly write regulations, it is important to recognise regulators as being among out users, and provide them with clear guidance on how to use WCAG.

There are many different regulators. Policy makers that aren't strictly regulators such as HR guidance for the intranet of a large organisation has the same needs as a WCAG user. They have very different requirements, and set their own levels of how far something needs to go. An organisation that provides autonomy and work to people with intellectual disability will prioritise accessibility requirements differently from a manufacturing organisation with a number of blind staff, and neither are likely to settle for the priorities of a libertarian regional government setting rules for general public-facing services.

[MakotoUeki]

My understanding is that the concept of "Accessibility Supported" is about "specific features (ABC element or XYZ attribute) " of a technology, not the "Technology (HTML)" itself.

If a HTML technique (ABC element or XYZ attribute) is supported by JAWS, but not supported by a Japanese screen reader, we need to use an alternative technique which works with the Japanese screen reader to meet a Success Criterion.

Even if a sufficient technique is supported by an English screen reader, it doesn't always mean the technique is supported by a Japanese or any other language's screen reader. If the technique is not supported by a Japanese screen reader, we can't use it to meet the Success Criterion for a Japanese web page as it doesn't work for users.

That was why the concept of "Accessibility Supported" was introduced in WCAG 2.0 and WCAG 2.x can be used in different languages/countries where the levels of screen readers/ATs are different. Authors must use a technique which is supported by ATs in their languages/countries to meet a Success Criterion.

So we will need the similar concept in WCAG 3.

[GreggVan]

I think

• that some form of this will be required because we cannot rely on content to be directly accessible to all types, degrees, and combinations of disability. So we will need to rely on assistive technologies.
• it would be good if we could say exactly and precisely what we mean - rather than use something vague like "accessibility supported"
  HOWEVER
• AT is going to shift very quickly and I suspect if we get specific -- we will move from requiring outcomes to requiring techniques
• the desired outcome is indeed that it be usable by / work with assistive technology. What it takes to do that will change rapidly so saying what it takes today will be wrong before we release W3.
• but saying "works with AT and access features in user agents" (our desired outcome) has problem too
  1. what does user agent mean? (all? some? a particular set?) Ditto for assistive technology.
  2. if we want these to apply outside of browsers -- does that mean we need to drop user agents and stick to just AT? (the AT question above still applies -- but if we drop user agents, suddenly all web pages are going to be responsible for doing a LOT more that user agents now do)

Bottom line

1. If we want to apply outside of just web content - then we need to have three categories of W3 provisions
   1. Applies when there is a user agent
   2. Applies when you don't have a user agent
   3. Applies to both (with and without user agent)
2. The best (though problematic with regard to keeping it up AND having a provision that refers normatively to a non-normative document) method might be to
   • use accessibility supported and have a separate (normative?) document that states what that term means 'today'
   • OR
   • use accessibility supported with a specific definition in the guidelines - but update the guidelines periodically to reflect changes in technology, user agents and assistive technologies

NOTE: if we go with any approach we should note that as AT (and accessibility features in user agents) get better it will require LESS of authors in order for things to be accessible -- yet more and more people will have access. (e.g. no loss in accessibility). So the old definition of backward compatible (I.e. if it passes version 3.x it will also pass 3.x-1) cannot - and should not - be used. This is another good example of why we can't have the same backward compatibility requirement and work with technologies as the evolve -- in this case in the better direction

[alastc]

Hi Gregg,

Regarding this bit:

"then we need to have three categories of W3 provisions"

If we had an outcome such as "Views have a structure that helps users orient and navigate", e.g. using headings and landmarks, then I assume we'd need methods (or whatever the tech-specific provision is) along the lines of:

• Web (with user-agent): Sections or sub-sections of a view are identified with landmarks, headings or text.
• EPUB (with reader / user-agent): Page breaks are identified programmatically.
• General (no user-agent): A mechanism is available to navigate sections of the view.

Is that the kind of thing you had in mind?

[chaals]

If we want to apply outside of just web content ...

I would suggest that we solve the already very large and important problem for Web Content first. That's the core focus of W3C, it's now probably the single most impactful piece of accessibility work on the planet, and it's a big piece of work to take on even when "limited" in that way.

We should be mindful of how our work can be used outside that scope, but I suggest we should not be constrained by that.

[stes-acc]

I think in the end there is a never-ever resolved base conflict between two different expectations.

1. The end user expectation
   A piece of software is only accessible if all end users have a satisfying and "used to" experience with a given combination of code + content + user agent (UA) + assistive technology (AT). If there are issues, the software vendor is first made responsible for that.

2. The author/vendor expectation
   Software is already considered as accessible if code and content obeys to all HTML, ARIA etc. specs and WCAG guidelines have been followed what to do. If code has temporary deficiencies or/and UA/AT has issues that hinders a good end user experience (which is detected in testing which should be mandatory prerequisite in WCAG 3) this will be reported in extra documents (such as formerly VPATs) to inform about it (with all implications which will arise from that).

For complex controls not covered entirely by HTML / ARIA and modern app scenarios in Web, it is likely to be always in mode 2) because of different UA/AT heuristics and imperfections that inevitably will come up during testing. The devil is in the details.

Not sure how WWCAG already positions itself here. It would definitely help if reasons not being entirely in camp 1) or 2) are elaborated as part of the prep work for WCAG 3 Accessibility supported.

If WCAG 3 is all around expectation 1), it should be explicitly stated as part of WCAG 3 that AT vendors are in duty to harmonize their support effort and heuristic behavior in the interest of all users.

If WCAG 3 is supporting whole heartly 2) , a template report format should be developed that clearly states who to address for a given accessibility violation and the process to fill it out should be made mandatory.

[alastc]

(Chair hat off) I'm going to make a suggestion, partly so we have something to discuss / shoot down.

I've put this into a google-doc as an alternative review method.

Accessibility Supported Proposal

Tie accessibility supported to the levels (bronze/silver/gold), so that the responsibility for the author increases as the level increases. I'm assuming that methods are tech-specific requirements under outcomes.

• Bronze: Methods (tech-specific requirements) can assume that AT supports the requirement. E.g. screenreaders can use alt-text, voice-input can be assumed to work with ARIA set accnames.

• Silver: Methods can involve a level of UA / browser / AT testing to ensure that they work for the intended audience. The informative documentation may provide some level of compatibility information, but it would not be complete and responsibility would be on authors to ensure compatibility.

• Gold: Methods can require AT testing and / or usability testing in order to meet the requirement (e.g. an assertion).

So at a Bronze level, I can just keep to the spec for HTML / ARIA / ePUB specs and meet the requirements.

At Silver I need to think more about usage, work out what end-users are likely to be using and create an compatibility/AT list. (E.g. the GDS list) To test the method & outcome, it should be tested with that set of user-agents.

Gold would be similar to silver but requirements could go beyond that to usability-oriented testing.

[alastc]

I think an upshot of this approach would be that methods at bronze need to be generic, whereas at silver they would need to incorporate UA support material.

[chaals]

Another upshot is that we would be looking for lists like the GDS list referenced, and we would want them for different langauges as @MakotoUeki already pointed out.

I think we'll do better to make them "informative", and write the requirements without blessing a particular list, but we need to be serious about maintaining that information as well as we can, or finding out who can do that appropriately.

[chaals]

As a differentiation, something like

• Silver requires a justification some basic sets of software combination and use pattern work, e.g. browser+screen reader, browser and speech input, browser+magnifier at 400%
• Gold requires a record of user testing with combinations, and a statement on what disability barriers the content has overcome. Possibly asking for a minimum set that matches the requirement for silver, and with some flexibility over what else is done.

The reason I hesitate to enforce a atronger minimum set for gold is to avoid the situation where we solve all problems for one set of users, at the cost of not doing anything much for some other set - instead, it might be that enabling really good accessibility for any particular set of users means we do better overall. After all, there isn't a resource I can think of that everyone needs to access (most of those that leap to mind are contractually banned for users under 14, for example), and there is nothing to stop the very common resources from striving to do a very good job for a great variety of people.

I'd sort of like to ask for a statement on known barriers that are still in place. That would help focus work on accessibility enhancement "at the edge (of the client/server model)", or using overlays to actually improve things. But I suspect that's a pathway to nightmares of complexity so for now I'll leave the idea here without pushing for it.

[chaals]

Following @mraccess77's comment above, a further differentiation between silver and gold under this proposal could be restricting the kinds of tools that are required by the user, in claiming gold.

Using the example given, while it might be reasonable to accept the use of a known AI tool that effectively remedies content between the server and the user in a claim for silver, this might not be acceptable at gold where the requirement would be that the content provider has incorporated that functionality into the content itself.

[alastc]

Another upshot is that we would be looking for lists like the GDS list referenced, and we would want them for different langauges

How about we have 'tagging' for each method? E.g. (and making this up) a method for aria-expanded is tagged with JAWS '20, NVDA version X, and Dragon 15. Anything we know works is tagged with the version where it started working.

Obviously things can be added to AT and later stop working, but it could be a reasonable / feasible way of marking which methods work for what, especially if we can take suggestions from people in different regions.

Also, we could include information on how to create an AT/compatibility list, so an individual, organizational or regional can create a list for their use.

@chaals I think the other comments are good & useful, but more to do with what should go into each level rather than the accessibility supported concept?

[mraccess77]

One issue with just following the ARIA spec might be something such as the ARIA patterns that may assume keyboard usage on desktop. When a slider is used on mobile the slider needs to be created in a way that works with a mobile screen reader as the keyboard might not be available and adjustment for increment and decrement need to be available programmatically or as a separate controls.

[mbgower]

It's worth mentioning Enabling Interoperability for Assistive Technology Users. This is an effort to create testable methods to validate outcomes for ATs when using ARIA.

This is as opposed to the ACT rules, which develop a set of rules to have homogeneous results across automated checkers against HTML.

While I think the aria-at group is interesting, if we can confirm the degree that the accessibility tree is consistent across browsers, I believe that ACT will be a better way to improve testing for accessibility support without requiring AT testing.

[rachaelbradley]

Below is an alternate approach I proposed in the meeting.

It assumes that Bronze in WCAG 3 is comparable to A & AA in WCAG 2.
This focuses on accessibility supported and does not include additional criteria (example: repeatable results) we will use to assign levels.

Accessibility Supported Criteria for Outcomes

• Bronze: Outcome can be met and tested universally (meets some internationalization requirements)
• Silver: Outcome can only be met in certain environments
• Gold: Outcome is experimental or requires high cost assistive technology to meet

Outcomes could then migrate towards bronze as technology coverage increases.

[chaals]

I think the order here is upside-down: You might be able to claim you meet the outcome at a Bronze level if there is some technology that can make your approach work, but to claim you meet it at a gold level users can expect it to work on any "major" platform... for specific definitions of "major".

To @GreggVan 's point in a thread below, we should be publishing techniques that meet the gold level requirement - and we also have to describe what that means in some detail.

For example, there are IMHO 5 operating systems we should consider supporting. Windows, Android, MacOS and iOS all have screenreaders that integrate reasonably well into common browsers (we're focused on Web here - going beyond that makes this question much harder). I'm unfamiliar with the current state of Linux, although I know there are screen reader / braille line users who have Linux systems. I trust the WG can collect relevant information and then assess it.

Likewise we need to collect information for voice input, switch-based input, symbolic output, and different languages where for example there may be significantly lower usage of more expensive platforms if cheaper alternatives work well, and then we need to work out how we decide what is the threshold for "well-supported", and what is the difference if we only mean "some evironments"...

[alastc]

I'm not sure how much we can rely on 'universality'? Similar to my comment to Gregg, we'd have a very restricted set of methods at Bronze.

Also, I think I might be missing something for the 'only met in certain environments', does that mean the scenario of the website (e.g. education vs e-commerce) or the region (e.g. Japan vs Europe), or something else?

[GreggVan]

I think there is a misunderstanding of what accessibility supported means (at least what it meant in WCAG 2 and I assume we are not using the same term to mean something completely different here.) Accessibility supported did not have anything to do with testing webpages for performance. It only had to do with the techniques or methods used to meet the success criteria [Outcomes). When we propose a technique as being "sufficient" to meet a success criteria/outcome, we need to be sure that the techniques are accessibility supported. If someone uses one of our techniques, they can assume that it is accessibility supported. If they want to make up their own different way of meeting the success criteria, then they need to make sure that they novel approach to meeting the success criteria is accessibility supported. (For example, a company can't create some thing, and then invent their own API and expose the information through the API and then declare their content accessible. There are no assistive technologies that actually use their API.) In a lot of these discussions, I keep hearing things that make it sound like individual users or authors need to be testing their sites to see if they are accessibility supported. This is way outside of the capabilities of any, but the largest organizations. To test for a accessibility one would have to be very familiar with all of the different API's and technologies of all of the different assistive technologies and browsers as a working group, we can probably assemble this and we have in the past to explore and confirm that our own techniques are accessibility supported. But we should not have having to do accessibility support on their individual sites or we are going to wipe out the vast majority of all websites from being able to do this. G

…

On May 7, 2024, at 9:11 AM, rachaelbradley ***@***.***> wrote: Below is an alternate approach I proposed in the meeting. It assumes that Bronze in WCAG 3 is comparable to A & AA in WCAG 2. This focuses on accessibility supported and does not include rest of the criteria (example: repeatable results) we will use to assign levels. Accessibility Supported Criteria for Outcome inclusion in levels: Bronze: Outcome can be met and tested universally (meets some internationalization requirements) Silver: Outcome can only be met in certain environments Gold: Outcome is experimental or requires high cost assistive technology to meet Outcomes could then migrate towards bronze as technology coverage increases. — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXTECPN6EFDGTE4NFGTZBD4JPAVCNFSM6AAAAABDT3NMFSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNBTHE3DE>. You are receiving this because you commented.

[chaals]

I think that your explanation matches the meaning I see people discussing.

I agree, we should be describing techniques that work on the broadest range of platforms, because expecting the world to do this wthout a strong set of examples might mean we get very few doing it in practice.

IF individual authors choose to use a "novel" technique that relies on some capability we haven't already exploited in an "approved" technique, then there is some onus on them to do some testing. The more guidance we provide, and the clearer we are about why we adjudge that things "work", the easier that additional testing will be in general.

We also need to track changes in the platforms people use, and update the guidance we give. Tracking novel techniques and understanding why they are implemented can help us with that task.

[alastc]

When we propose a technique as being "sufficient" to meet a success criteria/outcome, we need to be sure that the techniques are accessibility supported.

As mentioned in the meeting, this is not the case internationally, and it is also not the case in practice. (See the summary from the sub-group.)

For example:

• The most popular screenreader Japan (PC-Talker) doesn't support a lot of HTML / ARIA, therefore a lot of our published techniques are not 'accessibility supported' there.
• Dragon still doesn't support the <input type="file">, so a perfectly valid bit of HTML (like in H32) doesn't work.
• Some ARIA patterns (usually a reliable way of passing Name, Role, Value) have mixed support even in common AT. E.g. VoiceOver with Safari doesn't properly support the details & summary elements.

The current approach doesn't work internationally, and doesn't have sufficient granularity to work for people on the ground trying to work out which things they can rely on.

I don't think anyone is suggesting that it should be necessary for individuals or small businesses to conduct significant AT testing on their site (i.e. anyone who's main job is not development/accessibility). However, we do need to acknowledge that at some point relying on specs and the current techniques is not sufficient to ensure compatibility with AT.

[mbgower]

Gregg, what you are saying makes lots of sense for assessing and adopting novel technologies or techniques. It’s supported by much of the front part of the content covered in https://www.w3.org/WAI/WCAG22/Understanding/conformance#accessibility-support. But it doesn’t make a lot of sense in regard to an author validating their conformance for a website.

For example, WCAG offers some examples of accessibility support statements. The first reads:

1. This conformance claim meets the accessibility support requirement based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z. This means that we were able to pass all of the success criteria for level A of WCAG 2.0 using these products.

It's fine to say ‘programmatically determinable and accessibility supported techniques were used’, but if authors don’t actually test sites, they have not validated that their code conforms.

And of course this interpretation ignores the realities of bugs. What does an author do where not all occurrences of a technique are done correctly? I believe one of the reasons 4.1.1 Parsing was created (in addition to prevent AT glitches when, historically, the AT interpreted malformed html) was to provide a place where malformed code could be reported. The argument for its removal was that poorly formed code could be reported by its result elsewhere, but that gets confusing when considering the reporting of AT problems.

There are years-old issues still open in our repo about this. For example, if I test a page and I can operate it properly by keyboard, I obviously pass 2.1.1. But if I turn on a screen reader and the keyboard no longer works, where do I report that? If I put that under 2.1.1, I’m being inaccurate, and I’ve arguably devalued my report in an assessment process, showing a keyboard failure where one does not exist for anyone except users of AT X.

[mbgower]

[The following response is from @GreggVan on May 12. He replied in the email thread which caused it to be added to the bottom of the discussion where it made no sense, so I am relocating. mg]

---

For example, WCAG offers some examples of accessibility support statements. The first reads:

1. This conformance claim meets the accessibility support requirement based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z. This means that we were able to pass all of the success criteria for level A of WCAG 2.0 using these products.
   It's fine to say ‘programmatically determinable and accessibility supported techniques were used’, but if authors don’t actually test sites, they have not validated that their code conforms.

I disagree. If the author uses techniques that we already have said are “accessibility supported” (because we don’t list any techniques that are not) then the author can rely on that. There is no need for them to question our testing to do it all over again - any more than if they tested is on one page - they would have to test it on every page they used it on. If it is - it is.

Now - if they don’t use one of ours and they make up a new technique - then they need to test that technique. But once tested they would not need to test every page with every piece of AT from then on either.

Finally, I would note that it is a good thing that this is true because only very large companies have the teams, expertise, and AT to test a new technique. So if this were not true we would have to remove all of these success criteria (outcomes) as being logistically impossible to do for most companies.

I think we need to be practical if we want these to be adopted and applied/required broadly and not just to a few very large companies with large expert teams.

[alastc]

Accessibility Support varies by level - 2nd draft proposal

This is an updated version of the proposal above, based on yesterday's discussion. There is also a Google doc version.

“Accessibility supported” should be tied to the levels (bronze/silver/gold), so that the responsibility for the author increases as the level increases. This assumes that methods are tech-specific requirements under outcomes.

The levels are assumed to follow previous conversations where Bronze would include things currently at WCAG 2.2 AA, and Silver/Gold build on that baseline.

Bronze

Methods (tech-specific requirements) can assume that AT supports the requirement. E.g. screenreaders can use alt-text, voice-input can be assumed to work with ARIA set accnames.

Bronze level Methods would be generic, following patterns/implementations from other specs such as ARIA.

Silver

Methods published by the working group at silver level would include some information about AT compatibility. For example, Method X is supported since Jaws v16, NVDA 2022, Dragon v15. This would be a tagging mechanism in the WCAG 3 content management system.

If authors use other methods to meet the outcome there would be a requirement for testing by the author (or other party).

The set of user-agents needed for that testing (and conformance) would be set by the author (or their regulator), with some informative guidance from the working group. That guidance would be to assess the common assistive technologies in your region, or by asking stakeholders (such as charities who support people with disabilities), or due to the environment (e.g. a corporate environment where only certain AT are supported).

If the set of user-agents for your conformance includes one(s) not covered by the working-groups information, there would be a requirement for testing. E.g. If you are in Japan and a method doesn’t include a key japanese screenreader, you would need to test it to rely on that method.

There should be a process where interested parties (e.g. an accessibility group in Japan) could add compatibility information to the WCAG3 methods.

The compatibility information should not be too detailed to make maintenance an arduous task. For example, once a particular feature is supported by a product (e.g. NVDA) it would be tagged with the version that first supported the feature (e.g. NVDA 2022.1). If it later drops support for that feature, the tag would be removed.

Exceptions

If there is one particular AT which has had a bug for more than 2 years, or will not update to support a feature that is supported by all the other AT in a conformance set, the author can claim an exception. I.e. that they conform by using a particular method, even though it isn’t supported by an assistive technology. The conformance claim must include information about known AT bugs.

Gold

Methods can require AT testing and / or usability testing in order to meet the requirement (e.g. an assertion). There would be no exception mechanism.

Authors point of view

At a Bronze level, I can just keep to the spec for HTML / ARIA / ePUB specs and meet the requirements. Those specs would be the basis of the more technical / AT oriented methods.

At Silver I need to think more about usage, work out what end-users are likely to be using and create a compatibility/AT list. (E.g. the GDS list). That way I can pick methods that are known to work, or create my own and test the method & outcome with that set of user-agents.

Gold would be similar to silver but requirements could go beyond that to usability-oriented testing.

Methods at bronze can be generic, whereas at silver they would need to incorporate UA support material.

For example, imagine that a new HTML element “tab-panel” starts to replace the ARIA-tabs pattern, the methods might be:

• Bronze: HTML method - Use a tabs component that follows the ARIA tabs pattern (via ARIA or tab-panel element).
• Silver: HTML method - “Use ARIA-tabs pattern (supported by X, Y, Z)
• Silver: HTML method - “Use HTML tab-panel element (supported by X, Y only)

Using this proposal to answer the questions from the introduction above:

• Should AT testing be part of the methods / tests?

  • No for bronze level.
  • Yes at Silver / Gold, although some methods could be used which are known-compatible.

• Should conforming to a spec (e.g. HTML+ARIA) be sufficient?

  • Yes, at bronze.

• Should the concept apply to technologies (e.g. ARIA) or features (e.g. aria-live).

  • Features.

• What happens when a guideline is partially supported by user-agents? What if a user-agent feature (that fulfils the guideline) is hidden or not well known. Whose problem is that to solve?

  • It will depend on the methods provided at each level.
  • It is the author's responsibility at Silver/Gold.

• How popular does an AT need to be in order to count as supported?

  • WCAG can define a method of creating your own user-agent list for Silver/gold. We wouldn’t set the list, but it could be used by people / regions / regulators to create one. (E.g. the GDS list).

• An example is the use of CSS media features. Is it ok to assume users with a need (e.g. reduced motion) have that setting applied? - These features can massively expand the level of testing needed if there are many variations of each page/thing.
  Yes at Bronze, you can assume people who need something have it enabled / installed. At Silver and up the methods could vary.

• What if a particular technology does unexpected things? E.g. reader-mode drops certain content.

  • That’s a UA problem at Bronze, author problem at Silver.

• Should a conformance claim include what assumptions were made about user-agents / accessibility support?

  • Yes at Silver / gold.

• How would this concept apply when the product conforming operates in a closed environment (e.g. kiosks, or intranets where staff have a particular set of AT they can use).

  • No impact, they would do the same as everyone else, just with a reduced set of ATs.

• Is the proposal impacted by AI? E.g. where responsibility moves from author to UA.

  • The methods for AI would need to be added as AT support for an outcome becomes available. E.g. if you have an author method for adding alt-text (with universal accessibility support), you could have a second method for AI generated alt-text from the user-agent. When the second method is tagged with sufficient user-agents to meet your conformance set, you could rely on that method.

[bruce-usab]

Looks great! The only thing that gives me pause is:

There would be no exception mechanism.

I'll take the liberty to suggest that exemptions/exceptions might be a separate topic from levels (and maybe even Accessibility Supported) and warrants its own conversations. I may be reading more into the line above than is meant.

With 2.x we have exemptions (e.g., legal, technical) allowing for conforming alternative versions.

With 2.x we have many in-line exceptions (e.g., several SC use "except for", "except when" and "unless").

We have also had some conversations that exceptions for security and privacy reasons could/should be holistic rather than SC oriented. Is the proposal that Gold disallow any exception mechanism for security or legal concerns?

[bruce-usab]

From call, I now understand that I did read too much into "There would be no exception mechanism" but still I suggest expanding that sentence a bit:

There would not be an exception for AT bugs, regardless of their age (and regardless of being well documented).

[MakotoUeki]

Let me correct a part of the example.

The most popular screenreader Japan (PC-Talker) doesn't support a lot of

HTML / ARIA, therefore a lot of our published techniques are not 'accessibility supported' there. This example should be: The most popular screenreader Japan (PC-Talker) doesn't support *newer features* of HTML / ARIA, therefore *some* published techniques *can not be *'accessibility supported' there. Thanks. 2024年5月8日(水) 18:24 Alastair Campbell ***@***.***>:

…

When we propose a technique as being "sufficient" to meet a success criteria/outcome, we need to be sure that the techniques are accessibility supported. As mentioned in the meeting, this is not the case internationally, and it is also not the case in practice. (See the summary from the sub-group <https://docs.google.com/presentation/d/1Oo7A6B44guvYaBkaFSBVaeSW1qCAglReaYqxSSsksNw/edit#slide=id.p> .) For example: - The most popular screenreader Japan (PC-Talker) doesn't support a lot of HTML / ARIA, therefore a lot of our published techniques are not 'accessibility supported' there. - Dragon *still* doesn't support the <input type="file"> <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file>, so a perfectly valid bit of HTML (like in H32 <https://www.w3.org/WAI/WCAG22/Techniques/html/H32>) doesn't work. - Some ARIA patterns (usually a reliable way of passing Name, Role, Value) have mixed support even in common AT. E.g. VoiceOver with Safari doesn't properly support <https://www.matuzo.at/blog/2023/details-summary> the details & summary elements. The current approach doesn't work internationally, and doesn't have sufficient granularity to work for people on the ground trying to work out which things they can rely on. I don't think anyone is suggested that it should be necessary for individuals or small businesses to conduct significant AT testing on their site (i.e. anyone who's main job is not development/accessibility). However, we do need to acknowledge that at some point relying on specs and the current techniques is not sufficient for an accessible user-experience. — Reply to this email directly, view it on GitHub <#53 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACENGACM5TUKFVKJODW4PILZBH4NZAVCNFSM6AAAAABDT3NMFSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNJSHE4DS> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bruce-usab]

On the call today, there was some discussion that usability testing with end-users might make Gold unappealing to regulators. I don't agree, and I share two contemporary U.S. counter examples:

1. From ADA.gov > Enforcement > Cases page on Justice.gov/CRT > Keyword Search for WCAG
   • Read though any of the Settlement or Consent Decrees and one will find a requirement for testing with end-users.
2. From M-24-09 (December 2023) Strengthening Digital Accessibility and the Management of Section 508 of the Rehabilitation Act

   Agencies should conduct user-centered and collaborative co-design activities to identify the needs, preferences, and expectations of people with disabilities. Prior to deployment, agencies should test and validate design and development solutions with individuals with disabilities and assistive technology users.

That said, the Section 508 Regulation does not include an explicit requirement for user acceptance testing with end-users. Also, both DHS Trusted Tester Conformance Test Process and ICT Testing Baseline for Web Accessibility very deliberately avoid dependance upon AT.