Accessibility & screen reader 'JAWS'.

April 10, 2013

Down arrow black
to make it up I can let you dunk over me


Operations Director

After being on a project for 2 months to increase the usability of major UK bank’s web site for partially sighted and blind users, I’ve learned an amazing amount. Getting hands dirty at code level we’ve been doing much rapid iteration, prototyping, and user feedback sessions using the most popular of major screen readers “JAWS” from Freedom Scientific to try and improve the experience.

The biggest hurdles have been:

  • JAWS has a very steep learning curve, it can’t be learnt by just “having a go” at it, there are many different modes it can run in, and many different keyboard shortcuts to use depending on the mode it’s currently in.
  • As JAWS is quite expensive, users don’t tend to upgrade, so we have to support versions 9 through 14, which all have very different capabilities.
  • Again, JAWS is expensive, a 40 minute trial is available but with spinning up a development stack taking up to 10 minutes, testing cycles can be tricky.

Tips I’d tell anyone starting with accessibility, DDA compliance & JAWS:

  • No two users use JAWS in the same way. You need to do sessions with real users, not make assumptions on what you think is a good design.
  • No user listens from pages top to bottom, they will use shortcuts to either start navigating an alphabetised list of links, or use a shortcut to jump to the first form element, or use a shortcut to look through page landmarks and major navigation elements.
  • You absolutely must understand what “forms mode”, “auto forms mode” and “virtual cursor mode” are and how to switch between them in JAWS.
  • Use ARIA role tags only if you know exactly what they do, and you must test in JAWS the results.
  • You must be concise in your error messages and form labels. No one wants to hear “User name Username Your User Name” read out to them by jaws because you’ve over-labbeled and over-tagged your code.
  • The basics of semantic html for forms like marking up with fieldsets, legends, labels, and “for” attributes are absolutely critical for a good experience.
  • You can use the style attribute “display” set to “hidden” in CSS to have an element’s content read by JAWS but hidden from sighted users.
  • You can user an aria-hidden attribute with a value of “true” to have an element visible for sighted users but unreachable to JAWS users.
  • Again, brevity of labels is absolutely key!
  • Validators, and focussing on semantic HTML (definition lists), correctly formed HTML, quoted attributes, valid XML, none of this matters. What matters is what comes out of the headphones when JAWS is reading. Your work must be validated against the real world usage and users, - not against a W3C Validation service.
  • What’s happening on screen can be a big distraction when you are using JAWS, the audio and visuals due to the “virtual cursor” are not necessarily in synchronisation. Try turning your monitor off!
  • Get your headphones on!

One of my biggest take away lessons: it can be extremely hard to retroactively make any site work beautifully and elegantly DDA compliant. If accessibility is a requirement of your site, it needs to be bedded in from the start. An example: using large modal “light boxes” for user journeys. This is extremely hard to make these work well with JAWS, no matter what aria tagging you use, it's simply not going to be a great experience for the partially sighted or blind, and this knowledge should feed in to up front design decisions such as “should we be using light boxes for major task navigation paths at all?”

Reason is tech-agnostic and results-driven... every technology we recommend in projects is based on matching the capability to the outcome.