Accessibility Technology

Lessons Learned: Accessibility Theory vs. Implementation Reality

This is my fifth session from the second day at the CSUN conference.  This description of this session from the event guide says that “standards-compliant accessibility does not always work as expected in real-life implementations…TPG/CGI will share techniques for dealing with inconsistent support by browser and AT products.”  If it’s anything like the other TPG presentations, there will be lots of content and resources…I will do my best to keep up 🙂


  • Hans Hillen, The Paciello Group (@hanshillen)
  • Jennifer Gauvreau, CGI
  • Stephen Cutchins, CGI




It SHOULD work versus it DOES work

CGI and TPG have been working together for about two years and made a choice very early on that they would adopt WAI-ARIA and HTML5.  They’ll cover 3 use cases:  theory, use cases demonstrations and workarounds


Browsers and Screen Readers

  • Time + Budget = Targeted Testing Profiles.
  • Profile 1:  Win7, IE8 and IE9, JAWS (v12, v13, v14)
  • Profile 2:  Win7, FF, NVDA (latest stable build)


ARIA Landmarks

  • We weren’t using landmarks and wanted to use them.
  • Theory:  We had heard that it was easy to implement on existing and new pages, supported regardless of (X)HTML version, a real win-win
  • Reality:  initially worked as expected; as real content was added, strange things started happening.
  • Hans then showed what code looks like both with and without landmarks, and followed up by demonstrating with JAWS 12.  When a field is focused and does not have an aria-label on the region, JAWS (v12) reads the entire content of the main landmark.  IE used all the content of the region as fallback content.  Solution:  add an empty title=” ” tag in the body.


JAWS 13+ announces region before each form field

Solution:  wrap the fields in a <div> or <form> and define role=”form” on the form container.  JAWS stops announcing “region” before announcing the form element, but new issues sometimes appear.

Pair new HTML5 <main> element with ARIA role=”main”

  • Adding landmarks wasn’t necessarily guaranteeing a great and consistent user experience.


ARIA Landmarks: Lessons Learned

  • Need to test at a unit (landmark) and integration (page) level
  • Do no harm
  • You may not run into these issues if you have simple static content.  Most of this stuff crops up with forms and CMS-generated content


ARIA Dialogs: a common design pattern

  • Theory:  WAI-ARIA dialog requirements describe this in detail; it worked as expected with test content.
  • Reality:  when adding large sections of complex content to a dialog, things didn’t work as expected.  What would happen is that the dialog would display the contained content halfway down and focus would be on an element far down the page.

Question:  as a fix, could you make the close button the first focusable element?  Answer:  Yes, but there was a reason why we didn’t go that route (although I can’t remember what that reason was).  Instead, we made the heading of the dialog the first focusable element (tabindex=”-1″).  You can also force the dialog role so that it is read in “document mode.”

ARIA Dialogs: Lesson learned – adapt to design challenges

  • Create POC early on using “real world” content, not short strings of boilerplate text
  • Expand design patterns and authoring best practices to meet new design realities
  • Support the use of reusable frameworks like JQuery UI to design/build once and then reuse from a centralized solution for ease of maintenance


Use case 3:  Icons

Define alt text to make HTML images accessible is perhaps the first accessibility concept every developer learns.  However, as web designers and developers have embraced new methods for displaying icons, we were faced with a new set of accessibility challenges to consider

Requirements:  equivalent text content for  icons used to convey content, status or meaning; allow for user personalization; clients and developers need cost-effective scalable solutions.

Reviewed high contrast mode and user-defined style sheets

  •  HTML images should be used for icons conveying information.
  • CSS background images should not be used to convey content and only used for decorative images or as a redundant visual cue for adjacent text.

Designers prefer CSS image solutions (sprites) because they load faster.  Unfortunately, HTML images don’t inherit high contrast theme.  No fallback text for CSS background images.

Solution: build a High Contrast Mode detection script and use font-based icons.

Test your icon approach

Takeaways:always test your solution in high contrast mode, user defined stylesheet, images disable, css disabled


Key Themes

  • Do no harm
  • Adapt to design challenges
  • Be maintainable
  • Be vocal:  id bugs and tell vendors

By Paul Schantz

CSUN Director of Web & Technology Services, Student Affairs. husband, father, gamer, part time aviator, fitness enthusiast, Apple fan, and iguana wrangler.

One reply on “Lessons Learned: Accessibility Theory vs. Implementation Reality”

Leave a Reply

Your email address will not be published.

%d bloggers like this: