Accessibility Technology

Responsible Design: Accountable Accessibility

Arrived 10 minutes late, so

Bill Gregory – CGI – @thebillygregory

As a web developer, I took on responsibility for coding accessibility into my projects

When good enough stopped being “Good Enough”

  • Spent more time planning code up front, which lead to less time fixing later
  • Questioned everything on the page, made sure it was documentes
  • Wireframes became my recipe, I refused to  cook without them
  • Always assumed at least SOME level of accessibility

Own your code

  • Real lessons in teh stuff you did wrong
  • Every gbug could be a chance to learn something you didn’t know before


Top 10 things I can do that I have complete control over

  1. Semantic mark up
  2. ARIA landmark roles
  3. Lists and the many ways we can use them
  4. Skip links
  5. Focus
  6. Headings
  7. Forms and labels
  8. Alt text
  9. Hidden text
  10. Testing



How do you approach a dev when they come to you to learn “after they’ve already done everything?”  When baking chocolate chip cookies, you bake the chocolate chips into it.  If you add them afterward, it’s not a chocolate chip cookie, it’s a cookie with chocolate melted on top of it.

Missed a few questions ’cause I was listening and not typing…sorry!


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

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

WCAG Guidelines – What about the Users?


  • Birkir R. Gunnarsson, Blindrafelagid; The Icelandic Organization of the visually impaired @birkir_gun
  • Hinni Hreinsson, The Stockholm Low Vision Center @hm_hreinsson

BIOVI (Blindrafelagid, Icelandic organization of the visually impaired), similar to NFB in the US (details directly from slide)

  • Fights for independent and responsible living conditions for visually impaired people
  • Fights for their secured equal rights and opportunities to respnosible, active and recognized participation in all sectors of our community
  • Part of a public medical service of Stockholm County; 80 staff in 5 teams
  • Birkir does audits and makes development recommendations
  • Hinni trains users on AT
  • Discussions between Birkir and Hinni revealed that their best practices recommendations did not always make it to AT trainers and end users


  • Delivering web content requires 4 players
  • Accessible web site
  • Browsers that render content and build DOM
  • (missed a bunch of items from this slide, sorry!)

To summarize (Paul’s description, so it’s probably butchered):  this is an outreach effort to get the word out about the roles of headings, landmarks, navigation hotkeys, etc.  Wanted to create a survey to help develop a vendor neutral guide to help explain how you can use a screen reader to effectively read web pages.  This would benefit users at various stages of screen reader competence.


  • 1,700 SR users
  • 2/3 of SR users consider themselves advanced Internet users, only 2% consider themselves beginners
  • Users keep their SR up to date
  • (missed details on this slide as well…will try to post link to WebAIM survey results)


  • Many users run multiple screen readers
  • Most have one up-to-date enough to read landmarks
  • 20% received formal training
  • Close to 80% use their SR web page summary feature


  • 60% are familiar with headings and use them for page navigation
  • 60% use navigation hotkeys to browse tables on web sites


  • Most users learn how to browse on their own, with little formalized training
  • Much of user base still relies on TAB and ARROW keys to navigate a web page.
  • Users also use the page description element of screen readers


  • Web developers:  use markup clearly and efficiently
  • W3C standards:  consider a set of more clear specified landmarks
  • SR Vendors:  include landmarks in web page summary features
  • AT instructors:  can we reach out to more users?
  • Make sure AT instructors teach effective browsing techniques

Create educational web resource that would be a simple online user manual on how to effectively navigate web pages.  This would include relevant navigation hotkeys for all screen readers.  Will be written first in English, then translated to Swedish and Icelandic.  Information would be updated as needed.  Possibly have WCAG certification or an associated accessibility statement that links to this resource.

Results will be released at an EASI webinar on May 2nd, at 2pm EST (US Eastern Standard Time).  Sign up at http://easi.cs

%d bloggers like this: