Thanks to Refresh Detroit member Maria Gosur for sharing her notes from our July 2016 meetup, Introduction to Accessible Rich Internet Applications (ARIA), with speaker Matt Isner, a JavaScript developer at Deque Systems.

The video recording of Matt’s presentation is available on YouTube. You can find Matt’s presentation slides on Slideshare.

ARIA can help with AJAX, tabs, slides, menus, etc. Roles instruct screen readers to the appropriate mode for interaction.

There are two modes for screen readers:

1. Browse mode: keypad
2. Application mode: bypasses keys to do interaction types via javascript, event handlers, etc

The Accessibility Tree

• Name
• Role
• Value
• State

• ARIA roles will override native HTML tags
• Keyboard-only users is a large population
  • Tabbing around is important
  • Tab order has to be scripted

States change; Properties are static.

Only use ARIA when appropriate; it supplements HTML markup

Popular: aria-describedby and aria-labeledby

VoiceOver on Mac is designed for Safari browser
You can jump to landmarks here

Document structure roles: group
Ex: for forms (like a checkbox group)

Widget Roles

• Ex: slider
• Watch tab index
• Use tab-index=0 -> this makes default keyboard tab accessible in that tab order

Application Regions

• Ex: calendar date-picker
• Don’t use a date-picker if not needed

role=“presentation”

• Use this attribute if it doesn’t have/add meaning for the user
• Use alts even if it’s a blank alt tag

Live regions announce activities, but be careful because this can be annoying!
Ex: chat window where the response must be heard

In CSS, display:none and visibility: hidden hides content from screen readers

Use button for markup

Create a support matrix to test with user agents and put this diagram on your website for screen readers to find and be aware of.

ARIA labels need to be for focused items.

Speaker had code example for “all widgets” -> we should do this
Make sure the drawer is accessible.