search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 257 forks source link

Supplement Understanding 4.1.3 #894

Open JAWS-test opened 5 years ago

JAWS-test commented 5 years ago

I think it would be good if https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html were supplemented as follows:

  1. a warning that the output of live regions through assististive technology is currently very poor. Live regions should only be used after thorough testing. This is due to errors of user agents and assistive technology on the one hand, and incomplete specification on the other hand (https://github.com/w3c/aria-practices/issues/78). A superficial test of JAWS with Chrome, Firefox, IE 11 and Edge has revealed a huge number of bugs (https://github.com/FreedomScientific/VFO-standards-support/issues?q=live+region). I suspect that other screenreaders are not better... Feedback on this topic is very welcome.
  2. a warning that the output of live regions by programs for visually impaired users (screen magnifiers with reading aloud function) probably does not exist at the moment (https://github.com/FreedomScientific/VFO-standards-support/issues/15)
  3. a warning, that visually impaired users using the zoom function or screen magnifiers may have difficulty or may not be able to perceive status messages. This is currently not covered by SC 4.1.3. Developers are advised to take this into account and consider the extent to which important status messages need to be presented in other ways (e.g. modal dialog that receives the focus).
  4. a warning that the content of live regions is difficult to perceive with the screenreader because it is only output once and cannot be read with the virtual cursor (https://github.com/FreedomScientific/VFO-standards-support/issues/282). This may be considered a violation of Guideline "2.2 Enough Time: Provide users enough time to read and use content."
  5. a warning, that live regions are output as plain text. The text structure and the role of interactive elements in the live region are not perceptible and the interactive elements are not operable because the live region does not receive the focus. A live region should therefore only contain text if possible.
  6. a warning that live region should actually only be used for the narrow definition of status messages (https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html#dfn-status-message). Any use beyond that would be an abuse of live messages and a violation of SC "2.2.4 Interruptions"
  7. a hint that for all the above reasons a modal pop-up might be better for important status messages (such as error messages). However, it would be best if the users could configure on the site themselves how they would like to see and hear important status messages.

Two further comments on the current Understanding:

Non-displayed text specific to AT users: ... Important considerations regarding the appropriate use of such techniques are further discussed in the Sufficient Techniques

Unfortunately I can't find any information about this in the section "Sufficient Techniques"

Non-textual status content: ... Where an icon or sound indicates a status message, this information will be surfaced by the screen reader through a combination of two things: 1) existing WCAG requirements governing text alternatives (under SC 1.1.1 Non-Text Content), and 2) the requirement of this current Success Criterion to supply an appropriate role.

Not every form of a text alternative is automatically output in a live region. For example, what about the text alternative of SVG graphics or embedded graphics? What about text that is added via CSS? The specification says nothing about that.

patrickhlauke commented 5 years ago

i'll just add a general personal comment here that you seem to want everything spelled out in understanding etc documents, covering every single scenario, hints and tips about the specific technologies, current levels of support, etc. while laudable, this becomes unsustainable. WCAG documents can't be maintained constantly, even with the best will in the world. they're not a cookbook on how to achieve things, and there will be many other considerations (current levels of support for certain approaches, all possible scenarios/ways in which a criterion can be passed, etc) that won't make it into these documents.

JAWS-test commented 5 years ago

The WCAG also contains such notes elsewhere. And there are also very specific recommendations in 4.1.3 on certain technologies, e.g: "aria-atomic=true is necessary to make Voiceover on iOS read the error messages after more than one invalid submission." (https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA19)

patrickhlauke commented 5 years ago

not saying these are never there. but that it's a balancing act/level of detail exercise here. also, also a difference in terms of notes added to a specific technique (relating to a particular technology used in that technique) versus understanding docs which usually (but not always) try to be a bit more open-ended/agnostic.

JAWS-test commented 5 years ago

I understand your objection, though. My suggestions are certainly too extensive. Hence my proposal in a new form:

Also, for WCAG 3.0 one should consider whether the problem that status messages are not noticeable on zoom/screen magnifiers gets its own SC.

mraccess77 commented 5 years ago

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.

JAWS-test commented 5 years ago

I wonder if one can even speak of an "accessibility supported way" for live regions because so much is unclearly specified