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

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.



Accessibility Technology

Using WAI-ARIA to Make Typical Pages Fabulous

Another IBM presentation:  “How to go beyond adding WAI-ARIA landmark regions to radically improve the accessibility of ordinary web pages by thinking of them as rich internet applications”


  • Matthew King
  • Mary Jo Mueller
  • Bill Curtis-Davidson

HTML is good for documents and static forms, but not good for modern rich web sites.


Landmarks indicate what’s on the page and how it’s organized.  Only put inside of a region those things that belong in a region.  WAI-ARIA landmark roles are:

  • Banner (header)
  • Search (search tool)
  • Navigation (links)
  • Main (main content of page)
  • Form (collection of form elements)
  • Complementary (info related to main content)
  • Contentinfo (footnotes, copyrights, privacy statements, etc)
  • Region (content where no other role is applicable)
  • Application (software unit embedded on the page – not recommended)

Main region is the most important and needs to be created for every page (before and after screen shots of a page were shown)

Don’t create orphaned content – content that’s not included in any region, or relationship to other elements on the page are lost.


  • “Make keyboard navigation more like a desktop application experience”
  • Study the visual layout and group
  • With effective grouping, the tab ring of the page collapses dramatically
  • Support up and down arrows in vertical groups (showed a megamenu with categories of links within the menu – sort of like the CSUN home page)
  • QUESTION:  can you put other elements into a megamenu besides navigation elements?  Yes, you could put (for example) a search field in it.
  • Support left and right arrows in horizontal groups (i.e. – tabs, toolbars)
  • Blocks of elements that appear tabular may support all arrows
  • Don’t forget the visual focus indicator
  • Skip the “skip link” it just eats up one more tab stop; designs a “tab ring” so short that skip links do not add value.  The method for skipping large block of becomes tab itself.  Showed a slide with a horizontal group of tabs:  without horizontal grouping you have 9 tab stops, with horizontal grouping you have 3 tab stops.


  • Learn standard keyboard patterns for:  menubar with submenus, menu and menu button, tree, toolbar, grid, dialogs containing menus and other widgets
  • With appropriate widget choice:  perfectly map virtually any navigation scheme, equally efficient for all (keyboard or mouse, visual or non-visual)

QUOTABLE QUOTE:  “This is a designer’s job…interaction design is the magic”

Menubars with pulldown menus should work just like they do on the desktop.  A good example is  This was a powerful demonstration of how  much WAI-ARIA affects navigation within a page.

Since JAWS 12, opening a dialog allows you to easily navigate confined tab rings.

Even though they look like tabs, in most cases it is better not to use WAI-ARIA tablist and tab roles.  Site nav links that are styled to look like tabs usually don’t work like tabs


After identifying elements with correct landmark or widget roles, ALL, with few exceptions, should be labeled and related to any describing elements.

  • Use aria-labelledby whenever possible
  • Re-use of strings simplifies maintenance, translation, etc
  • Brevity is key:  aim for 1 or 2 short words, 3 tops; do not use role names in labels i.e. “site navigation” for a navigation region; do not put instructions in labels “press enter to…”

A slide was shown with examples of labeling and describing elements, good and bad

Use labels on multiple regions of the same type; some powerful examples:

  • Composite labels
  • aria-labelledby multiple IDs
  • May self-reference by including ID of element being labeled
  • May have both aria-label and area-labelledby on same element
  • browser automatically concatenates in specified order


Success is in the minutia; implement design patterns thoroughly

Implement WAI-ARIA prperties per design patterns:


Lost visual focus = lost user

  • Is the new focus location logically what user would expect?
  • Telling non-visual user useful information?
  • Making the task efficient?

Pay attention to where focus moves

  • Elements need to be able to receive focus (menuitem, treeitem, button)
  • If a parent or child element has focus instead, it may not work correctly

Best practice is to have one role per element

“Code to the spec, not to the test tool or assistive technology”  GREAT ADVICE

  • WAI-ARIA spec clearly states intended use for each role
  • Purpose is to communicate the intent of UI element to assistive technology
  • Use role only to communicate WAI-ARIA specified intent
  • Do not re-purpose roles to “fix the issue” or manipulate AT behavior
  • If AT does not behave as desired or expected:  may be incorrect design or bug in your code, may be incorrect expectations, may be bug in browser, may be bug in AT


WAI-ARIA can dramatically boost accessibility and be as desired by PwD as anyone else

%d bloggers like this: