WCAG 2.1 on a mobile device

Unpacking Commonly Misunderstood WCAG 2.1 Success Criteria – Webinar Q&A

Written by: Kim Phillips

We got a lot of great questions in last week’s webinar – Unpacking Commonly Misunderstood WCAG 2.1 Success Criteria – presented by Chief Accessibility Officer Jonathan Avila. Jon has provided responses to all of them below, and if you’d like more information on the topic the webinar resources are now available on-demand.

For input field, the border requirement applies in high contrast as well?

High Contrast is not specifically covered by WCAG 2 – refer to this Github issue on high contrast mode for discussion.    High contrast mode like Dark mark is important to users but not clearly addressed by current requirements.

Can you indicate the focus state by making the text in the button bold on hover and still pass success criteria? 

Yes, currently the criteria does not indicate how to communicate focus state – so bolding, underline, etc. can be used to meet the requirements.   Keep in mind that inconsistent methods are confusing for users and subtle methods are difficult for users with low vision to discern.

For 1.4.11 , if the visual focus lacks sufficient contrast on the menu (shown as example), does it pass or fail the criteria?

If the menu control’s appearance was changed by the author (not default from browser) and the focus indication is adjacent – then the focus indicator must provide >= 3:1 contrast from adjacent pixels.

There is some language in the 1.4.11 understanding page that says “positioning” can be a distinguishing indicator for a button.  In your opinion, does this mean that ghost buttons (no border or background) that use color to communicate they are interactive  conform to use of color as long as you use position as well to make them stand out?

Yes, unfortunately a button with no border passes this current requirement. Affordance such as border are very important issues for people with low vision and cognitive and learning disabilities but the group was not able to reach consensus on this issue.  There is discussion on a possible WCAG 2.2 criterion for this – but mandating a specific affordance can be difficult to get adoption.  Another method  of helping users might be creating content in  a way that users can apply a border easily through a stylesheet or browser extension.

On the gestures, swipe, if there is a keyboard, why is that not sufficient?

Opening up a keyboard interface on a mobile device is very difficult – and in some browsers getting the keystrokes from an on-screen or physical keyboard to be sent may not be possible.

What is the name of the autocomplete tool that shows the values on the screen?

We have created a favlet here for showing autocomplete values.

When using autocomplete, are there any discussions related to privacy and security? related to PII?. for example, if accessing the form in a public library could potentially give away someone else’s information?

Yes, there have been discussions on the WCAG github page and a security review was performed by a group in the W3C.

Can you give us a preview of one or two WCAG 2.2 guidelines that will be covered later this year?

Potential Success Criteria thus far can be found on this public Google sheets page.

Just want to confirm – if a site’s navigation goes from a horizontal nav bar on top to a hamburger menu with a sidebar – this *is* considered a violation based on reflow?

This is not a violation as long as both are accessible and meet all of the criteria.

I think I missed what we’re supposed to be “testing” each breakpoint for. Was that covered?

Technically each breakpoint should be tested for all of the success criteria -however, in general each break point will need to be tested for things that are likely to break such as reflow, text spacing, contrast, reading order, etc.

So a control is the best for the gesture?

If you have an operation that requires a gesture then generally the best option is to provide an additional control as an equivalent.

Can you repost the github link?

https://github.com/w3c/wcag

For non-text contrast success criteria, why are buttons not required to have a border with sufficient contrast (or a border at all)?

This was the determination of the working group.  I and others made a strong case that borders are important clues that help people with disabilities to locate buttons and don’t require the user to read through all text or tab/hover over content.  Ultimately I was in the minority to require buttons to have sufficient contrast.   I’d recommend that folks share any research you can on the topic to help shape future requirements to in this area.

In use of graphs, you said it would be sufficient to enter percents with the categories, would that make the piechart, for example, as a decorative image?

Yes, if you had all of the information in text such as percent’s and legends then you would not need the graph at all to be accessible for contrast for alternative text – we’d still recommend adding alt text at least indicating what it is and it would be best practice to create the graph with sufficient contrast.

For 1.3.5 (input purpose), if I buy 3 plane tickets and need to fill out the passenger info, if i’m one of the passengers then 1.3.5 applies to the fields I’m filling about myself but does that mean the other other passenger form fields don’t have to conform to 1.3.5?

That is correct – only the fields about you must conform to 1.3.5.

Do all browsers interpret the labels you showed us for forms the same?

You may be referring to the icons in the 1.3.5 Input purpose example.  The icons I added where through stylesheets in an extension.    The use of icons in this manner is an assistive technology and prototype extension that was created to support the user need.  In this case I added them with an extension I have installed for other purposes.  Unfortunately mainstream assistive technology has not taken up this example so I don’t have an example to point to.

Can you indicate the focus state by making the text in the button bold on hover and still pass success criteria? 

Yes, currently the criteria does not indicate how to communicate focus state – so bolding, underline, etc. can be used to meet the requirements.   Keep in mind that inconsistent methods are confusing for users and subtle methods are difficult for users with low vision to discern.