On 31st May 2021, nine new WCAG success criteria and supporting documents were put out for wide review resulting in a wide range of comments and issues being raised on the W3C’s own GitHub issues page.
TPGi understands the importance of—and fully supports—the continuation of the WCAG 2.x series, as well as the effort to include the public in the review process. However, TPGi feels that the current draft of WCAG 2.2 requires some clarifications and improvements.
We feel that the combination of issues raised below would cause confusion within the testing community and may result in content authors misinterpreting, and ultimately misusing, the additional success criteria. With that being said, TPGi believes that after consideration of our comments, along with the comments of other individuals and organizations, WCAG 2.2 will strengthen the existing guidelines and help fulfill the WAI’s mission to lead the Web to its full potential to be accessible, enabling people with disabilities to participate equally on the Web.
TPGi has submitted a series of comments to the W3C, which can be found below, organized per success criteria. The comments are taken from collated feedback after an internal consultation process. Please visit the individual issues on GitHub for their current status and further commentary.
2.4.11 Focus Appearance (Minimum) (AA)
Insufficient requirement for focus indication via enlargement
Figure 15 in the “Adjacent contrast” section of the 2.4.11 Understanding document shows three buttons that are very close to each other. The middle button has been enlarged by 2px on each side.
While it looks fairly clear when there are three buttons next to each other, we do not think that this would be a sufficient focus indicator for many users to perceive if one of these buttons were on its own.
Confusing wording due to unconventional state requirement
The logical structure of the SC is hard to follow, specifically because interpreting it correctly appears to require considering the page background as part of the control, something that we don’t think will feel natural for most people. If doing so is required, the normative wording should clearly signpost this.
Two relevant parts from the SC wording:
- The content under test must meet all four of the requirements (including “Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.”)
- The “Adjacent contrast” clause has two parts, joined by an “or”, so you can pick either one.
The choice in the “Adjacent contrast” requirement is subtle and risks being misinterpreted. Perhaps making the two options under “Adjacent contrast” into bullet points (as has been done with “Minimum area”) would make it clearer?
Also, Figure 15 in the “Adjacent contrast” section of the 2.4.11 Understanding document initially appears to violate the first requirement, as the 2px border added to the control to act as the focus indicator doesn’t contrast with the rest of the button.
However, the explanation for Figure 18 in the “Relationship to Non-text Contrast” section of the 2.4.11 Understanding document, which features an indication that doesn’t contrast 3:1 with the border of the checkbox, says:
The pixels making up the blue focus indicator have a sufficient Change of contrast from their white color in the unfocused state
Thus it seems the intent of the SC is for us to consider the white (in this case) page background as part of the checkbox’s unfocused state. Doing so allows all of the above to fit together.
However, the fact that the page background is considered part of the control feels counter-intuitive and is not explicitly called out in the normative text. Other SCs use the phrase “adjacent colors” to help clarify this, though explicitly mentioning “including the page background” would be clearer.
Typos in the text below Figure 18
Two of the bullet points below Figure 18 in the “Relationship to Non-text Contrast” section of the Understanding document begin “Ihe” instead of “The”.
Gradient Focus Indicators
The following comment is made in the 2.4.11 Understanding document:
A keyboard focus indicator that has a pattern or gradient may have parts that do not meet the 3:1 contrast ratio for the change of contrast, as long as an area equal to the minimum does meet the contrast ratio.
With the current color contrast tooling available, testing multiple pixels of a gradational focus indicator to determine the area of the part which meets the required contrast ratio will be non-trivial, especially when non-standard shapes are used.
The understanding document describes the process as straightforward, but we feel this would only be the case when the content under test is a clear pass. It would be significantly more laborious if the result is marginal. The precise nature of the test procedure may result in errors and therefore impact repeatability.
Editorial note: there are no spaces between the figure numbers and their captions.
Gradient Backgrounds
The 2.4.11 understanding document goes into detail on how to approach gradational focus indicators, but no examples have been given describing how to handle gradational backgrounds. Pages that have a non-solid background image covering the whole page or make use of parallax scrolling effects will result in a near-infinite number of color combinations if a page is scrolled and/or changes are made to the viewport size.
How can this be addressed pragmatically to benefit users without causing undue burden on testers at the same time?
Text below figure 2
To aid with comprehension, we suggest that a calculation is shown to demonstrate that the inner outline is well over the minimum requirement.
Text below figure 3
For consistency, the following text should be edited to include the correct units of “px” and “px squared”.
Figure 3 The thick (3px) yellow underline is almost as long as the longest edge, 80px
xis multiplied by 3px exceeds the requirement of 236px squared.
Text below figure 11
This failing example also fails “Adjacent contrast”, which references if you add a border or outline of a very similar color. We feel that a reference to this should be made to avoid authors changing “light-gray” to “dark-gray” to meet this 3:1 requirement without meeting the “Adjacent contrast” requirement.
2.4.12 Focus Appearance (Enhanced) (AAA)
Adjacent Links
Within the “minimum area” bullet two hyperlinks (“CSS pixel” and “perimeter”) are adjacent to each other. Some users may have difficulty in perceiving that they are separate links until they receive focus or are activated. This issue can be overcome by adding a word between the hyperlinks, such as “wide”, so that the sentence reads “…the area of a 1 CSS pixel wide perimeter…”
2.4.13 Page Break Navigation (A)
Query: are slides included?
Would a web-based slide show be covered by this SC and thus require some form of break indication?
Query: are pages with print CSS that includes page breaks excepted?
We assume so, as the author can’t know exactly where they will occur.
Web Content
Although the phrase ‘content (web content)’ exists in the WCAG glossary, a link to the definition has not been provided and it unclear whether this definition applies to this SC. We are wondering whether EPUB would be classified as web content or not.
2.5.7 Dragging Movements (AA)
TPGi has no comments on Dragging Movements that fit the scope of WCAG 2.2 and were pleased with the addition of the clarification with regards to SC 2.5.1 to the 2.5.7 Understanding document.
2.5.8 Target Size (Minimum) (AA)
Minimum Component Size
As discussed in issue 1848, this success criteria does not discourage the use of targets that are too small to be activated for users with motor-skill disabilities. As this SC has been renamed Target Size (Minimum), it feels prudent that a value for a minimum target size is provided for targets offset by at least 24 CSS pixels.
Name Change
With the current wording, our internal discussions have centered around the spacing exception.
As interactive controls can easily be given at least 24 CSS pixels of surrounding space due to the amount of height and width available to modern viewports, we feel that the original name of Pointer Target Spacing is more appropriate to our foreseen implications of this SC mentioned in the above issue.
Further Examples Required
To fully understand the impact this SC will have, further examples should be provided that include complex widgets that contain multiple, but separate, discrete targets. Examples could include material design style navigation drawers, date pickers, compact tab controls, ARIA <select>-style controls, or interactive toast messages that partially obscure content underneath.
Typo in the Figure description
Under figure 2, the height of the buttons is stated to be 22 CSS pixels. On the figure itself, the height is indicated to be 20px.
3.2.6 Consistent Help (A)
Using “should” in the 3.2.6 Understanding document is confusing
The Understanding document says that the linked help “should” be accessible and gives a non-exhaustive list as to how this may be done.
We are concerned that this may be interpreted as too loose a suggestion. While we understand from w3c/wcag#1237 (comment) that it’s not possible in 2.x to “scope-in” the external help, the Understanding document is non-normative, so it would be possible to use stronger language in the document to alert readers to how important it is for the help content to be accessible.
3.2.7 Visible Controls (AA)
Controls that require scrolling to reach
We gather that controls that the user can scroll to would pass this SC. We gather the following scenarios would pass:
- T&C modals that require a user to scroll to get to the controls that allow them to accept the terms.
- Cases where more options/fields become visible because of a selection elsewhere on the form. Think of filling out an address and the City field is not visible until the State is selected.
- Similarly, an e-reader that allows the user to select some text and then pops up some buttons to allow the user to interact in different ways with that text would pass.
If that’s the case, it may be worth clarifying that scrolling is acceptable.
However, what would happen in the following two different cases?
- With the examples above if there are no visible scrollbars to alert the user to the fact that there’s more content to scroll through before they get to the controls required to proceed?
- If table column sort controls only appear on hover/focus, but the user needs to use them to find the information they’re looking for in the table?
Controls that are always hidden for everyone
We gather that fields that are always hidden from everyone—i.e. honeypot fields—would be out of scope. Is this correct?
Subjective judgment is needed, and effort to test and remediate could be quite variable
The Understanding document says:
Controls such as video players, web chats, and carousels include controls that are only visible on hover since they overlay the contents being displayed. These controls are not considered a process in terms of this SC but occasionally completing a process requires interacting with one of these controls.
We take this to mean that a page containing video thumbnails that can be hovered/focused to reveal a play button would still pass this SC—unless completing a process required it, in which case they would fail.
This means that subjective judgment is needed on whether persistently visible controls are required, based on what the user may be trying to accomplish, based on quite a subtle distinction. This could be prone to misinterpretation and/or variable results, as well as quite different outcomes in both design, as well as time required to remediate, for fairly similar UIs.
The SC has an exception for equivalent components, as seen below.
The information needed to identify the user interface components is available through an equivalent component that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus;
If a piece of text was added onto the page, stating that “video controls are revealed on mouse over and keyboard focus”, should this pass the SC?
With the current wording requiring an “equivalent component”, we do not think it currently passes, but suggest that the SC could be given a labels or instructions exception.
3.3.7 Accessible Authentication (A)
Ensuring copy-paste is not blocked
The “Intent” section of the non-normative Understanding document mentions that copy-paste must not be blocked, but this is not in the text of the SC. We feel it would need to be in order to ensure that it’s a requirement.
Other Methods
If the “other method” used is inaccessible, such as an RSA SecurID token which is impossible for a blind user to use, is the requirement passed?
3.3.8 Redundant Entry (A)
Ensuring single transactions (from the user’s perspective) are covered
There are several sites on which, in order to complete a transaction such as buying something, the user is redirected to a payment provider before being sent back to the original site. E.g. when buying something from eBay, some of the screens in the middle of this process will be provided by PayPal.
We understand that such screens would be covered here, as from the user’s perspective they form part of one single transaction.
This was the case with the initial version of the wording, and we gather it would be the case with the latest wording, which includes the term “user-session”. The term is not defined, and could have many different meanings based on who is interpreting the SC, so we suggest it be removed as it appears to be redundant.
Acknowledgments
We would like to take this opportunity to thank the following people for their contributions. The links below will take you to their individual GitHub pages.
Comments
Thanks for your dilgence here, wishy-washyness makes me sad and auditing confusing.