WAI - ARIAIntroduction to Accessible Rich Internet Applications

Vinod Tiwari

Consultant - UI & Accessibility

I am a Software Professional

with over 7 years of experience

in web design & development

and passion to develop usable &

accessible products.

Twitter - @vinodt_

LinkedIn - www.linkedin.com/in/vinod-t

Problem Statement

Accessibility of web content requires semantic information about widgets, structures and behaviours, in order to allow assistive technologies to convey appropriate information to persons with disabilities.

Default HTML elements do not convey sufficient information to ATs about advanced UI controls and widgets.

Solution (evolving)

WAI-ARIA, the Accessible Rich Internet Applications suite, defines a way to make web content and web applications more accessible to people with disabilities. It is useful for communicating dynamic changes in content with AJAX and screen reader interaction with advanced UI controls.

How? ARIA extends HTML by using additional attributes that are designed to convey custom semantics. These attributes are used by browsers to pass along the control's state and role to the accessibility API.

● Landmark roles to describe structure of page- navigation, header, footer etc.

● Roles to advanced UI controls and properties to describe the current state.

● Properties to mark live regions that get regularly updated using AJAX.

● Properties to mark regions for drag-and-drop functionality.

Progressive enhancement

Start with valid semantic HTML elements and progressively enhance AT (assistive technology) user experience with ARIA.

Landmark Roles Allows easy access to major sections of page.

● banner● complementary● contentinfo● form● main● navigation● region● Search

Source: Accessible Culture

HTML5 & Landmark roles

<header> role=”banner”

<nav> role=”navigation”

<main> role=”main”

<footer> role=”contentinfo”

<aside> role=”complementary”

<article> ** no corresponding landmark role.

<section> ** no corresponding landmark role.

Categorization of Roles

● Abstract Roles● Widget Roles● Document Structure Roles● Landmark Roles● Live Region Roles

Read them in detail- https://www.w3.org/TR/wai-aria-1.1/#roles_categorization

We will go in detail for some commonly used ARIA roles.

alert● Alerts are used to convey important and time sensitive messages to

the user.● Alerts are assertive and processed by ATs immediately without the

need to set focus on element.● Common use- form field error, login session expiry, connection lost etc.

alertdialog● alertdialog is used to notify the user of urgent information that demands the

user’s immediate attention.● The alert dialog must always be given an accessible name (through

aria-labelledby or aria-label).● An alert dialog must have at least one focusable control and focus must be

moved to that control when the alert dialog appears.

button● button role should be used for clickable elements that trigger a response when

clicked by user. Screen reader will announce it as button control.● Additionally use tabindex to make button focusable and use aria-pressed

attribute for toggle buttons.● NOTE- It is recommended to use native HTML buttons rather than ARIA button

role.

dialog● dialog role is used for modal window that separates content from rest of page

and usually is placed on top of page with overlay.● Additionally dialog must be properly labeled and keyboard focus must be

managed.

presentation● presentation role is used to remove semantic meaning from an element and its

related child.● In some websites <table> is used for layout purposes. role=”presentation” will

remove any semantic meaning for ATs from <table> element.

progressbar● progressbar role should be used for an element that displays status of a task

that takes a long time or consists of several steps.● Progress can be indicated using aria-valuenow, aria-valuemin, aria-valuemax

attributes.● As task progresses, aria-valuenow value should be updated dynamically to

indicate progress to ATs.● If progress value can’t be determined, omit the aria-valuenow attribute.

status● status role is a type of live region and is applied to advisory content that is not

important enough to justify alert role.● Status information must be provided within status object and it should not

receive focus.● Screen readers may provide a special key to announce current status and this

should present contents of status live region.

States and Properties

● By using the ARIA role, you have a means of presenting what a control is, or can do, but no way of presenting the current state of what it is doing.

● ARIA uses a set of extended attributes to document the state and properties of elements within the control.

Live regions ● Live regions are elements that are expected to get updates at run time.

● An ARIA role may be set on the element that is a live region role: "alert", "status", "timer", "marquee", or "log".

● If the element is not one of the explicit live region types, the aria-live attribute may be used. The aria-live attribute may be added to any element

● A good example is email web application updating inbox with new messages.

Don’t depend on ARIAMany AT users are stuck on old version of screen readers without ARIA support.

Remember, Progressive Enhancement!