Accessibility Technology

CSUN 2014 Web Track Mega Post

As usual, I like to make a post that sums up my entire conference experience…I call this the “Mega Post.”  As you may have guessed from the titles of the sessions I attended, I’m interested in the web track.  If the web is your bag, you just might find all this helpful.



Friday, March 21


Thursday, March 20


Wednesday, March 19


Tuesday, March 18


Monday, March 17

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

WAI-ARIA / HTML5 Accessibility Testing Toolbar

I have to admit that I had no idea what the hell a favelet was, so I Googled it.  Smashing Magazine had this to say, it seemed relevant, so I shamelessly stole it from  Hopefully the copyright gods won’t strike me down:

If you’ve used them once you’ll never be able to work without them. Bookmarklets (or Favelets) are tiny Javascript-Snippets, which are stored within a bookmark and add particular functionalities to the browser you’re using. It doesn’t matter whether you browse, bookmark, look up, search, design or program – depending on your interests, bookmarklets can significantly enhance your efficiency and productivity.

Ok, got it…now this session might make some sense to me.  WARNING FROM THE FUTURE:  unfortunately, I was a little lost in this session until I understood that the presenters were showcasing favelets they built and use to look at and test ARIA and HTML5 elements in the browser.  I must have been in the minority in this audience, ’cause pretty much everyone else seemed to know what the presenters were talking about.


  • Jim Thatcher
  • Suzanne Taylor (works for Pearson)


  • His favelets were inspired by web accessibility Toolbar
  • Make things go faster and be more thorough
  • In IE, they’re saved as bookmarklets
  • Started with images
  • Wanted to provide alerts and alert counts
  • Text size favelets
  • Skip links favelet checks for skip links and whether they will “work” or not in IE6-8
  • Form labels favelet
  • Presented a slide with a large list of favelets, which I won’t transcribe here
  • DOM reader for HTML5 canvas objects
  • Simple example:  simple drawings – short text alternatives
  • Fallback content is supposed to be sent to Assistive Technologies; AT tries to read whatever is displayed.
  • Conditional drawings – dynamically generated text alternatives:  JS draws on canvas, Writes parallel content to the DOM



  • Tracking focus for:  Magnifiers
  • scrolling with text to speech
  • scrolling with voice control
  • support for keyboard access
Landmark favelet demonstrated on Jim’s web site.  Highlights all the landmarks…groovy.  Had a slide which showed which listed all the WAI-ARIA and HTML5 landmarks, another one which listed warnings.
ARIA favelet displays
  • All role attributes
  • All aria 1-* attributes
  • Shows all of these, whether they are coded correctly or not
  • Tabindex=”-1″ (with WAI-ARIA developer coes keyboard access; developer must code any changes in focus)
  • Referenced elements
  • Referencing based on IDs
Slider / Range Favelet and Spin Button / Number Favelet
  • Make choosing numbers more user-friendly
Progress Bar and Scrollbar Favelets
  • If there’s interactivity on the canvas, is that passed via API to the AT?  No, you pass it to the DOM, which then passes it to the AT.
  • Is it valid HTML to put any tag into Canvas?  Yes
  • Are favelets screen reader accessible?  Long answer that eventually got to “yes”
  • Which browsers show ARIA?  All show some, but they’re not consistent.



%d bloggers like this: