Real

JavaScript

Ninja’s

know how

to role with

WAI-ARIA

Dylan BarrellTwitter: @dylanbarrell, @unobfuscatorGitHub: dylanbhttp://unobfuscated.blogspot.com/

8 trillion

$8 trillion

15%

1 billion

POUR

PerceivableOperableUnderstandableRobust

Call a Spade a Spade

RoleNameState(s)Value

Keyboard (and gestures) – add graphic of a Braille keyboard

Insert periodic table of ARIA roles

• ARIA roles:– Provide the ability to control the

transition between application (forms) mode and document mode

– Provide more native announcments for widgets like menus, tabs, sliders etc.

– Provide for the ability to control announcements when updates occur away from the focus

– Provide much more control over the structure of the document and how someone navigates around it

Insert periodic table of ARIA attributes

• ARIA attributes:– Solve the problem of multiple labels and

descriptions through the addition of finer-grained labeling attributes

– Enhance the ARIA roles through the addition of standard state, value and role-specifying attributes

– Add some attributes for better control of what is spoken by the screen reader versus what is simply there for presentational purposes

First rule of ARIA – If there is a native HTML element that does

the job, use that

Examples1. Use <button> and <input

type=“submit”> NOT <a role=“button”>

2. Use <ul>, <ol> and <li> NOT <span role=“list”> etc.

Compelling ARIA roles• Landmark Roles

– main, search, navigation, contentinfo, complementary, banner

– region in combination with aria-label

• Live Region Roles– log, status, alert

• Some Widget Roles– tabpanel and tab– slider– menu, menubar, menuitem and associated attributes– dialog – in combination with the document role to get it

to work in NVDA– tree and treeitem – a bit tricky to get to work reliably

• Some form roles– button, textbox, checkbox, radio, radiogroup

• presentation role

Second rule of ARIA – test it on all YOUR platforms with the

assistive technology YOU support

All platforms have problems, most have workarounds, iOS is the

most problematic and Android is not quite ready for prime time

yet

ARIA holes• Tables, tables, tables– Use the a11yfy library

• Arrow keys on iOS– Insert dynamic modal content in line– Use gestures

• Gestures– Think hard about your mapping to the

portable gestures– add on screen controls where possible

Accessible Gesture Calendar Examplehttps://github.com/dylanb/gestura11yhttp://dylanb.github.io/datepicker/datepicker.html

• Shows use of tabindex to control focus• Shows use of role=“application” to force

application mode• Shows use of aria-live regions to announce the

current date as the user moves around• Shows use of aria-hidden to hide presentation

markup from the screen reader• Shows use of keyboard handler and mapping to

gestures• Shows how to ensure that gestures are

consistent regardless of zoom level

Accessible Gesture Calendar Examplehttps://github.com/dylanb/gestura11y

Third rule of ARIA – Always attach your event handlers to

the same element that has the role and the focus

If you stick to this rule, you will avoid events not being delivered consistently

Fourth rule of ARIA – In complex widgets like menubars,

tabpanels etc. always make all interim structures

presentational

Fifth rule of ARIA – in a complex widget where you are

managing focus, disable all naturally focusable elements

with tabindex=“-1”

Example is the a11yfy menu examples where the anchors

are given tabindex=“-1”

FinallyThere is a wealth or resources including

The ARIA specification http://www.w3.org/TR/wai-aria/

The Authoring Practices http://www.w3.org/TR/wai-aria-practices/

The WAI Web Site http://www.w3.org/WAI/intro/aria

Mozilla Developer Network https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA