This is part two of a two-part presentation. Catch up on part one here: Introduction to ARIA and HTML5, Part 1
I’m typing this introduction before the presentation begins, and as I understand it, this session will be more technical than the morning session. I’m not sure how many in-depth code samples will be included (the resources link below hints at what we’ll be talking about), so I’m making an educated guess that I may not be able to capture every nuance. My apologies in advance if this is the case.
Presenters:
- Steve Faulkner, The Paciello Group (@stevefaulkner)
- Hans Hillen, The Paciello Group (@hanshillen)
- Bill Gregory, The Paciello Group (@thebillygregory)
- Karl Groves, The Paciello Group (@karlgroves)
RESOURCES
- files.paciellogroup.com/training/CSUN2014 (slide here)
- Many of the examples Steve showed were with CodePen, which will be familiar to users of JSFiddle.
- W3C NU markup checker: http://validator.w3.org/nu/
EVENT PLUG – TPGBB (The Paciello Group Bug Bash)
- Wherein you and TPG can ID and squash AT bugs
- Thursday, March 20, 5:30 – 6:30 PM
- Suite 3233, Harbor tower, Manchester Grand Hyatt
STEVE FAULKNER’S SEGMENT
SLIDE ONE
Diving into some HTML5 – an overview of the session
Steve Faulkner talked briefly into his involvement with his having a role in the creation of the HTML specification. His specific interest is in how APIs speak to AT.
SLIDE TWO
Getting Simple
Getting to use native HTML controls makes things simpler for the developers and the AT.
SLIDE THREE
HTML5 Demo – details/summary
Here’s an example of the “HTML code triangle” we’re all used to:
<details>
<summary> label </summary>
Some content
</details>
When fully supported, you’ll be able to use native HTML controls without having to use any complicated JavaScript. In the example above, clicking details would expand and show the contained elements.
Steve then demonstrated in CodePen an example of the code above, and how vastly simplified it is to render these UI elements. This will make UI/UX designer’s lives much easier.
SLIDE FOUR
Chrome, Opera, and Safari have implemented this
Keyboard = 1/2 implemented
SLIDE FIVE
Steve then gave a description of how the code above is exposed to the AT APIs (i.e. MSAA). Put simply, it’s exposed as a <div>, however, it’s not an accurate description of how it’s represented within the DOM. He then proceeded to show how this looks when viewed through the “Accessibility Viewer” tool. The aviewer tool is an object inspection tool available from the Paciello Group’s web site at http://www.paciellogroup.com/resources/aviewer.
Not all information is necessarily passed through the API and readable by aviewer. The hope is that every browser will expose the same API Names, Roles, and States.
SLIDE SIX AND SEVEN
What We Want
- We want to be able to see what’s actually there.
- We also want to fill the gaps in general support in FF, IE, and webkit browsers
SLIDE EIGHT
Steve showed and described the example above, only this time embellished with ARIA code inserted.
SLIDE NINE
Showed the details summary here as a working example: http://www.html5accessibility.com/CSUN14/details.html
The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.
SLIDE TEN
Dialog
Creating a modal dialog that works with keyboard and prevents users from accessing ‘disable’ content is the holy grail…
Being able to do this within native HTML is something that sure would be awesome. See next slide…
SLIDE ELEVEN
What we get for free:
- Focus moves to modal dialog when displayed
- Focus stays until it is dismissed
- Content not in the modal dialog is really disabled
- ESC key dismisses it
- <dialog> = role=dialog
SLIDE TWELVE
What we need to add (this only works in Chrome with Canary plug-in at the moment)
- Accessible name to dialog: <dialog aria-label=”text”>
- Currently when the dialog is dismissed, focus moves to <body> when it needs to move to control that triggered dialog display: can be polyfilled using scripting.
Steve demonstrated accessible modal dialog, once again with CodePen; he was unable to tab “out” of the modal dialog. It works like a JavaScript alert()
SLIDE THIRTEEN
The “good oil” on implementing custom dialogs (I didn’t capture these links, but they’re available in the TPG source slides from the “Resources” link above).
- Juicy Studio – Custom Built Modal Dialogs
- The Incredible Accessible Modal Dialog
- WAI-ARIA design pattern – modal dialog
SLIDE FOURTEEN
Input type=number
What we get:
- Correct role and value information
- Keyboard operable
Exposed as spin buttons
SLIDE FIFTEEN
Input type=range control
Implemented in all browsers. However, default styling in IE is pretty funky, and they all look different from each other. Bottom line: you get everything for free.
SLIDE SIXTEEN
There are conformance rules for HTML5, but they can be difficult to decipher. Steve has a “Using ARIA in HTML” document available for download which can help.
SLIDE SEVENTEEN
A large part of what’s been consuming Steve’s life in his role on the HTML5 specification group is figuring out which ARIA Roles, States, and Properties can be used on any HTML element.
SLIDE EIGHTEEN
ARIA Validation
- Use of ARIA in HTML5 is non-conforming and probably always will be. It doesn’t make any difference, it still works.
- Easiest method is to use the HTML5 DOCTYPE with ARIA markup and then validate it using the W3C NU markup checker: http://validator.w3.org/nu/
<!DOCTYPE html>
KARL GROVE’S SEGMENT
SLIDE ONE
Live Regions
- Allows user to be notified of content changes
- Typically for content that changes automatically
- Content change may exist separate to what has focus
- Live Regions facilitate these notifications
ARIA overcomes gaps between what JavaScript has “traditionally” done in web browsers to emulate desktop applications.
SLIDE TWO
Karl’s favorite thing to say: “What is this thing & what does it do?”
- Chat, error logs, etc. (role=’log’)
- Status messages (role=’status’)
- Urgent message requiring immediate notice (role=’alert’)
- Stock ticker (role=’marquee’)
- Timer/Clock (role=’timer’)
- Progress indicator (role=’progressbar’)
- None of the above (role=’region’)
SLIDE THREE
How important is the content?
- aria-live=’polite’ (waits patiently, default for most roles)
- aria-live=’assertive’ (interrupts output, default for alert role)
SLIDE FOUR
What’s being changed?
- I’m adding stuff (aria-relevant=’additions’)
- I’m removing stuff (aria-relevant=’removals’)
- I’m changing text (aria-relevant=’text’)
- I’m replacing stuff (aria-relevant=’all’)
Makes relevant changes to the DOM within that live region. You can change these properties together as needed.
SLIDE FIVE
What matters?
- aria-atomic=’false’ (default behavior, only announces changed node)
- aria-atomic=’true’ (presents entire contents)
SLIDE SIX
What’s my name
A redux of aria labels that was covered in Part One
SLIDES SEVEN AND EIGHT
<div role=’alert’ aria-label=”Errors’>
Please correct the following errors:
</div>
Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.
SLIDE EIGHT
Karl then demonstrated some of the challenges when using live regions with a chat he had set up at: chat.karlgroves-sandbox.com
He also showed a web-based slideshow called “shower”
Download and play with Karl’s JQuery plug-in at github.com/karlgroves/jquery-live-regions
Short break here…
Karl went about soapboxing:
“ARIA is a LIE and your HTML doesn’t do anything. They are instead a polite request to the browser about what to do with our code, which is then transformed into a DOM.”
Principle of Least Astonishment: things should behave consistently
HANS’ SEGMENT
SLIDE ONE
- Keyboard and Focus management
- Form validation
- Mode conflicts
- Solutions, workarounds, and considerations
SLIDE TWO
Problem with Custom Controls (not native UI)
Usually created with generic elements like <divs> and <spans>
- Not keyboard focusable
- Have a default tab order
- Behavior unknown
Best solution is to use native controls, or manually define keyboard focus and behavior needs.
SLIDE THREE
Keyboard Issues in a Nutshell
- Reachability: via tab order, globally defined shortcut, activating another widget
- Operability: all functionality should be doable via keyboard and mouse input.
SLIDE FOUR
To be accessible, ARIA input widgets need focus.
- Tabindex=”0″ element becomes a part of the tab order
- Tabindex=”-1″ element is not in tab order, but focusable
Each widget should have only one stop in the tab order. All of your widgets should be reachable via keyboard. Hans then gave a demonstration of a tree widget, tabbing both into and out of it using JAWS. This demonstration also pointed out the danger of wrapping a page with a role of application.
An alternative for a roving tabindex is the aria-activedescendant=”<idref>”
SLIDE FIVE
Every widget needs to be operable by keyboard. Common keystrokes are:
- Arrow keys, home, end, page up, page down, enter, space, esc
- Mimic navigation in the desktop environment when possible: www.w3.org/WAI/PF/aria-practices
- Always manage and keep track of your focus. Never let it get lost.
To demonstrate focus, Hans showed a table that allowed deletion of columns of data. After deleting a column, the previous column received focus.
SLIDE SIX
Skipping Mechanisms
- Ability to skip content is crucial for screen reader and keyboard users
- Skip links may be out of fashion and often misused, but users still need to be able to skip.
- Alternatives: collapsible sections, consistent shortcuts, custom focus manager
SLIDE SEVEN
Form validation
- ARIA makes form validation easier to manage: aria-required & aria-invalid states, role=”alert” flags validation errors immediately. Inline and error summary used together are most effective.
- Validation summaries make invalid entries easier to find
Create a programmatic connection between validation messages and their associated fields. Maybe there needs to be a W3C specification about how AT is supposed to behave (there’s one for UA). Hans provided a demonstration of a sample form with required fields. Tabbing away from a required field activated the “required” error when tabbing into the following field. He attempted to mark up the fields as live regions, but it didn’t work very well.
SLIDE EIGHT
Fallback solutions for link buttons
There’s no real consensus on links versus buttons. Set role=”button” to make links look like buttons for screen readers
SLIDE NINE
Mode conflicts, i.e. Role=Application
- Screen readers normally browse in ‘virtual mode.’ This means it navigates a virtual copy of the web page. It intercepts all keystrokes for its own navigation (i.e. “H” for heading navigation.
- For dynamic web apps, virtual mode may need to be turned off. Interactive widgets need to define the keystrokes themselves; content needs to be live, not a virtual copy; automatically switches between virtual and non-virtual mode.
- role=”application”: screen reader switches to non-virtual for these elements; must provide all keyboard navigation when in role=”application” mode; screen readers don’t intercept keystrokes then, so typical functions will not work.
SLIDE TEN
Role=Document
- For apps with reading or editing sections (e-mail client)
- When applied to a container inside an application role, the screen reader switches to virtual mode.
Only use application role when your application actually IS a web application.
SLIDE ELEVEN
Explain to users how Rich Internet Applications work
Put some hidden text at the beginning of the page to explain.
SLIDE TWELVE
The perfect dialog, in theory
- Use role=”dialog” combined with aria-labelledby (for dialog title), aria-describedby (for dialog message text)
- Focus management
- For modal dialogs: prevent virtual navigation to background using aria-hidden=”true”