Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make Web content and Web applications […] more accessible to people with disabilities.
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:
- Digestible. We strive to feature short, digestible pieces of content.
- Up-to-date. The project is hosted on GitHub so information can be current with the latest standards.
- 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
titleattributes. 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, witharia-pressedorrole="switch"plusaria-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
buttonas 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
esckey 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.
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-currentattribute 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-currentattribute 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 thearia-currentstate must not be exposed by user agents or assistive technologies.According to the ARIA 1.1 specification, the
aria-currentattribute 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-currentattribute can be used to solve the first use case in this post like this:
[aria-current] {
font-weight: bold;
background-color: #cc33ff;
}When a screen reader encounters the link identified with
aria-current, it will announce something like “Home, current page link”.Whenever
aria-currentis 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”.