WAI-ARIA defines additional attributes that can be added to HTML elements to convey custom semantics and make web content and applications more accessible to people with disabilities. It provides landmark roles to identify major sections, widget roles for advanced controls, and properties for dynamic content and interactions. ARIA should be used to progressively enhance the accessibility of interfaces while maintaining valid semantic HTML as a baseline.

1. WAI - ARIA
Introduction to Accessible Rich Internet Applications

2. 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

3. 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.

4. 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.

5. 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.

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

7. Landmark Roles
Allows easy access to major sections of
page.
● banner
● complementary
● contentinfo
● form
● main
● navigation
● region
● Search

8. Source: Accessible Culture

9. 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.

10. 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_c
ategorization
We will go in detail for some commonly used
ARIA roles.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. Don’t depend on ARIA
Many AT users are stuck on old version
of screen readers without ARIA support.
Remember, Progressive Enhancement!