Day 2. Learning about ARIA Roles

UX Engineering in Public

04-10-19

👉Jottings from https://css-tricks.com/why-how-and-when-to-use-semantic-html-and-aria/.

My previous knowledge has always been to override browser default and provide custom styles and behavior for elements.

I’ve recently learnt that we don’t need to do that. There’re a lot of experienced people who ensure that things work on the web.

Making Custom Things

If we want to make a custom element, we would write the HTML, event handlers, and imitate consistent behaviors on Web (Different browsers), Android, iOS, Mac, Windows etc.

There’s more…

How would screen readers announce it? How would browsers describe it? How would search engines differentiate it from other elements on the page? How would RSS readers correctly present the content?

But when we use a standard element like a button, we get all that for free.

Semantic HTML is leveraging the hard work of awesome people who’s job is to make the web accessible to anyone, anywhere. If you’re concerned about accessibility, you should begin from markup. Markup is the basis of accessibility.

ARIA Roles

On the other hand, we could make use of ARIA (Accessible Rich Internet Applications) APIs to enhance the experience for screen readers and assistive technology. For instance, if a button toggles a menu, we could communicate the state of the menu to the reader. Here’s how we would achieve this

<button aria-expanded="false"></button>
<div hidden>Some Menu Content</div>

We could then make use of JavaScript to set the aria-expanded attribute to true when the menu shows. This will communicate useful information to the browser and screen readers like what is on screen and what isn’t.

👉Jottings from http://web-accessibility.carnegiemuseums.org/foundations/semantic/

Semantic, Structural HTML is the basis for accessible web content. Screen readers mainly read only HTML content. If a screen reader can’t correctly read HTML first, then adding CSS and JavaScript to make content meaningful is reinventing the wheel and will mostly fail.

Choosing elements based on Meaning

Every HTML element is specifically useful in describing the contents of the page. A page with lots of divs , spans and less semantic elements is on the far meaningless spectrum while one with less divs and more HTML5 elements is more meaningful.

Semantic HTML elements are chosen based on their meaning and not their styling. Styling can be fixed with CSS. HTML is concerned with structure and meaning alone. We can go a long way by

• Using one H1 per page and ensuring other headings are used with appropriate hierarchy. E.g, use a H2 first before a H3, rather than manipulate the font-size attribute with CSS to achieve hierarchy.
• Using the most appropriate HTML element for the content. <address>, <cite>, etc.

👉Jottings from http://web-accessibility.carnegiemuseums.org/foundations/aria/

ARIA (Assistive Rich Internet Applications), is a spec from the World Wide Web Consortium (W3C) that was created to improve accessibility of web pages and applications by providing extra information to screen readers via HTML attributes.

ARIA attributes are divided into two categories: roles, and states & properties.

ARIA roles are used to communicate the role of an element on the page. There’s four categories of ARIA-roles

• Landmarks
• Document
• Widget
• Abstract

Landmarks ARIA Roles:

Screen readers for blind and visually impaired users use these ARIA attributes to get a broader view of the web page and easily jump to different sections. Think of a user who wants to jump straight to the main content.

While there’s a main tag, setting the role attribute to main on the main element will make it easier to navigate to the main content. The same also applies for nav elements too. Here’s the different values of the role attribute.

• banner: element containing the main title of the page.
• complementary: Content aside from the main content, but is meaningful on it’s own. e.g aside.
• contentinfo: A section providing more information about the parent document. Think copyright info, general links, references etc.
• form: Block of content for entering information
• main: Main section of a page
• navigation: Any section containing important links for primary navigation.
• search: The search component of a page.
• application: Used to describe a part of the site that is more interactive than normal document centered pages.

Checkout Using ARIA landmarks to identify regions of a page for more info.

Document ARIA Roles

While Landmark roles describe sections of a webpage, document roles describe the structure of content on the page. Examples of common ones are

• article
• definition
• group
• heading

Widget ARIA Roles

Widget roles are more appropriately used to describe JavaScript-like and interactive elements that change overtime. A few examples are

• alert: Elements with important, time-sensitive content
• alertdialog: A dialog showing an important message and takes initial focus.
• button: No brainer
• dialog: Interrupts the use to collect information from the user
• radio: Describes a radio button
• tab: Navigation for iterating tab content
• tabpanel: A container for content controlled by a tab navigation
• textbox: form element for free text entry

ARIA States & Properties

ARIA states and properties are used to support ARIA roles on a page. Think of them as describing the relationship between 2 or more elements on a page.

Properties are less dynamic and rarely change while States are usually updated with JavaScript once application state changes.

There’s a comprehensive list of all ARIA states & Properties on ARIA Roles, States & Properties