Accessibility - WAI-ARIA

When you navigate this page using VoiceOver, and use the Form Controls menu, you’ll get a list of all form controls on the page, including the Add to Cart buttons.

Quickly scanning these buttons you can tell that they provide very little value, as there is no way to tell which product each button corresponds to. How does a user know which button they want to go to and press if they don’t know which product it corresponds to?

[…]

A popular example of Voice recognition software used to browse the Web is Dragon Naturally Speaking.

[…]

Seeing it in action is the best way to get an idea of how it’s used. So, to quickly demonstrate how it is used on the Web, Level Access created a video demoing Dragon Naturally Speaking to fill out a form on a page. The following video is a short clip from their video which you can find and watch in full on [YouTube].

 

When the dragon user (in the video) wants to select a form control, he speaks out the visual text label of that control. This is one of many reasons why visual labels are important in user interfaces.

So when we have a series of Add to Cart buttons, a dragon user will speak the label of the button in order to interact with it. This is why adding text in the middle of the string makes it inaccessible. The content in the middle of the string would break the visible label. The user would be telling dragon to interact with a button whose label is not what it visually appears to be.

[…]

So whenever you need to add additional text to a visible label, it best come after what’s visually shown.

Similarly, always ensure the accessible name (announced by screen readers) matches the visual label as much as possible. This means that you’ll also want to avoid adding a label using aria-label that does not match the text label that is shown on a control.

Whether you build a widget as a web component using standards, Vue, React, or any other framework, or with a combination of HTML and JavaScript, screen readers that encounter your widget will look for clues in the rendered markup to discern what it is and tell users that they’ve encountered a search box, menu, or carousel.

Screen readers generally follow this order of precedence:

1. Look for explicitly set ARIA attributes (roles, states, properties), and in the absence of those:
2. Interpret any implicit roles from markup semantics (form elements, paragraphs, lists, etc).
3. Read any text available in the markup.

If no discernable semantics exist (think ARIA-less <div> or <span> tags), it skips to #3. So when you omit ARIA, you’re rolling the dice on whether users will understand that your <ul> is a menu and not simply a list. When you omit ARIA and semantic tags, you’re leaving it up to your users to figure things out (and potentially abandon your product because it doesn’t work).

Little #a11y tip for you: If you are using a status message bar, you’ll want it to be a live region. But it should aslo be discoverable in case the messages are missed when they’re announced. Good case for an <aside>:

<aside aria-live="polite" aria-label="Status">
  ...
</aside>

A repository of styled and “styled” form control patterns, and how they are announced by screen readers.

Why?

Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.

A11Y Nutrition Cards is an attempt to digest and simplify the accessibility expectations when it comes to component authoring. Based on the WAI ARIA Authoring Practices Guide.

Accessibility can be a complex and difficult topic. The Accessibility Project understands this and wants to help make it easier to implement on the web. Our goal is to accomplish this with three principles in mind:

1. Digestible. We strive to feature short, digestible pieces of content.
2. Up-to-date. The project is hosted on GitHub so information can be current with the latest standards.
3. Forgiving. People make mistakes, so we seek to be encouraging.

This seems like a really valuable resource on what ARIA attributes are required and optional in working with various role attributes.

Most of the time, tooltips shouldn’t be needed if you provide clear textual labeling and familiar iconography. Most of the time toggletips are a complex way of providing information that could just be part of the document’s prose content. But I see each of these components all the time in auditing websites, so I wanted to provide some guidance on how to make the most of them.

Checklist

• If you have space, don’t use tooltips or toggletips. Just provide clear labels and sufficient body text.
• If it’s a tooltip you are looking to use, decide whether the tip’s content should be provided as the label or description and choose ARIA properties accordingly.
• Don’t rely on title attributes. They are not keyboard accessible and are not supported in many screen reader setups.
• Don’t describe toggletips with aria-describedby. It makes the subject button non-functional to screen reader users.
• Don’t put interactive content such as close and confirm buttons or links in tooltips or toggletips. This is the job of more complex menu and dialog components.

How you design and implement your toggle buttons is quite up to you, but I hope you’ll remember this post when it comes to adding this particular component to your pattern library. There’s no reason why toggle buttons — or any interface component for that matter — should marginalize the number of people they often do.

You can take the basics explored here and add all sorts of design nuances, including animation. It’s just important to lay a solid foundation first.

Checklist

• Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
• Use <button> elements, not links, with aria-pressed or role="switch" plus aria-checked.
• Don’t change label and state together.
• When using visual “on” and “off” text labels (or similar) you can override these with a unique label via aria-labelledby.
• Be careful to make sure the contrast level between the button’s text and background color meets WCAG 2.0 requirements.

See the source link for very detailed descriptions of all of these points.

What it does

• Uses a real button as a control.
• Places the displayed content next in DOM order after the button.
• Uses some ARIA magic to augment the semantics and behaviour.
• Displays or dismisses content on click, press or tap (also dismisses on esc key press).
• Conveys state (collapsed or expanded) to AT users.
• When initially displayed content is announced by (most) screen readers that support aria-live.
• Screen readers users can also virtual cursor through and interact with the displayed content.
• keyboard only users can interact with controls in the displayed content.

What it does not do

Display content on mouse cursor hover.

View Toggletip demo on CodePen