Accessibility - WAI-ARIA

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

It is common on the web for the current thing in a collection to be highlighted visually, but providing an alternative for screen reader users has often involved something of a hack. The aria-current attribute is intended to solve this problem.

[…]

Here’s the official attribute definition:

Indicates the element that represents the current item within a container or set of related elements. The aria-current attribute is an enumerated type. Any value not included in the list of allowed values should be treated by assistive technologies as if the value true had been provided. If the attribute is not present or its value is an empty string, the default value of false applies and the aria-current state must not be exposed by user agents or assistive technologies.

According to the ARIA 1.1 specification, the aria-current attribute can be given one of a predefined set of values (enumerated tokens):

page

represents the current page within a set of pages;

step

represents the current step within a process;

location

represents the current location within an environment or context;

date

represents the current date within a collection of dates;

time

represents the current time within a set of times;

true

represents the current item within a set;

false

does not represent item within a set.

So the aria-current attribute can be used to solve the first use case in this post like this:

When a screen reader encounters the link identified with aria-current, it will announce something like “Home, current page link”.

Whenever aria-current is used with a value other than true, that information is incorporated into the screen reader announcement. For example in this set of steps, a screen reader will announce “Do this, current step link”.