-
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.
There are a number of situations where an alternative version is not an explicit way to meet a specific criterion (although it is identified as method to meet at the conformance level). Any situations where the alternative version can be met in-page should be documented on a case-by-case basis (and documented here).
Similar to to alternative version, there are several current requirements that do not provide an 'equivalent function' exception, which may be useful to designate
There are a number of situations where the author cannot control behaviour. The appearance of visited/unvisited links is one (and how it relates to Use of Color). The failure of 2.1.1 Keyboard due to key press timing built into native select elements is another (wherein if a user types quickly enough the key presses are treated as a string of characters for repositioning within the list of options, or if typed more slowly, each character repositions to the first option starting with that character).
Another potential exception could be around the appearance of placeholder text, and how it relates to Contrast (Minimum). The user agent controls the placeholders default appearance, but the author can override the style of the placeholder text (via ::placeholder in CSS), so it is worth discussing whether they are responsible for its appearance. The author can also decide whether to use placeholder text in many situations (although it can be harder than one might expect to prevent any placeholder text from appearing, down to having to designate an empty space " " as the placeholder text), so in this situation, a discussion can take place about the limitations of a user agent exception, but it would still be worthwhile considering the limits of author responsibility.
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 a WCAG A level criterion to control sound quality, which means;
* sufficient 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 receiving 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
We should use SVGs wherever possible in WCAG 3. This will improve the quality of the images and make updating them easier, as SVGs can be opened by numerous different editing applications. Where it's not possible to use SVGs, for example: an annotated screen grab of some UI, it would be good to require keeping the layered, editable, image somewhere. Admittedly, editing those would be harder depending on the availability of the original editing application.