Error of the User Agents part of WCAG or not

[JAWS-test]

5 of the new success criteria of WCAG 2.1 have the limitation that they only apply to problems caused by web developers and not to problems caused by user agents (see below). To my knowledge, these restrictions do not exist for the WCAG 2.0 criteria. Why?

• In itself, the restriction makes sense, because web developers are not responsible for the errors of the user agents.
• From an accessibility point of view, the restriction is bad, because in the end the affected users don't care who is responsible for the inaccessibility of the content.
• From a legal point of view, it is problematic because WCAG has been transposed into national law in many countries of the world, but not the UAAG. In addition, the UAAGs are from 2015 and do not contain any rules regarding the new criteria (and also not regarding all old)
• From the accessibility test point of view, the inconsistency between WCAG 2.0 and 2.1 is problematic because it means that web developers can be held responsible for browser errors with the old criteria, but not with the new ones. For example, I can say that a web developer cannot use a select element with multiple attributes if Chrome has been defined as the test environment (because non-contiguous multiple selection is not operable with keyboard, thus violating 2.1.1). But elements with too little contrast can be used as long as the colors have not been adjusted.

Examples:

• 1.4.11: "except ... where the appearance of the component is determined by the user agent and not modified by the author"
• 1.4.13: "Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author."
• 2.5.1: "this does not apply to actions that are required to operate the user agent"
• 2.5.2: "this does not apply to actions that are required to operate the user agent"
• 2.5.5: "except when ... User Agent Control: The size of the target is determined by the user agent and is not modified by the author"

[patrickhlauke]

To my knowledge, these restrictions do not exist for the WCAG 2.0 criteria

are there any criteria from 2.0 that you feel should be dependent on user agent support / include requirements that are outside of the control of authors?

From a legal point of view, it is problematic

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.

[JAWS-test]

are there any criteria from 2.0 that you feel should be dependent on user agent support / include
requirements that are outside of the control of authors?

There are problems of user agents or assistive technology with some success criteria. I have given an example: Multiple selection lists in Chrome are not fully operable with the keyboard. To be compliant with 2.1.1, this could mean that a developer is not allowed to use select multiple because he should know that this element cannot be used with the keyboard.
As with 1.4.11, it could also be the case with 1.4.3 that contrasts need only be met if they have not been changed. This can apply to placeholder texts, for example.
Another example for 3.3.1 and 3.3.2 would be that the error messages of the browsers during form validation are often not output by the screen reader.

[JAWS-test]

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

I can understand that, but then why is the restriction not applied to the old criteria?

I'm also not sure if 5.2.4 (https://www.w3.org/TR/WCAG21/#cc4) does not require developers to use only technologies that are actually accessible.

[patrickhlauke]

with regards to accessibility supported use of technologies, note the definition https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance#accessibility-supporteddef and particularly

The Web content technology must have accessibility-supported user agents that are available to users.

taking the case of multiple selects, it can be argued that it's perfectly valid to use multiple selects and say keyboard users have other user agents available to them other than Chrome. it doesn't mean "must be fully supported/implemented in all browsers/AT", but rather that there is a way for users to get it working, even if it means having to switch to another browser (with a bit of wiggle room).

it's only you, by saying "Chrome has been defined as the test environment", that is limiting the scope here. i'd say this would still be a pass, with a best practice note in the audit saying that while nominally the use of multiselect is fine in principle, you'd advise against it because Chrome has a known shortcoming here (and it's generally horrible for all keyboard users regardless, even when it does work).

in short, i don't think even 2.0 put the onus for browser bugs or lack of a particular feature etc on the author.

[mraccess77]

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?

[JAWS-test]

Wouldn't the failure have to be rewritten? E.g. https://www.w3.org/WAI/WCAG21/Techniques/failures/F95 "Procedure: ... 2. check if the new content is provided by the user agent ... If 1 and 2 are false, then content fails the Success Criterion."

[JAWS-test]

keyboard users have other user agents available to them other than Chrome

It may be easy to switch browsers, but:

• I don't know of any browser that supports all HTML elements correctly.
• many people work in their company in a closed environment where they are not allowed to change browsers
• the change of an assistive technology is not so easy, because they are usually very expensive and difficult to learn (e.g. screen reader)

[JAWS-test]

What efforts are being made to adapt UAAG to WCAG 2.1?

[JAWS-test]

I'm not sure if the original intention of WCAG was not to check if the user agents support an intended function. For example, I understand "Define an Accessibility Support Baseline" (https://www.w3.org/TR/WCAG-EM/#step1c) to mean that the combination of different operating systems, user agents and assistive technology should be tested practically. Otherwise, I wouldn't need to define any technologies at all, I would just do a source code analysis to find out if the WCAG is theoretically met.

[mraccess77]

Refer to Conformance Requirement #4 https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

[JAWS-test]

keyboard users have other user agents available to them other than Chrome

I understand "Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions" (https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head) to mean, for example, that an element must work in many browsers. If it doesn't work in one (like select multiple in Chrome), then it must not be used. But I find it really difficult to understand exactly what is required in 5.2.4.

[jake-abma]

I don't know of any browser that supports all HTML elements correctly.

For HTML5 Features... Edge: 100% (that doesn't mean 100% with an AT combination) https://www.html5accessibility.com/

---

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.

[JAWS-test]

For HTML5 Features... Edge: 100% (that doesn't mean 100% with an AT combination)

That's a good joke.

• The page only evaluates the new elements and not all HTML5 elements.
• Edge does not support several of the new elements (e.g. details and summary).
• Some HTML elements are not keyboard operable in Edge. Example input list=ID, datalist. As mouse user I see the list entries, as keyboard user I don't (tested with Edge 16 and 17).
• Edge is the browser that works at least with assistive technology - e.g. not really useful to use with JAWS
• Zoomtext does not work with Edge at all and recommends the use of IE 11
• Edge is dead and is replaced by Edge Chromium

[Myndex]

@JAWS-test

5 of the new success criteria of WCAG 2.1 have the limitation that they only apply to problems caused by web developers and not to problems caused by user agents (see below). To my knowledge, these restrictions do not exist for the WCAG 2.0 criteria. Why?

As a gross simplification, WCAG is more about guidance to authors of content, not browser developers. This is something that is being discussed extensively in SILVER in terms of scope/reach.

I've mentioned at various times that some functional needs are best addressed with the cooperation of app/user agent/browser developers as some needs are best accommodated by functions or features outside the control of the content author.

FOR INSTANCE: "User Style Sheets" literally throw out the author's design choices, but what is actually needed is a USER ADJUSTMENT SHEET, that modifies an author's content without overwriting it wholesale (which usually leads to breaking the content). But most modern browsers have or have extensions that allow such relative adjustment.

[JAWS-test]

@Myndex: I agree. The problem, however, is that WCAG and UAAG, ATAG and all the other rules for accessibility are currently strictly separated. WCAG is being further developed and UAAG and ATAG are not. WCAG is law in many countries, nobody is interested in UAAG and ATAG. Therefore UAAG and ATAG would have to be strengthened or WCAG would have to be supplemented by points which do not concern the authors. That's why WCAG often doesn't help us with accessibility at the moment, because many problems are not caused by the authors, but by the user agents and the assistive technology. For example, my main activity at the moment is to create bug tickets for the JAWS screen reader for bugs that have existed for many years and it is not foreseeable whether they will ever be fixed (https://github.com/FreedomScientific/VFO-standards-support/issues).

[alastc]

As an old issue marked as "discussion", I'll close this now.

Regarding:

5 of the new success criteria of WCAG 2.1 have the limitation that they only apply to problems caused by web developers and not to problems caused by user agents (see below). To my knowledge, these restrictions do not exist for the WCAG 2.0 criteria. Why?

WCAG 2.1 was pushing into areas not tackled by 2.0, and in those areas found that sometimes the user-agents don't meet the guidelines. As these guidelines are focused on web-content, authors are not required to work around that.