-
Notifications
You must be signed in to change notification settings - Fork 232
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.
Another basic problem with all the time-base media criteria is that they do not specify anything qualitative, and very little from a technical perspective. For example, there is nothing to measure the quality of the captions or audio descriptions, or media alternative, or techniques to show General good practices.
The lack of specific information has led to a number of issues being opened over what exactly should be in an audio description (e.g., https://github.com/w3c/wcag/issues/3806). There are many challenges to tackle in this area. For example, some users consider that verbatim captions should include "ahs", "ums" and speech habits; others want captions to be 'cleaned up'. For audio descriptions, it is entirely unclear what level of verbosity audio descriptions should contain. Depending on technologies, there are potentially a number of different methods or sufficient techniques, such as the options described in one comment.
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