Last week’s presentation in our Accessibility Basics Webinar Series covered best practices for ARIA. In this post Chief Accessibility Officer Jonathan Avila has provided answers to the questions we received during the webinar.
The webinar slides, transcript, and recorded presentation can be accessed at https://dev-level-access.pantheonsite.io/resources/overview/.
ARIA Webinar Q&A
When using a UL to contain a list of navigation links, would you recommend adding role=”navigation” to it directly, to a div around it, or not at all?
//JA: Use a div with role “navigation” around the UL or use the nav element.
What is the state of ARIA from a compliance and legal perspective? If your site uses ARIA, but the assistive technology and user agent does not support it, can you claim that your site is “accessible”?
//JA: No, you can’t really claim WCAG conformance without accessibility support. The support is based on the technologies used. So within an organization, an internal site or content that only works with select AT may conform – but for a public site, you need a broader range of AT and user agent support to claim it is accessibility supported. (For information about accessibility support and conformance claims see http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html)
Could aria-live be a useful tool for a character counter or word count for text input fields?
//JA: Yes, but you need to be careful that it is not overly verbose. For example, you don’t want it to be announced after every character – perhaps just when you are getting close to the end.
Is ARIA created just for screen readers, or will it have any impact for voice recognition or other AT software?
//JA: Dragon uses some ARIA properties – such as allowing the user to speak the text associated with a field via aria-labbelledby. The support is limited. ZoomText and other screen magnifiers also rely on aria-activedescendant for focus tracking.
So JAWS will not recognize DIV but it will recognize the ARIA role?
//JA: Correct, Div is a generic container.
Would a JAWS user really want to hear “Sandwich condiments lettuce, sandwich condiments tomato, sandwich condiments mustard”? That’s a lot of repetitive information, and the most specific information is stated last, which slows users down. Would it make more sense to put the extra context label after the item-specific label? Wouldn’t a user encounter the header and hear that before the option list, thereby reducing the need to even have the extra “conds” label?
//JA: If you referring to the use of legend and fieldset or use of ARIA role group with an aria-label or aria-labelledby with the group name – this behavior of JAWS speaking the group name before each item is actually specific to JAWS. With other screen readers like NVDA, the group name will only be announced the first time you enter the group either going forwards or backwards. You could use aria-describedby to associate the group name and that would allow it to be announced after the label for the checkbox.
Is it common to add extra information that is not initially shown on the page?
//JA: Generally, you don’t want to add extra information that is not shown on the page unless somehow it is needed and can’t be provided any other way. It’s not clear why extra information was provided in this example.
In the sandwich condiments example, why do they use a list of images and hide with role presentation and we give them role checkbox when native HTML checkboxes exist?
//JA: Some authors want the checkboxes to appear a certain way across all devices or they may be using a framework that doesn’t use actual checkboxes. While this may be possible with CSS to customize the appearance, ARIA is an option. Ideally, yes, you should use native HTML elements.
Will the screen reader user hear the list? Will we hear bullet checkbox label…?
//JA: The screen reader user will not hear the role for anything with role presentation. When a role is present the screen reader user will hear that role. If a role of presentation is not applied to the list and list items the user may hear that information – it still may be useful information to the user in some situations, but could be distracting in others.