Last week I had to pleasure of attending the John Slatin AccessU conference at St. Edward’s University in Austin, Texas. In addition to taking part in many of the sessions on offer, I held a workshop (admittedly, more of an extended presentation) on the basic concepts of WAI-ARIA – Introduction to ARIA: The Why, The How, The New, The Weird…
Using a mix of theory and simple live examples (including the step-by-step remediation of an inaccessible “faked” button control, an accordion widget, various uses for live regions, and a simple modal dialog), the workshop aimed to convey:
- the limitations of “vanilla” HTML for rich interactive web experiences (though some of the gaps are being filled by new elements and APIs in HTML5)
- the problem of custom/non-standard structures and controls (made using a mix of HTML, CSS and JavaScript) not being conveyed to assistive technologies
- how browsers and assistive technologies communicate via an accessibility API at the operating system level
- how ARIA’s primary purpose is to influence/determine what information browsers expose via the accessibility API, which is ultimately what assistive technologies will announce to the end user
- that ARIA itself does not change browser behavior – when using ARIA, authors will still need to manage focus and keyboard behavior, and dynamically update state and property information for interactive controls
- some of the new additions in ARIA 1.1, as well as some of the problem areas still present in the specification – in particular, how some suggested ARIA widget patterns (such as custom sliders and inputs with autocomplete functionality) can be problematic when accessed using assistive technologies on touchscreen devices
The full set of slides and examples/demos is available on GitHub: WAI-ARIA – An introduction to Accessible Rich Internet Applications (HTML)