Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

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”