Web Accessibility – The Screenreader Experience Part One

Posted by Brian in Accessibility, Browsers, Usability (October 15th, 2010)

In order to help other developers understand accessibility and assistive technology, I’ve been working on a series of articles aimed at developers. As a slight change of pace, I invite you to experience Twitter through the “eyes” of a screen reader in this short video. You’ll hear what it sounds like when a screen reader reads the text of a page, and you’ll experience what a blind user might experience if he or she encounters a browser popup dialog. You’ll also get a chance to experience what happens when the browser experiences the “spinning beachball” on Mac OSX.

The Screenreader Experience Part One from NAPCS on Vimeo.

Discussion

I want you to know that I used Twitter in this example because it was on my screen when I started recording. These problems aren’t isolated to Twitter. Many, many sites have similar problems. However, there are three things Twitter could do right now which would have made the experience easier.

First, they could provide useful alternate text on the avatar images. They have the ability to know the account name of the user, and instead of “normal”, they could use “avatar for bphogan”.

Second, the main profile page seems to use the Geolocation API to find my address, which I find annoying even without a screen reader because it’s obtrusive. Browsers are required to ask permission to expose my information. Geolocation APIs can get your current coordinates, but that functionality should be handled on the preferences page of the site, not on the main interface page.

Thirdly, navigation that gets me right to the timeline should be available right at the top so that non-sighted users can get right where they want to be instead of having to listen to the contents of the search bar.

Nothing Twitter did causes the machine to lock up during this screencast. I caused that to happen with a script in another window. I wanted you to see what that experience is like, because some JavaScript code can take a while to load, and that can cause the machine to be slow to respond. The screenreader navigates by keyboard, and when the machine becomes unresponsive, keyboard commands get lost in the shuffle and users get confused.

The takeaway from this is that there are issues that people face with these devices. Following best practices like “skip navigation” and better alternative text are a good start for improving the experience, but being aware of other problems will help you much more as a developer than any ‘accessibility checklist” ever will.

Please share your thoughts.

5 Responses to ' Web Accessibility – The Screenreader Experience Part One '

Subscribe to comments with RSS or TrackBack to ' Web Accessibility – The Screenreader Experience Part One '.

  1. Srdjan Pejic said,
    on October 15th, 2010 at 9:35 am

    Wow, it was as painful as I imagined it would be. And by comparison to most sites I worked with, Twitter’s site is pretty clean from the HTML standpoint. I cannot even imagine how a table-based site would sound.

    These are all good tips to remember.

  2. Web Axe said,
    on October 15th, 2010 at 10:14 am

    Great article and demo, thanks. PS: Have you tried the (third-party) Accessible Twitter web app? http://www.AccessibleTwitter.com/

  3. on October 16th, 2010 at 5:16 pm

    [...] Comments View full post on Hacker News [...]

  4. MacRae Linton said,
    on October 16th, 2010 at 11:13 pm

    Why aren’t you using the Alex voice for screen reading? Are you using stock Voice Over?

  5. on October 17th, 2010 at 3:57 am

    solution proposal: http://webreflection.blogspot.com/2010/10/pre-authorization-meta-tag-proposal.html

Leave a reply

:mrgreen: :neutral: :twisted: :shock: :smile: :???: :cool: :evil: :grin: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: