skip to main content

TAMU Webmaster's Blog


Information and insight from the A&M Webmasters

Making Accessibility Better with ARIA, Not Worse

January 28th, 2015 by mdmcginnis

Some takeways from Jared Smith’s ARIA Gone Even Wilder session at the Environment for Humans Accessibility Summit.

ARIA stands for Accessible Rich Internet Applications. As Jared Smith explains, “ARIA allows us to expand the vocabulary of HTML to include things that screen readers already understand.”

To do this, web developers use HTML tags and attributes. Probably the most important of these attributes is role, but there are many others, such as aria-label, aria-describedby, etc.

Most HTML5 tags have default ARIA roles. For example, an h1 tag automatically has the ARIA role of ‘heading’. Use HTML, then use ARIA to fill in the gaps.

Roles don’t change browser behavior. That is, giving a span the role of button doesn’t make it act like a button. If you define roles with ARIA, you must also support the standard anticipated behavior. You must add CSS or Javascript to make your span act like a button (clickable, etc.) If not, it will require overhead/orientation for everyone, to teach them how to use your widget. You don’t need to duplicate native roles. If you define a button using the button tag, you won’t have to worry about faking it.

ARIA supports a lot of user interface widgets (such as menu, slider, checkbox), and users need to learn how to use them. They may know tab only and not arrow keys. What if you do it right and they don’t understand? Should we break the rules/standards? No.

Common misunderstandings about ARIA roles:

  • Navs are rarely menus! Menus are File-Edit-View etc.
  • Lists are rarely a listbox. Listbox is a select menu.
  • Tables are rarely grids. Grids are interactive.
  • Dynamic content is rarely a live region (aria-live=”assertive”) If focus is set to it, it isn’t a live region.
  • Important information is rarely an alert. Alerts are read immediately.
  • Not all groups of links are navigation. Navigation lets you move within a page or across the site. Social icons are not navigation.
  • jQuery dialogs always have role=dialog regardless of their content, which makes them mostly inaccessible.

Navigation by type is not yet widely available. You can’t jump to it. Landmarks are usually identified anyway. It would be great for browsers to support keyboard navigation by structural elements (headings, nav, main) and ARIA landmarks. Then we wouldn’t need skip links.

Landmarks and labels

You can use aria-label or aria-labeledby to differentiate multiple landmarks of the same type.
Labels vs. descriptions: label is necessary, description is advisory
There is no aria-description, since aria-labeledby is better. It might be read twice if it’s already in context.
ARIA labels replace the link and label text. So a screenreader reads aria-label=”PDF” instead.
Use off-screen or aria-described by.
Ensure labels are on the focusable element, not parent or child or container.
HTML input attributes, however, can change behavior.
Users assume that if you can tab to it, you can interact with it. Don’t put tabindex=0 on text, only on links and buttons.

ARIA roles are an example of progressive enhancement – usually you can’t make your website less accessible by using ARIA (though it’s possible if you do it wrong), but older browsers might not see the newer attributes.

Wednesday, January 28th, 2015 Accessibility
Share this article

No comments yet.

Leave a comment

Categories

Archives