Day 4. Using ARIA for more accessible content

In the course of learning about Semantic HTML as a basis for accessibility, I came across a document defining rules for using ARIA attributes. Here’re my notes from the document.

NB: ARIA stands for Accessible Rich Internet Applications

Rules of ARIA use

Rule 1

If you can use a native HTML element or attribute with the semantics and behavior you require already built-in, instead of re-purposing an element and adding ARIA role, state or property to make it accessible, then do so.

This maps directly to don’t re-invent the wheel, use semantic HTML where possible

Rule 2

Do not change native semantics, unless you really have to

Don’t make a paragraph act like a button

<!-- Bad -->
<p role="button">Click Me</p>

Rule 3

All interactive ARIA controls must be usable with the keyboard…All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.

If you change the behavior of a component using ARIA attributes, you also have to write scripts to make them respond behave like their equivalent. Here’s how the docs put it

What Adding a Role Does Not Do Adding an ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviors, states and properties of the host element but only the native role semantics

For example, adding role="button" to an element will make the screen reader treat the element as a button, but you have to make add all the states, respond to the enter and space keys as normal buttons do. You see, everything goes back to rule 1, use native .

Rule 4

Do not use role="presentation" or aria-hidden="true" on a focusable element. Adding role="presentation" or aria-hidden="true" will hide an element from both the DOM and screen readers.

Rule 5

All interactive elements must have an accessible name… An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.

When we associate a label tag with an input field, the text in the label will be announced when the user navigates to the input field.

<label for="name_input"
  ><input id="name_input" placeholder="Name" type="text"
/></label>

The label is the accessibility name of the input. Compare this to the block of code here

<p>Name</p>
<input type="text" placeholder="Enter your name" />

While users without visual disabilities will the Name text with the input field, there’s no way for screen readers to know it’s relationship to the input field.

An easy way to solve this would be to use the aria-labeledby or aria-label attribute

<p id="name_label">Name</p>
<input type="text" placeholder="Enter your name" aria-labeledby="name_label" />

or simply

<input type="text" placeholder="Enter your name" aria-label="Name" />

But why should you do this? You get all these for free when you use the label element together with the input field. Some vital things to note.I was initially wondering if we would need the ARIA tags if we use semantic HTML. Like

<header role="header"></header>

Here’s what the docs have to sayIn the majority of cases setting an ARIA role and/or aria-\* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.

Some examples of redundant ARIA

<button role="button">press me</button>

<h1 role="heading" aria-level="1">heading text</h1>

But this doesn’t that ARIA attributes are not needed. In some cases, there’re no semantic HTML5 elements that best describe content. Here’re are some examples from the docs

• alert
• menu
• menubar
• presentation
• scrollbar
• search
• tab
• tablist
• tabpanel
• …

Typical usecase

<div class="alert" role="alert"></div>

Complete list and more info on Using ARIA.

Thanks for reading and see you tomorrow.