Chief Accessibility Officer Jonathan Avila and Manager of Accessibility Services and UX expert Kara VanRoekel hosted a well-attended webinar last week, “WCAG 2.1: What You Need to Know to Ensure Compliance.”
There were a few questions during the webinar that they did not have time to address, so they have provided answers in this post. For more information, you can access the webinar slides and transcript here: WCAG 2.1: What You Need to Know to Ensure Compliance.
Q: Can you talk more about “hover?” We were advised by counsel that providing an alternative to hover (or in any experience) is not acceptable as “separate is never equal.” I’m wondering how many people are using hover and how they are making it accessible via keyboard?
In the case of WCAG 2.1 SC 1.4.13 Content on Hover or Focus it is primarily addressed at making the additional content dismissible, hoverable, and persistent for low vision users after it has already been triggered. Apart from that success criteria, regarding triggering of additional content – additional content needs to be available with the keyboard (SC 2.1.1) as well as the mouse. WCAG does allow for alternatives – for example when the same information is available on the page or linked from the page. Alternative pages and alternative sites are something to avoid – however, there can be situations where alternatives to something are acceptable – such as a summary and data table alternative to a chart or a pick up and drop button as an alternative to a drag and drop sequence. When content appears on focus without the user wanting it to appear it can be distracting – so the additional keyboard requirement to dismiss the content with a key such as escape will be very helpful to users. It may be possible to balance use of hover content and a visual indicator that tells people to press something to get additional content with the keyboard rather than having it appear on focus.
Q: Success Criterion 1.4.11: Non-text Contrast… re: this new guideline has attempted to clarify success criteria for Providing sufficient colour contrast between web-app button and link states: focus, hover, and press. How does this apply to the “Hover” button and link state when the user’s mouse pointer cursor also changes shape (cursor changes shape from pointer to hand) to indicate the hover state? For example: If we are changing the user’s mouse pointer cursor’s shape during button/link hover, do we also need to ensure sufficient colour contrast (3:1) between the button’s normal and hover states?
This discussion came up in the Accessibility Guidelines working group. At this point this requirement does not appear to be aimed at having sufficient contrast between the hover and focus states themselves but ensuring that when the state is triggered the content in that state conforms to the contrast requirement. The only time when two states would need be compared against each other is when you have a state like a selected tab with an adjacent control that is part of the same widget. In the case of selected tabs you would need either sufficient contrast between the selected and non-selected states or you could simply use some other visual identifier to communicate which is selected or not. Use of some other identifier is likely best in other use cases as well such as high contrast mode where lightness is often lost.
Q: I would like to know how the WCAG 2.1 updates will be incorporated into the VPAT templates and timelines associated with that integration.
I do not have a specific timeline – but they will likely coincide with the updates to the VPAT format to account for changes in the EU Standard EN301549. ITI is responsible for changes in the VPAT format as it is copyrighted by them.
Q: Are there any security repercussions for using the auto-complete attribute?
This is something that has been discussed. Most browsers have controls that allow the user to control the filling of fields and users have to explicitly tell the browser to autocomplete the content. If people wanted to collect information with off-screen fields with autocomplete after the user chose to use autocomplete for a visible field that used autocomplete they could already do that today. Thus, addition of the criteria doesn’t appear to change what can already be done today.
Q: Is horizontal scrolling not allowed at all? How about features that won’t display on a screen for any user?
Horizontal scrolling is ok for widgets like carousels, toolbars, tables, map, and other things that require 2 dimensions. For text and content that can be presented without 2D scrolling it will need to respond to the 320 CSS pixel requirements of this criteria.
Q: Does 1.4.11 apply to visual focus indicator?
Yes, the non-contrast requirements apply to the visual indication of focus. When the default focus styles unmodified (like the default browser applied focus outline) are used it is generally seen as considered sufficient to meet the exception within this criterion.
Q: 1.4.11 applies to those non-text elements of important context and not decoration, correct?
Right, it would not apply to decorative content – or any part of an image or control that was not important for understanding. It also doesn’t apply to disabled content.
Q: How are ‘hover’ features accessible to screen readers if these are accessible via ‘mouse only’? Not sure how this solves that problem.
WCAG already contains SC 2.1.1 requiring functionality to be keyboard accessible. This new criteria SC 1.4.13 is not aimed at replacing that but to allow the additional content to be hoverable, dismissible, and persistent mainly for users with low vision but also has benefits for keyboard only users who want to dismiss the focused content with the keyboard without moving focus.
Q: Does hover state styling have to have minimum 3:1 contact vs. non-hovered state (I assume not but it is unclear from W3C docs), or vs. the background (I assume so), or both?
The intent is not to compare the hovered vs. non-hovered state but instead ensure that each state looked at by itself has sufficient contrast. See the previous question on this topic which covers comparison between states like selected and non-selected.
Q: Any sense of when the Information Technology Industry Council will update the VPAT to include WCAG 2.1 guidelines?
Refer to the prior question on this topic.
VPAT 2 does not yet WCAG 2.1. VPAT 2 will be updated in the near future with the updated EU EN301549 standard and WCAG 2.1
Q: Does 2.5.4 address being able to turn off gestures for those who may accidentally trigger them?
2.5.4 Motion actuation does cover being able to disable the actuation. If you are asking if SC 2.5.1 Pointer Gestures has similar language – I am not aware of a requirement to disable gestures that might be accidently triggered – but that is a good idea. There are some touch accommodation features in iOS that might assist with that under Settings > General > Accessibility > Touch Accommodations.
Q: If labels are already descriptive, where does autocomplete become helpful?
Autocomplete allows for icons or other personalization to be used for people who may not be able to understand the label.
Q: Are you planning on a webcast for the VPAT 2.2 updates and the EN310549 standard when it is finalized?
This is a likely topic, but we have not yet made a definite decision as the updated VPAT has not yet been made available. Please check back.
This blog post is for informational purposes only and does not constitute legal advice.