-
Notifications
You must be signed in to change notification settings - Fork 266
WCAG 3 parking lot considerations from 2.x
This is a place to list topics that are discovered from WCAG 2 issues that cannot be resolved inside the existing normative scope of WCAG 2.x and thus are consideration for the next version of WCAG.
As per https://github.com/w3c/wcag/pull/1642#pullrequestreview-1784175041 there is currently no requirement to document a non-conventional keyboard operation in WCAG. If it can be done by keyboard but a user cannot figure out, it is not a failure!
For WCAG 3, a requirement to document accessible methods/keyboard where they deviate from conventions (and maybe some establishments on conventions) should be included. It’s another of those situations where I do not believe it was the intent by authors of WCAG that a mysterious key should pass; rather, the assumption was keyboard operation would be not just Operable, but predictable and Understandable. In a word, Robust 🙂
2.1.2 does have that kind of caveat “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”
2.2.1 also introduces the idea of ‘before encountered’. IMO WCAG 3 should introduce a notion of documentation within the current UI or some such wording to establish that the user does not need to spend effort figuring out how to operate.
WCAG 2.x could use an editorial pass to remove “trigger” words.
One example is “requires”, as a reader might easily infer it to mean “required” (or requirement for conformance). Example from 3.3.2:
"Labels or instructions are provided when content requires user input."
This use of “requires” is not intended to be read to mean that labels are only provided for fields that are marked as "required". The intent is that labels or instructions should exist for input fields.
Some of the requirements can appear overly prescriptive in typical scenarios. This section captures potential examples.
There is already overlap between Error Identifcation and Error Description. Comments as part of https://github.com/w3c/wcag/pull/1651 showed that there is some support for tightly scoped situations where, through use of programmatic indicators of error, text may not be necessary for the identification of errors, only for description.
The WCAG standard rarely specifies that an "equivalent" for something is in the same language/dialect (i.e., "mother tongue"), but that is clearly the assumption. This should be made explicit; this could potentially be made at a 'global' level, or it could be done on a per requirement basis.
In common parlance, there is typically a distinction made between captions (a text-based synchronization with spoken dialogue, in the same language) and subtitles (a text-based synchronization with spoken dialogue, in a different language). It can be inferred that WCAG 2.x is intended to require an alternative using the same language, for captions and audio descriptions, but this is never stated. Similarly, it can be assumed that the requirement for sign language is expected to meet a regionally appropriate sign language (such as ASL for a United States production in English). Given that many streaming services provide many localization options, there may be multiple language versions of a video available -- both with subtitles and with dubbing (where the original dialogue is replaced by dialog in another language). It would be useful to specify which of these versions must meet the requirements of time-based media success criteria in order to meet the standard. It could be that a variant of something offered in a different language has a different threshold for conformance in a number of scenarios.
For audio only, and/or some video audio tracks eventually, we are still missing aWCAG A level criterion to control sound quality, which means;
* sufficent max volume,
* clearly distinguishable voices/other sounds.
So far, we only have a WCAG AAA level criterion 1.4.7 Low or no background audio to control sound quality. Audio background is not the main problem we have to solve so far. You do not imagine the poor quality of audio we are receiveing today. This is huge problem for audio only... :-( It is less concerning in video audio tracks, though it highly depends a lot on the video type (professional vs amateur).
We need the WCAG to help us solve this audio quality problem. reference #3861