What does "accessibility-supported" mean?

[JAWS-test]

What does accessibility-supported mean? My impression is that the answers to this question are contradictory, and the Understanding is too vague for me to decide in real life whether a site is WCAG compliant according to 5.2.4

I would be pleased if this question were to be clarified and possibly supplemented in the Understanding.

Below are some examples of comments on the topic, which do not give a consistent picture for me.

@awkawk

https://github.com/w3c/wcag/issues/1005#issuecomment-572077561

According to WCAG you are not responsible for the bugs of the browsers and AT

This isn't accurate. Accessibility Supported requires that you use techniques that actually work. You may make a conformance claim that references Windows 10 and NVDA and other current tools and not include Window-Eyes 5.5 in that claim and as long as there is accessibility support in the browsers and AT that are part of your conformance claim then that claim can stand up.

If there was a major issue in a major browser rendering engine that defaulted to hiding the keyboard focus for interactive controls, for example, authors would need to find a way to restore that even if this was regarded as a bug in the browser (again, unless the conformance claim didn't include that major browser rendering engine).

@patrickhlauke

https://github.com/w3c/wcag/issues/866#issuecomment-522678815

it's even more problematic if you try to make a case that a site's owner/developer has failed to comply with WCAG if the fault lies not with their page/code/anything they control, but with the user agent the plaintif used. you'd instantly make every site liable to prosecution if a browser had some problem/bug.

@mraccess77

https://github.com/w3c/wcag/issues/866#issuecomment-522823801

When HTML 5 validation error mechanics are not accessibility supported in common browsers then I would generally fail it per the WCAG Conformance Requirement for accessibility support. Making a determination for accessibility support depends on a number of factors including whether it is a public or private site and the combinations of user agents that would be available in the particular environment. This issue has always been a point of flexibility under WCAG to address support in real world situations. Today with Firefox the role dialog is not communicated with JAWS or NVDA -- so you have to make a determination based on the browser and AT combinations whether this is a violation or not. If not a violation it's likely something people need to be aware of as it impact the user under SC !.3.1 and something we would consider marking as advisory. Failing people for issues in the user agent and coming up with hacky solutions isn't always the best answer. If people could never pass WCAG because of user agent limitations where would we be?

https://github.com/w3c/wcag/issues/894#issuecomment-529419113

I believe many screen readers also do not show ARIA live regions in Braille unless the user is sitting on the text. This means that people who are deafblind could miss live regions changes. This is a screen reader issue though and not the authors issue if they have created the region in an accessibility supported way.

@jake-abma

https://github.com/w3c/wcag/issues/866#issuecomment-524637612

To answer the main question / title: "Error of the User Agents part of WCAG or not "

Errors of User Agents are not part of WCAG. WCAG focusses only on the content and responsibility of the content author (solutions must be accessibility supported)

Does this make the Web already completely accessible, no, there's much more to do for this. The UA, authoring tools, AT makers etc. all have their responsibility.

UAAG and ATAG are initiatives to give guidance, adoption is up to the vendors.

[alastc]

Part of that understanding doc includes the normative definition: https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported

So it means that (1) a technology/technique is accessibility supported when it can be used by the user's AT, and (2) that there are ATs available for that technology. (See the definition for the longer version, with notes.)

I'm not sure why (2) is separate as it seems to be a sub-set of (1), but I suspect it is to do with 'odd' enviromements such as kiosks or other closed-enviroments.

With that definition in mind, all the above comments make sense, apart from Jake's which is true of WCAG's aim, but not true of making conformance claims.

As people having been making conformance claims for many years and changing this would create huge problems it is not something that is likely to change in WCAG 2.x. However, @peterkorn might be interested in this from a conformance-challenges point of view.

[patrickhlauke]

the problem is that (1) is impossible for authors to know in advance ... and a user may choose an old, quirky, non-conformant AT. maybe they like a particular AT, but that AT has notoriously shoddy support for a particular technology (think ZoomText and its known flaws when it comes to ARIA). if a site makes correct use of ARIA, is it the developer's fault that ZT doesn't follow the standard?

further, the aspect of "supported by AT" can be vague when it comes to bugs/problems in that AT. an AT may for instance nominally "support ARIA" or specific aspects of it, but then have bugs that mean a very specific (but still valid, per ARIA spec) use of ARIA doesn't produce the correct result in an AT. again, is it the developer's fault? and as bugs come and go in software, this would potentially invalidate conformance claims - if it was "supported" today, but then browsers/AT have a regression or new bug that means something fails, in future...is the developer liable because NOW it's not "real-world supported"?

(note that, to me, these are more legalistic distinctions. of course a site should aim to work correctly for its users, work around any known bugs/quirks of AT, test that things actually work as they should...but then it becomes more a best practice/real-world accessibility issue to me, rather than a "meeting WCAG's baseline" issue)

[alastc]

Yep, I guess it's trying to balance between making things work for users in practice and being reasonable to do.

Assuming a conformance claim is treated like an MOT (i.e. valid at the time of making it) and the site has a process for dealing with issues, that seems like the most reasonable course, at least in a WCAG 2.x context.

[WilcoFiers]

I think the WCAG evaluation methodology had the right idea here. You decide per audit, what the accessibility support baseline should be; i.e., which browser + AT combinations need to work. If it content works in those, it conforms to WCAG. Caveat to that is that the same piece of content can conform if you use one baseline and can not conform if you use a different one.

Short answer, WCAG is pretty darn clear about this. Content authors are responsible for making sure the stuff they build works for their users. And yes of course ideally UA / AT just follow the specs. But when it comes to AT, there aren't actually all that many specs to follow. Can't blame them for not following a spec that doesn't exist, or for going outside the specs to try and improve the user's experience. And we shouldn't lose sight that a lot of PWD don't have the funds to regularly update their tech either.

[patrickhlauke]

I think the WCAG evaluation methodology had the right idea here. You decide per audit, what the accessibility support baseline should be; i.e., which browser + AT combinations need to work. If it content works in those, it conforms to WCAG.

so that means that if i do an audit today and some SC passes, it may fail in future? seems very brittle to me to be honest...

so not only do you evaluate things with subjectivity in certain SCs, which may colour your pass/fail results, but you also evaluate against a particular set of browser/AT and their support, and pass/fail according to what those pieces of software currently support in a bug-free way? makes an accessibility audit result even more sketchy and variable...

[patrickhlauke]

e.g. say a site uses aria-current to programmatically indicate the current page in a navigation, in addition to using some color/visual identification. do you hard-fail this against 1.1.1 even though the author has done the right thing IF your testing baseline included an older browser/AT combo that doesn't support aria-current?

[jake-abma]

@alastc says:

With that definition in mind, all the above comments make sense, apart from Jake's which is true of WCAG's aim, but not true of making conformance claims.

My comment was:

To answer the main question / title: "Error of the User Agents part of WCAG or not "

Errors of User Agents are not part of WCAG. WCAG focusses only on the content and responsibility of the content author (solutions must be accessibility supported)

This is correct, also for conformance claims, as a UA NOT supporting code / a SC, shouldn't be part of your claim to conform. See between brackets "(solutions must be accessibility supported)"

Don't see why Errors of User Agents are part of WCAG, and yes, they are not allowed to be used when making a conformance claim.

[peterkorn]

@JAWS-test - you have labeled this issue as part of "Challenges with Conformance". Reading through the text, it feels like a general conformance issue for WCAG, not something tied to the https://w3c.github.io/wcag/conformance-challenges/ document. Can you remove the label if my supposition is correct?

[JAWS-test]

@peterkorn: The label is not from me, but from @alastc. I cannot remove it, because I do not have the access rights

[alastc]

I added the label as the topic above seems like a challenge for making conformance claims... I think Silver is trying to avoid using something like accessibility supported, but then how do you ensure practical support?

[sajkaj]

Closing for now. If this is indeed something we eventually address in our conformance challenges note doc, it's not a topic for the FPWD.

[sajkaj]

Reopened as this is now [Challenge

5](https://raw.githack.com/w3c/wcag/conformance-challenges-5aside/conformance-challenges/index.html#Challenge-5)

in the latest Challenges with Conformance working branch. Please feel free to suggest edits and/or additional text.