Accessibility Technology Uncategorized

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.





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





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.



Getting Simple

Getting to use native HTML controls makes things simpler for the developers and the AT.



HTML5 Demo – details/summary

Here’s an example of the “HTML code triangle” we’re all used to:


<summary> label </summary>

Some content


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.



Chrome, Opera, and Safari have implemented this

Keyboard = 1/2 implemented



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

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.



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



Steve showed and described the example above, only this time embellished with ARIA code inserted.



Showed the details summary here as a working example:

The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.




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…



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



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()



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



Input type=number

What we get:

  • Correct role and value information
  • Keyboard operable

Exposed as spin buttons



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.



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.



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.



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:

<!DOCTYPE html>




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.



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’)



How important is the content?

  • aria-live=’polite’ (waits patiently, default for most roles)
  • aria-live=’assertive’ (interrupts output, default for alert role)



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.



What matters?

  • aria-atomic=’false’ (default behavior, only announces changed node)
  • aria-atomic=’true’ (presents entire contents)



What’s my name

A redux of aria labels that was covered in Part One



<div role=’alert’ aria-label=”Errors’>

Please correct the following errors:


Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.



Karl then demonstrated some of the challenges when using live regions with a chat he had set up at:

He also showed a web-based slideshow called “shower”

Download and play with Karl’s JQuery plug-in at

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




  • Keyboard and Focus management
  • Form validation
  • Mode conflicts
  • Solutions, workarounds, and considerations



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.



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.



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>”



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:
  • 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.



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



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.



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



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.




  • 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.



Explain to users how Rich Internet Applications work

Put some hidden text at the beginning of the page to explain.



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”


Accessibility Technology

Introduction to ARIA and HTML5 – Part 1

This presentation is a two-parter, this is part one.  If you want to skip ahead to part two, this is the link you’re looking for:  Implementing ARIA and HTML5 into Modern Web Applications (Part Two)


  • Jared Smith from WebAIM (@jared_w_smith)
  • Jonathan Whiting from WebAIM

For those who don’t know, WebAIM is from Utah State University.  Here are some resources that were cited during the presentation:



Requiring JavaScript is not an accessibility question…it’s a general usability question.



WebAIM Surveys of Users with Disabilities >98% of respondents have JavaScript enabled.  Upshot:  if you’re going to do scripting, you have to do it accessibly.

  • You’re probably better off to have your scripts fail entirely rather just partially.
  • Progressive enhancement allows you to retain functionality regardless of browser capabilities.



“Freak out mode”  occurs with screen readers when the currently focused page element disappears or is significantly modified via DOM manipulation, refreshes or other control changes.  Avoid it or address it by setting focus();

  • Mentioned the common use of carousels and other frequently refreshing content



JavaScript prompt, alerts, and confirmations are screen reader accessible!



Ensure Device Independence.  Functionality available to mouse users must be available to keyboard users



CAPTCHA – Completely Automated Patience Test to Confuse the Hell out of your Audience (humor with some scattered chuckles and guffaws).  There are ways to accomplish the goals of CAPTCHA – that is, proving you’re a human – while avoiding its use.




  • Accessible Rich Internet Applications
  • Specification developed by the PFWG of the W3C’s WAI (Protocols and Formats Working Group of the World Wide Web Consortium’s Web Accessibility Initiative)
  • W3C Proposed Recommendation (final step before formal recommendation)

Implementation by browser vendors has actually been quickly adopted by comparison with other web technologies like CSS.



ARIA Enhances accessibility of…

  • …dynamic content and AJAX
  • …scripted widgets and interactive controls
  • …keyboard interactions within a web page

ARIA bridges the gap to future versions of HTML

An example of a widget that is not available natively in HTML is the slider.  Screen readers know what a slider is, and they are able to read ARIA code and interpret it.



Screen readers understand a fairly broad vocabulary, but HTML’s dictionary is very limited.  ARIA expands HTML’s semantic vocabulary.  ARIA fills in the vocabulary needed to express functions needed.  It “paves the cow paths.”  In a sense, ARIA “paves the cow paths.”  They showed a series of photos of “cow paths” at Utah State University.



You can only make things more accessible by implementing ARIA now…if you do it correctly.  Some older versions of browsers and screen readers won’t read some features properly.  In that case, ARIA won’t break the page, the technology just won’t see it.  A common interaction now are light boxes that will close when pressing the escape key.



ARIA Core Components

  • Roles:  this is what this thing is <form role=”search”>
  • States: this is the condition of this thing <input aria-disabled=”true”>
  • Properties: this is a property of this thing <input aria-required=”true”>

HTML has default states and properties.  In ARIA, there is no limit to the number of states and properties a core component can have.  While you can include lots of states and properties to your components, you need to be cautious about overloading your users with too much information.  There is a sweet spot, though.  More info in a post here:



ARIA and Code Validation

  • If your (X)HTML is valid and your ARIA is valid…
  • valid+valid=??

Your ARIA markup may be completely valid, but many validators will show that your ARIA code is invalid.  ARIA is a part of HTML5 spec, so if you code is marked up as HTML5, you’re less likely to get validation errors.



ARIA Landmark Roles

  • Banner:  complementary, contentinfo, main, navigation and search
  • Allows easy access to major page components
  • The end of the “skip” link?  No, browser keyboard accessibility still sucks so you should keep using it.

If browsers would implement navigation via headings and landmarks, the skip link could go away.  Consumers should bug the browser vendors if they want better accessibility in their tools.

Question from the audience:  are there SEO benefits for implementing ARIA?  I don’t know, but in the future there may be benefits for content landmarks like “main”



Landmark Roles – some examples

  • <div role=”main”>
  • <form role=”search”>
  • <div role=”navigation” aria-label=”Main navigation”>

You can add aria-label to differentiate multiple landmarks of the same type



Landmark Roles

  • Don’t overdo it!
  • Not all lnks are navigation
  • It is assumed that the footer will contain some links.  It todoesn’t need navigation also



HTML5 and Landmark Roles Mapping

  • <main> – role=”main”
  • <article – role=”article”
  • <footer> – role=”contentinfo”
  • <header> – role=”banner”
  • <nav> – role=”navigation”
  • <aside> – role=”complementary”

ARIA support is better than HTML5 support, so use both…for now



Modifying and Enhancing Roles

  • Bad:  <img src=”submit.jpg” onclick=…>
  • OK:  <a onclick=”…”><img src=”submit.jpg”…
  • Better: <a role=”button” onclick=”…”><img src=”submit.jpg”…
  • Best:  <button onclick=”…”>

Always start with native HTML



Always use native, accessible HTML first, then use ARIA to enhance or fill in gaps.  Use controls that convey the correct semantic meaning wherever possible.  Above all, be consistent!



ARIA does not change functionality, it only changes the presented roles/properties to screen reader users.  WebAIM’s WAVE toolbar identifies ARIA roles on the page.



If there’s a conflict between native HTML roles/attribute and ARIA roles/attributes…ARIA wins!

Example:  <input type=”radio” role=”checkbox”>

How is the above code presented to the user?  As a checkbox.




….routes key commands to the browser to allow it to function like a desktop application

Be very careful with <body role=”application”>

Some ARIA elements (tree view, slider, table, tabs, dialog, toolbar, menus, etc.) have an assumed application role

role=”document” should enable reading mode

An example of confusing behavior could be pressing the “h” key opening a help dialog instead of the default jump to next heading.

Paul Schantz comment:  It seems like by invoking application mode, the developer is making two big assumptions:  1) the screen reader user is advanced, and 2) the user is going to use your application an awful lot.

Hans Hillen comment:  use application role when 1) you can guarantee that your app will actually behave like an app, or 2) that this is a highly controlled intranet-style application




<ul role=”presentation”>

<li>menu item</li>…

Hides native roles of elements and all required owned child elements from assistive technology.  Useful on layout tables, lists, etc.

Is ignored if the element is navigable (e.g., links and controls).



Alert Role

  • <div role=”alert”>Read me right now</div>
  • Also role=”alertdialog”

Use this role only for really important alerts!  An alert is a special type of live region



Form field example with a “First Name” field

<label for=”name”>First Name</label>:

<input name=”name” id=”name”><em>(required)</em>

The information about the element being required is outside the form element and its label, so it’s ignored by a screen reader



<label for=”name”>First Name</label>:

<input name=”name” id=”name” aria=required=”true”><em>(required)</em>

A screen reader now indicates the required status of the form element (and that’s all).



Form field example using a Password field

<label for=”password”>Password</label>;

<input name=”password” id=”password” aria-invalid=”true”>

A screen reader no indicates that the field is invalid or broken (and that’s all).

Use ARIA attributes to control styling:

(aria-invalid=true) (border : 2px solid red;)



<input type=”submit” disabled=”disabled”>


<input type=”submit” aria-disabled=”true”>

Disabled HTML buttons are not keyboard focusable and have very poor contrast.



Use scripting to change aria-disabled value, then use CSS to control the visual presentation:

[aria-disabled=true] (color : #999;)

aria-disabled does not disable the button, it simply presents it as disabled to screen reader users.




Indicates element (and all descendants) are hidden from all (???) users.

You can’t unhide a child element.

Use ARIA attributes to control visual appearance:

[aria-hidden=true] (display:none;}



First Name form field example

<label for=”name” id=”fnamelabel”>First name</label>:

<input type=”text” id=”fname” aria-labelledby=”fnamelabel”>

Redundant, but doesn’t cause any problems.  Remember, ARIA always overrides native semantics.  Use aria-labelled by when you already have a textual description on the page.

There were then a few example slides that showed labeling examples with forms, multiple fields in a grid, and so on.



ARIA Live Regions

aria-live=”off | polite | assertive”

  • aria-busy
  • aria-atomic – read the entire region or only what has changed
  • aria-relevant – additions, removals, text, or all
  • aria-controls
  • Special live regions:  alert(important), status (not important), timer(always changing), marquee(same as aria-live=”polite”), and log(updates added to the bottom)



ARIA Live Regions

Some highly dynamic content updates simply cannot be made accessible using ARIA.  Be sure to give users control over content updates



ARIA Lists

A code example was here with <divs> and lists

Could use aria-checked=true|false|mixed to make it interactive



ARIA ‘fieldset/legend’

A code example was here with <divs> and radio buttons

Radiogroup is not reserved only for radio buttons



ARIA Table Caption

<h2 id=”salescaption”>2013 Sales Data</h2>

<p>Sales increased by…</p>

<table aria-describedby=”salescaption”>



ARIA Pop-ups/Dialogs and ARIA Expanded

<a aria-haspopup=”true”>Option dialog</a>

<a aria-expanded=”false”>Expand details</a>



Odds & Ends:  menus, tablists, grids



ARIA Design Patterns for Widget Interaction





  • Adds new features- primarily for application development and enhanced semantics
  • Maintains backward compatibility (mostly)
  • Defines error handling for browsers
  • Drops all (actually most) presentational markup



HTML5 History

A slide with a timeline that contained lots of dates that showed the history (too many bullets to capture…sorry!)



HTML5 Philosophy

  1. Why make authors do something that the browser can do for them?
  2. Things that actually work matter most.



HTML5 Doctype

<!DOCTYPE html>

  • The last DOCTYPE you’ll ever use?
  • HTML versions vs. HTML the “living standard”
  • HTML is very much a work in progress

If you write it and the browser supports it, then you’re good!



HTML5 Simplifications

  • HTML5 is case insensitive
  • Quoted single-word attribute values are not required.  Example <label for=fname> is acceptable
  • Don’t have to self close elements

There were then a series of slides that demonstrated a series of code simplifications, including language, charset, CSS type, script, style type.



The smallest valid accessible HTML5 Document:

<!doctype html>

<html lang=en>

<meta charset=utf-8>


<p>I’m the content</p>

HTML5 allows browsers to do much of the work.  Just because you can, doesn’t mean that you should.



HTML5 Changes

Dropped:  <acronym>, <applet>, <frameset>, <font>, <s> (strike), <big>, <center>

Maintained:  <b>, <em>, <i>, <strong>, <small>, (side comments), <u>, and <cite>



New HTML5 Elements

  • nav
  • header
  • main
  • footer
  • article
  • section
  • aside
  • …and more



HTML5 Sectioning Elements

  • <section>, <article>, <aside> and <nav>
  • Each should generally begin with a heading that describes that section
  • <article> is self-contained, syndicatable
  • The outline presented to the user may be different than the heading structure defined

A blog was given as an example of how the outline presentation might work.  Each blog post title will logically have an <h1> within the page of the post itself, while in a table of contents on the site home page, those <h1> might be shifted to <h2>

If you’re going to use these items, just use proper headings!



HTML5 Accessibility Changes

  • Alt attribute is optional when <figcaption> presents an equivalent alternative for an image within a <figure>
  • Dropped longdesc (subject to change)
  • Dropped table summary
  • ARIA markup is valid
  • <video> and <audio> natively support captioning

More details here on browser support:



New HTML5 Input Types

  • search, number, range, color, url, email, tel, date, month, week, time, datetime, datetime-local
  • New form attributes: – required, pattern, autocomplete, placeholder, autofocus, etc.
  • The browser can (or, more accurately, hopefully will) provide a natively accessible control/interface




Accessibility Technology

The CSUN 2013 Web Track Mega Post

Greetings, fellow web accessibilistas!  (not to be confused with accessiballistas, the little-known and even less-documented accessible siege engine of yore).

As you may have gathered if you followed my live blog posts a couple weeks ago, my interest in attending the CSUN 2013 conference was almost exclusively web-related.  Now that it’s been a couple weeks and I’ve had some time to reflect, I figured it would be a good idea if I consolidated everything into one mega-list.  This year, there were several times when I wish I could have been in two places at once.  Hopefully this gives you a pretty representative sampling of what was on offer web-wise this year.  Follow me @paulschantz for more web-related topics, including accessibility, project management, web development and design philosophy, thoughts on working in higher education, bad clients, off-color humor, and other ephemera.  Enough self-promotion…on with the list!

Pre-Conference Seminar:  Google Accessibility

Day One:  February 27, 2013

Day Two:  February 28, 2013

Day Three:  March 1, 2013

Accessibility Technology

HTML5 Accessibility Support


  • Leonie Watson – Nomensa – @LeonieWatson
  • Steve Faulkner – The Paciello Group – @stevefaulkner

See more here: (link repeated below)


HTML 5 Accessibility:  Where’s it at?

  • Humor:  You laugh now, wait till you join the HTML working group (!)
  • Steve talked about getting people to join the working group.


Where’s all the excitement?

  • Probably the mobile space.
  • HTML is being used heavily in that area.
  • BUT…all the work is still being done on PCs and workstations.
  • …and, the best level of support is still on desktop browsers


HTML5 Spec is BIG

  • As a developer though, you don’t need to know everything in the spec.
  • A ton of it is for User Agent and browser implementations.
  • Leonie:  if you read it front-to-back, you’ll go crazy
  • Stuff in spec now is either in the process of being implemented, or HAS been implemented by at least one browser manufacturer.
  • A great deal of stuff is stable (like the venerable <p></p> tag), but much of it is now.
  • ARIA live regions (assertive) drove JAWS users nuts, so it was pulled from the spec.



Stack includes a ton of technologies, and all these things are married / integrated together.  However, it’s a pretty messy integration and a difficult step for technologists.


HTML5 MAKES USING STUFF EASIER (taken directly from slide)

  • Audio
  • Video
  • SVG
  • ARIA
  • New semantic structures (header, footer, article, etc.)
  • New UI controls (as opposed to HTML4’s limited controls, which encouraged custom widget and plug-in development)
  • MathML

Leonie commented on the challenges to people with disabilities needing to use custom widgets and elements.



  • Date and Time input
  • Local Date and Time Input
  • E-mail input
  • Month input
  • Number input
  • Range input
  • datalist
  • details
  • menu
  • meter
  • progress

Leonie:  support for these new elements is spotty.  IE9 has best support among the various screen readers (NVDA has very good support, JAWS is pretty good too)

  • Browsers need to implement the new controls.
  • Browsers need to implement accessibility suppor for the new controls.
  • …and really, the 2 should not be separate, but they are..

Many of the controls you see in desktop OSes will be gotten “for free” with the new browser controls like sliders, progress bars, etc.  That’s why it’s important that the browsers implement them quickly.



  • MSAA
  • Iaccessible2
  • AX
  • STK
  • + input device support
  • roles, states, properties, interaction

Browser has to provide accessibility to the AT in a robust way.  There’s a mistaken view that AT is holding up web development…this is false.  It’s the browser implementations that are.

Steve reviewed a good slide showing how the API looks, using mechanical typewriter and old telco switchboard.  This was actually a very apt visual description of the state of the browser / AT interaction environment.



  • Screen shot of the “can I use” web site:
  • A good snapshot of what elements each browser supports.  (PAUL NOTE:  if you haven’t already, I highly recommend you check it out.)
When will browsers implement HTML5 UI features in a way that developers will want to user them?
  • …or, more accurately, when will the CSS hooks be implemented to allow flexible, atomic styling of control and their sub-elements?
  • Eventually the controls will have all the semantic elements “built in,” which will make developers’ lives much easier.
  • Browsers are implementing these controls, but developers can’t use them the way they want to use them.


Slide showing examples of audio and video elements (widget controls).  These will really catch on when AT can use the embedded controls.


Slide showing new structural elements in HTML5

  • JAWS and NVDA are neck-and-neck in their support of the new structural elements
  • Navigation with landmarks is now akin to “taking in the page at a glance”



  • Example:  <figure></figure> element allows definition of an image or any piece of content.
  • JAWS and Firefox is the only AT/Browser combo that implements the <figure></figure> tag well
  • This stuff doesn’t just “happen out of the box,” they need to be implemented appropriately.


Slide showing Accessibility API Mapping

  • HTML4, HTML5, WAI-ARIA, MSAA, MSAA+UIA Express, UIA, IAccessible2, etc.

See more here:


Accessibility Technology

Panel: Inclusive Mobile for Everyone – Challenges

This was a panel discussion with several panelists.  Please accept my apologies in advance for spotty / crappy coverage 🙂

Captioning was provided, host asked that people didn’t “company bash”  haha nice touch

Panelists Government and Industry Leaders

  • Holly Nielsen – host
  • Brian Cragun – moderator
  • Bruce Bailey – Access Board of US
  • Peter Korn – Oracle Accessibility guy (missed his title)
  • Rich Schwerdtfeger – CTO of Accessibility at IBM
  • Pirthipal Singh – Team leader of Web Standards office in treasury board of Canada (similar to OMB in the US)
  • Madeleine Rothberg of WGBH
  • Andrew Arch – Assistant Director of government management office within dept of finance of the Australian government

Pirthipal – students want to do everything from a mobile device.  Companies need to understand where their next gen of customers is coming from.  Daisy and Bookshare; eBooks.  Seeing a ton of media consumption and “second screen usage” on mobile devices.

Peter – 3 years at Oracle.  Focused on how big they are.  140,000 empoyees, 390,000 customers, more big numbers.  Have Java tech (ME and embedded via Sun) which is used pretty much everywhere.  Been to CSUN developers.  Co-developed outspoken SR, worked on Java, GNOME, etc.  Worked on 508 refresh group.  We make a lot of enterprise applications, customers want to run them on mobile, so we’re interested in it.

Bruce (on phone) – US Access Board.  Working to harmonize standards with the rest of the world.  Been involved with AT for 20 years.  Moving “up the chain” has removed him from the down-and-dirty of AT, which is a bittersweet thing for him.  Mobile devices are the poster child for why the current standards are unworkable int their current form; hard to apply the standard to them.  508 has a large loophole for commercial nonavailability (tell me about it), we want mainstream tech to have it built in.

Pirth – what we’ve learned from doing accessibility on the web can be applied to mobile.  Developing standards wasn’t enough…we have 106 departments and agencies…need to come together.  Their project is up on github…search for “WET” and you’ll find it.  PAUL – I think this is the repo “Web Experience Toolkit”

Andrew – Australia was one of the first countries to adopt WCAG 1.  Have 4 year trategy for implementing WCAG2.  Had tremendous uptake.  Been working with the web since the early 90s and accessibility for about 15 years.  BYOD is very seriously on the agenda of the Austrailian govt right now.  Some say mobile isn’t web site, so those standards don’t necessarily apply.

Rich – over 20 years in the business.  Development community is excited about working with AT now and implementing it in mainstream devices.  There’s a lot of challenges out there now, how do we educate communities.  Not everything is fully baked, particularly with the web.  For example, iOS doesn’t have a keyboard unless you’re in an input field or content editable area.  Working on projects like IndieUI that can help standardize things like zoom, open, close, without worrying what generated the command.  Many apps are a combination of web and native platforms.  Lots of innovation, but also a lot of challenges.

Andrew – What do you see as the biggest obstacles to business / govt integration of mobile into their infrastructure.

Brian – Security

Richard – yes.  Siri is a great technology, but your requests go off to Apple and that’s a potential security issue.

Pirth – tech is changing so rapidly, some devices have good security, some don’t.  Biggest challenge is not being able to identify, say, the 3 – 5 platforms or devices to support.

Bruce – too much attention is paid to “sexy” tech like Google Glass.  How about just delivering plain old cross-platform services?  (word up, yo – Paul aside)

Richard – mobile browsers have not done all the performance enhancements that you have on the mobile device.  Some things like Dojo are slow when put on mobile (Paul:  dojo is pretty fat, mobile networks are carrying fatter and fatter web sites and apps that seem to assume a desktop browser with a broadband connection).

Madeleine – we don’t know yet what makes for a great mobile interface.  We have to relearn how we interact with our devices.  Need to go back and do a LOT more usability testing.

Peter – we’re tightly connected with 508 and CVAA and anything we adopt is:  what does it mean to require that a mobile device be accessible?  For example:  big screen for people with mobility issues.  Some choices that are good for one device will not be appropriate for others.  There’s a disconnect between the structure of the regulations and the structure of the enabling law.  How do you regulate it?

Andrew – having multiple devices makes the layering of security on top of them a pretty sticky issue.  How many layers do we need to have to keep govt information / citizen’s info safe and secure?

Brian – what are the conflicts we see in the enterprise with BYOD and how do we address those?

Peter – focusing on accessibility component – who buys the accommodation?  do we assume the employee pays out of pocket?  That’s at odds with our idea of what the ADA stands for.  Then there’s the training component.  What if the built-in AT doesn’t meet my needs?  If we stuff a desktop OS into a device (like Microsoft, that may be an option.  But for the most part, that’s an issue right now.

Madeleine – multiplicity of formats is an issue.  Need to be able to push training out to people when they need it.  There are many players, video formats, captioning availability, etc will be an ongoing issue.

Richard – our CIO wants to promote this – move as much toward we-based technology and components that are already accessible on mobile devices.  Example:  Notes mail, put an Exchange server as a front end to notes mail.  We also need to address the functional performance criteria.  Permutations are a challenge.

Audience question – mobile device management – what about policies assigned to specific applications…how do we make use of accessibility as a policy?  For example, certain applications may not provide access (like logins).

Brian – MDM policies need to ba able to be pushed out to the end points.

Peter – a variant of the general problem tied to BYOD.  Certain features may be turned off in certain environment for certain reasons, which can be a problem for some users.  accessibility often requires more

Audience question – is there overlap between what’s being done here and what might be expected within the school systems within the next 10 years?  Obliquely referred to digital divide (who pays)

Madeleine – there is a lot of overlap between the environments (students at school, employees at a corporation).  Some policies in schools are designed to keep kids safe.  Where it differs is the mandatory nature of the funding.  Mandates are in different places.

Bruce – a big challenge is where school systems and govts are selecting / endorsing devices that are or don’t have good accessibility.  What happens when that selection differs from personal user preferences.

Peter – trend toward built-in accessibility doesn’t always meet every need, but that also makes it more affordable for everyone.  If every phone is $100 – $200 and it comes with a built-in SR, that’s really going to make things more affordable and somewhat easier for everyone.

Brian paraphrasing audience question – what are the thoughts on equivalent facilitation that might allow us leapfrog to new kinds of technologies or interfaces?

Richard – The do indirectly.  It’s almost taken equivalent facilitation and putting it on steroids.  We hae equivalent facilitation, and then we have functional performance criteria. Context awareness and adaptation, this is how you meet accessibility on mobile devices (like an iPhone user taking a pic with instagram).  What we are dealing with now is a complex visualization technology.  Our solutions in some cases may not be rich enough to meet every need.

Pirth – Canadian govt is def meeting WCAG2.  Our web apps are optimized for mobile devices, using responsive design, HTML5, WAI-ARIA, etc.  That gets us a long way toward meeting this goal.  The same info services should be widely available.

Peter – equivalent facilitation cannot be emphasized enough (508f) – textual info shall be provided using the OS mechanisms for displaying text.  Java couldn’t do that, and what about UNIX?  There is none.  This is why accessiblity API was developed.  This is how we prefer to do everything.

Bruce – equivalent facilitation comes out of ADA and then was used in current 508. That concept is not going away  Equivalent facilitation is here to stay.

Andrew – IndieUI is fantastic but now here yeat.  Still being worked out, still to be standardized, how to operate.  Devs are asking what do we do, what is our responsibility, where does the repsonsibility of the users start and stop.

Madeleine – 21st century communications video and accessibility act.  Hardware manufacturers are required to make their devices accessible.  If devices come pre-loaded with apps, those tools need to be accessible too (video chat).  3rd party apps are other people’s responsibility.