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

Accessibility Technology

Making Mobile Both Accessible and Secure


URL for slides (you’re gonna need it, the slides have thousands of bullets and I couldn’t possibly capture all of it here):

  • Costs to business of incompatible mobile secrity and accessibility?
  • Weak links
  • There are security gaps to be checked for


  • BYOD
  • Examples of inaccessible security
  • Risks of inaccessible secirty
  • Risks of non-secure accessibility
  • Items to consider when implementing a secure accessibility
  • Challenges you’ll encounter

A whole slide of disclaimers:  how IBM is approaching this topic, conclusions are based on anecdotal experiences, etc.

Risks related to inaccessible security:  biggest risk is the human element

Some interesting stats on BYOD::  most enterprises have personal devices accessing corporate resources, 89% of IT departments support them, but 46% are unmanaged.

Accessibility and Security don’t always work together; we start from a foundation of risks (508 and other intl. legislation).  Showed a slide of big corporations that had litigation against them, Target, Netflix, Google, etc.  Yes, the “risk” is real, but of course we all know that corporations should do accessibility because it’s good for business AND it’s the right thing to do.  Presenter Talked about brand, what it’s worth to your company, that sort of thing.  Sadly, the presentations I’ve seen given to corporate audiences seem to be driven primarily by fear and pursuit of the bottom line.  This presentation (so far) is following that line.

PDFs recently had an issue where secured docs could be read with a screen reader.  Within IBM, Antivirus could not be used by blind employees, so they needed to use an alternate AV program.

QUOTABLE QUOTE:  “If a security test fails an individual’s capabilities, it fails as an implementation.  If a security test fails the situation, it fails as a solution.”


  1. AT do not function correctly in a secure env
  2. Unverified AT leave exposures to secrity
  3. Security is unusable
  4. Secure solutions may not be able to be retrofitted for accessibility

They had a complicated slide that showed “10-Steps to security”

Slide with a triangle containing:  Accessibility, Security, Enterprise

Embed standards into the enterprise (mandates, processes, guidance, metrics, education, documentation, tools)


Slide about platforms:  OS, Hardware, carrier, AT

Slide showing a pie chart of platforms, there were about 50 (completely unreadable, but did show the scale of the problem)


  • AT (SR, Zoom, preconfigure, dev tools)
  • Security (platform settings, policy, partitioning)


Siri is a problem because “we don’t know what happens to that spoken utterance, it doesn’t stay on the device, it goes to what we’re told is a secure server.”

QUESTION:  what about captioning and transcription services?  These fall into the same bucket.  Concern is the unknown about “who’s wearing the Siri face” right now.

Evaluate AT for security

  • Does it run correctly when the security is engaged?
  • Have artifacts that leave unprotected content (logs, buffers, off-device processing, transmission, secure processing, is encription adequate
  • Does it work in public / private situations?
  • Does it require a network connection?

Accessible Authentication

  • Pwd length, complexity, time-outs, alternatives
  • Biometrics:  consider cost, environmental considerations, alternatives
  • Graphical pwds (not suitable for device without a mouse or touch-screen access


  • MDM, Security, Enterprise Applications
  • Bare metal vs. Hosted (type 2 like VMWare)
  • Container virtualization (i.e. Enterproid Divide), similar to UNIX chroot solution
  • Have to assess these solutions for accessibility

Paul’s sidebar regarding the “model” of IBM presentations:  they provide lots of big-sounding questions and problems, present slides that are overloaded with gobs of information, focus on compliance (often injected with fear), but not a lot of practical information.  Ya gots ta pay for that stuff, buddy.

IBM uses “Worklight,” a tool that sounds similar to PhoneGap, but it comes with a lot more under-the-hood stuff for policies, server interaction, endpoint management and management of services, etc.

Enable, monitor, and enforce compliance

System settings, software inventory, software distribution, automation, monitoring, reporting, taking action

Slide:  Rapid transformation of change (loaded with literally a hundred items and completely unreadable.  Again, shows just how complicated things are)

Mobile standards are lagging growth

New hypervisors have been announced by VMware (type 2) and Redbend vLogix Mobile (type 1)

10 new MDM solutions reported May 2012

Retrofitting is expensive and may in fact not work at all

Accessibility Technology

IBM’s WCAG 2.0 Compliance Web-Costing Model

  • Phill Jenkins IBM Research, Human Ability and Accessibility Center
  • Dan Shire IBM Ineractive, IBM Canada

Why this presentation?  Our experience with Government of Ontario is relevant to organizations and web sites trying to estimate the costs of accessibility.

Questions that need answers:

  • What does it take to make a website accessible (from scratch)?
  • What does it take to keep it that way?
  • What are the opportunities and challenges?

Project Steps

  • Identify candidate sites and sample pages
  • Assess sample pages for accessibilty
  • Estimate cost to test, repair and maintain
  • How to apply project experiences to sites and policy

7 week timeline

Slide showing an IT project life cycle showing user-centered design.  UX, including accessibility and support for inclusive design, should be at the heart of your project – this can be integrated into every phase of the project.


  • “Most organizations take several runs at procurement before they get it right”  This is a true statement and I agree with it.
  • “How many of you work in corporate IT departments?” (several hands raise)  “Many of your colleagues in government and higher education wonder why it costs so much to make things accessible.  In those environments, you take care of the HTML and CSS and you’re done.. it costs so much more in corporate environments because those environments are very risk-averse.”  I find this characterization suspect.


  1. Look and feel:  expensive to update – design and significant coding changes.  If you get accessibility wrong, it can be broken everywhere.
  2. Content can be relatively dynamic and change frequently.  Compliance can be a problem.

How often do organizations refresh their sites?  Varies, but roughly every 3 years (evidence is highly anecdotal)

99% of businesses are small and medium sized business (less than 200 employees)

Provided a very detailed description of IBM’s analytical approach to their testing methodology, with breakdowns of costs of web accessibility remediation, with hours of effort by role…

…and it was at this point that I couldn’t take any more and walked out.  Everything they’re saying is true, but my god, I think IBM can make anything mind-numbingly boring.

Accessibility Technology

Agile and Accessibility Case Study

Karl Groves @karlgroves

Agile and Accessibility:  Theory and Reality

Ceiling Cat and the SDLC (he watches you as you do waterfall project management – Google this meme…not as good as Cat-Breading, but still funny)

The further you get down the path, the less likely you are to get accessibility into the plan (if it’s not part of the plan to begin with).

The agile manifesto:  “We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value…”  Go here and read it yourself:

How do agile and accessibility work together?

  • Definition of done:  do tests pass?  If yes, we’re done!
  • Inherently user focused (as a user x, I should be able to do y, so that I can accomplish z)
  • Inherently quality focused
  • Inherently collaborative (pigs and chickens story, referenced here: )
  • Tools and techniques (Test Driven Development)
  • Daily standups
  • Definition of done
  • Fortune 100 Healthcare Company, 36.5 billion, 40,000 employees
  • SDUF (Some Design Up Front), some spec work done up front
  • 95 initial renderings
  • 9 page types
  • 10 sub-page layouts
  • Slicing up designs and assets into working HTML


  • A11y team members assigned to several scrum teams
  • Development and testing
  • We deviated from the process (triple quality constraint Cost, Scope, Time)
  • We underestimated the scope and resources, untrained resources
  • Executive staff unwilling to adjust to meet evolving needs
  • Agile fall?


  • William James: A chain is no longer than its wekest link, and life is after all a chain
  • You need the knowledge and skills, or you can’t be effective
  • You CAN integrate accessibility into any process
  • Time spent up front building accessible components and patterns is good accessibility ROI (still expect to refactor); that is, the 95 initial renderings


  • One way to get accessibility win, create an accessible.css file that contains all the stuff you need
  • Develop a detailed User Interface Model up front, which helps to standardize the interaction model.
  • Ratio of accessibility members on a team:  at least one should be functioning as a SME.
  • Why can’t we standardize on a particular framework / approach?  Start contributing to those projects that have made the most progress.
  • Leonie talked briefly about the UK government’s success with their site rebuild



Accessibility Technology

Be the Fireman, Not the Cop

John Foliot @johnfoliot /

Laying the groundwork for online accessibility success in a large environment.  Boy, this is something I can relate to 🙂

QUOTABLE QUOTE:  “Close only counts with horseshoes and hand grenades.  Perhaps web accessibility compliance should be added to that old saw.”


  • Lack of accessibility planning / pre-planning
  • Stakeholders already on the defensive
  • Tight deadlines
  • How much does it cost?  No budget allotted
  • Content being developed for the web was never designed with web accessibility in mind
  • Sum Total = Resistance


How does it manifest?  Confrontation, rejection (doesn’t apply to my content), avoidance, insincerity.


Takes a cultural shift, and requires good communication and communicators.  He read Malcolm Gladwell’s The Tipping Point.  From this, he realized that you need to find the “Connectors.”  They know everyone, have done everything, and have the institutional knowledge.  Also need to identify the “Mavens,” who in our case are the hard-core geeks who do the implementation; they’re the early adopters.  Also need “Salesmen” as well, provide boosters, promoters, persuader, helper (enthusiasm).

COMMUNICATION SKILLS (directly from slide)

  • Be likable, and stay positive
  • Connect – find mutual points of interest (be sincere)
  • Solve problems and build trust.  Teamwork starts with you.
  • Create positive experiences and make learning fun! (i.e. – things are challenges, not problems)
  • ID and work with the Connectors, Mavens, and Salesmen
  • Tackling technical challenges, such as using a publishing and tracking system like Drupal, CQ5, etc.
  • Select a tool to track bugs like Bugzilla, Mantis, Trak
  • Use frameworks like jQuery and Dojo
  • Consider custom tools (when necessary).  Example given was Stanford’s caption tool.
  • Look for ways to automate processes to make user’s lives easier
  • Evaluation tools (Deque Worldspace, SSB BartAMP, IBM Rational Checker, WAVE).  The reports these tools are kind of like a report card.
  • Provide detailed expectations of outcomes, not process (don’t tell them HOW it’s going to be done).
  • Set realistic goals
  • Encourage creativity (your users will have some great ideas)
  • Lay out the efforts as challenges, not consequences (tell an engineer you can’t figure out a problem and then walk away)
  • Pursuit of quality:  don’t let perfect be the enemy of good
  • Set timelines and milestones
  • Celebrate successes!
  • Foster empathy and understanding (brown bag events – invite actual users with disabilities)
  • It will cost money (you can pay me now, or you can pay me later.  Eventually, you have to pay me)
  • Be honest about what it’ll take
  • Scaled question – the longer you delay, the more it costs
  • Transition towards a team based approach (PM, tech team, Design and UX, Marketing / Content Department
  • Identify bottlenecks for each group independently
  • Establish training and internal resources
  • Motivation (internal awards, recognition, etc.
  • Document knowledge internally with a wiki or Knowledge Base
  • Be consistent in your implementation
  • Accessibility is a governance issue and a shared responsibility
  • Appeal to pride versus fear (your efforts matter and reflect well on the institution, we’re the best, that sort of thing).  Audience members commented on tying accessibility to something that matters to the organization.  An example of this might be brand.
  • Get some policies in place:  work with existing standards; avoid re-inventing the wheel.  Again, there is no such thing as perfect.
  • Legal threat is heavy-handed and should only be used as a last resort
  • There was some discussion regarding the involvement of lawyers.  My own commentary (not voiced) is that people only hate the lawyers because they make the rules and know ’em well.
  • Avoid the checklist mentality
  • Avoid appearances of concessions and sacrifices
  • Avoid the brick!  (Giant report)
  • More than just a QA process, multiple rounds of accessibility testing
  • Work with milestones, test early, test often
  • Be specific in what you ask for, generous in what you accept
  • Celebrate successes and recognize efforts great and small (this does matter)