Analysis

What should a screen reader do?

Peter Abrahams By: Peter Abrahams, Practice Leader - Accessibility and Usability, Bloor Research
Published: 4th September 2006
Copyright Bloor Research © 2006
 Logo for Bloor Research

Screen readers have been in the news in the last few months:

  • Apple announced VoiceOver as an integrated screen reader for Mac OSX.
  • Screenreader.net delivered a free screen reader called Thunder.
  • Microsoft demonstrated a screen reader that will be shipped with Vista.

These announcements added to the existing products such as JAWS from Freedom Scientific, and Guide from Software Express. Plus some specific implementations such as the Read Out Loud function built-in to Adobe Reader, the Browsealoud web reader and various text to speech engines such as the Nuance engine in my sat-nav system and SVOX in the Mercedes I desire.

Initially I assumed that all screen readers provided roughly the same function but having tried VoiceOver, JAWS, Thunder and Adobe on various machines at home I realised my mistake. An initial distinction needs to be made between:

  • System screen readers that enable users to navigate around the windows on a desktop, the menus within a window as well as the content of individual windows.
  • Document screen readers that only read the content of a specific type of window (such as Adobe Read Out Loud for pdf documents and Browsealoud for web pages)

So this article is an attempt to describe what a screen reader should do. In the process I will define what the content providers should include to aid the readers to work effectively.

Firstly a reminder as to who may use screen readers. The most obvious group is people who are blind or have severe visual impairments; but other groups include people with dyslexia who find the spoken word easier to comprehend, people trying to understand a second language, and people who need to concentrate on another activity such as driving whilst using a sat-nav.
Normally sighted people use a variety of tricks to quickly read and comprehend the document and extract the information of interest:

  • Looking just at the pictures or headings may get a user quickly to the area of interest.
  • Skipping lists if the detail is not important.
  • Skipping after reading the first few words of a paragraph or sentence.

People using screen readers should have similar options.

Here is a list of functions that I believe a screen reader should have, they are listed in rough order of importance:

  1. Turn machine-readable text into the spoken word.
  2. Do the above irrespective of the format of the document being read or the tool being used to display the document. For example Thunder does not recognise pdf files, and as far as I can make out VoiceOver does not read documents being processed by Microsoft Word on an Apple.
  3. Provide an easy step-by-step introduction to the functions. Given that a blind user will not be able to read any documentation without using the reader there should be some very simple instructions in the setup process as to how to open and start to read an initial document (for the techies amongst us this is like a bootstrap process for a computer). This document should, very early on, explain how to pause, step back a paragraph and then continue so that the user can learn everything from the document without further assistance.
    I am afraid to say that the VoiceOver documentation is appalling; it gives some information about the preferences that can be set but gives no indication of how to sensibly navigate through a document.
    I also had an issue with the Thunder documentation because it is a standard Word document and as I was trying to experiment with some of the features I managed to overwrite some of the document, it would be a great help if the document had been defined as read only.
  4. Any installation process should have voice prompts so a blind person can complete it without assistance.
  5. Read the document with some intelligence. For example there should be a short pause after a heading before the next line is read. Adobe Acrobat Reader 7 does not do this and it can make understanding very difficult.
  6. Tell the user about the structure of the document. For example when a list is encountered the reader should announce this and how many entries there are in the list. This is dependent on the document being created in such away that the reader can understand the structure, hence the need to properly tag web pages and pdf files.
  7. Support navigation around applications and menu structures.
  8. Provide ways of navigating around the document. At the minimum there should be the ability to jump forwards or backwards by sentence or paragraph. Further being able to jump to new chapters, heading levels, or links is important.
  9. Change the accent, speed, volume and tone of the voice with ease and to reasonable settings. Thunder is odd because it has about ten speeds that include sloooow, normal, fast, very fast and six others, which sound unintelligible on my machine.
  10. Be able to read tables and be able to identify a cell by both its row and column labels, including multi-level labels. This needs the table to be adequately tagged with the labels being identified. None of the readers seem capable of reading pdf tables correctly.
  11. Recognise the language being used even when it changes within a document.

Based on these requirements and an initial review here are my comments on the different products:

  • Adobe Read Out Loud reads pdf documents in any environment that Acrobat Reader operates, this means that pdfs are accessible to a wide audience including users of screen readers that do not support pdf. Adobe's design point was to support people with low vision and cognitive challenges. However, its functionality is very limited only supporting the reading of complete pages without any ability to rewind or fast-forward or to use bookmarks to jump to a section of interest. The present functionality means that it can only realistically be used on short documents or for tagged forms. I expect that some improvements will be included in the next release of the products.
  • Apple VoiceOver is so badly served by its documentation that it appears very limited and difficult to use. The news from Apple is that Leopard, the next release of Mac OS, has a range of accessibility improvements. Anyone needing a screen reader should wait and see if Leopard provides a usable solution.
  • Thunder has the significant advantage of being free to individuals, but it has some missing functionality (especially pdf support). Thunder is an important product because it makes computing and the Internet more affordable to a large number of people with visual impairments worldwide.
  • JAWS, undoubtedly, has the most complete set of functions but it is very expensive and hence not affordable for a large percentage of visually impaired individuals. It could also be improved by better documentation and more complete support for tagged pdf.

It is clear from my experiments that screen readers can only do a good job if the document they are reading is adequately structured and tagged. To create such documents requires extra effort from the authors and editors and they will only do it if there is a real benefit to the end user. At present none of the screen readers fully reflect the tagging, and so the end user cannot get the full benefit, and therefore there is little incentive for the creators to put in the extra effort.

The increased competition in this market must be a good thing and I expect all the players to improve their offerings in the next year. With better readers will come increased pressure on the creators to properly structure and tag their documents.

Reader Comments

Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.

5th September 2006: 'Hugh' said:

This article raises important issues, but i'm concerned by some of the concepts being compared here and the suggestion that the capabilities of today's assistive software should in any way be used by today's content authors as reasons to delay or limit implementation of accessible design. Firstly, it's very important to draw a clear difference between screen readers and document readers, they are distinctly different types of product. This article is good at raising the issues about what screen readers should be able to do, but i'm very concerned that people don't mix up these specifications with what document readers should be able to do. Second, i don't believe there is much evidence to back-up the concluding comments which seem to imply that content authors are incentivised to build accessible content based on the range of functionalities of screen reader products, the two areas are in my experience largely unconnected.

Reply to Hugh?

5th September 2006: 'Julie Howell, RNIB' said:

This analysis doesn't compare 'like with like' so readers may find it misleading.

The single most important conclusion that should have been summed up in the conslusion to this analysis is that 'user agents' (from browsers to screenreaders) must be WAI UAAG conformant to ensure the best browsing experience. UAAG are the WAI's User Agent Accessibility Guidelines. When websites are coded to be WCAG conformant, and user agents are UAAG conformant users' chances of having an accessible web browsing experience are greatly increased.

I recommend reading the WAI guidance at www.w3.org/wai

Reply to Julie Howell, RNIB?

6th September 2006: 'Peter Abrahams' said:

Thank you to Julie and Hugh for their helpful comments.
Julie was absolutely right to mention WAI and I should have included it somewhere in my article. However, I have tried reading the specification and I would say that it is hard work, not really suitable for someone who is just trying to choose a reader, and it tends to concentrate on the web. That said it should be read and adhered to by screen/document developers.
I hope that I did make it clear that I was not comparing 'like with like' but was trying to show the differences and similiarities in function between a number of products. All the products are aimed at vocalising the text on a screen that a sighted user can see and read. Therefore they all should provide some of the functions I listed, such as being able to jump back a paragraph and read it again.

In response to Hugh I think I see document and screen readers not as different requirements but rather as points on a spectrum, in my example Adobe is a limited document reader, because it gives you very limited navigation; JAWS is a high fucntion screen reader, but it does not do everything for example at present it does not correctly read complex PDF tables; whereas Thunder is a limted screen reader because it can not read PDF at all.
I agree with him that limitations in screen readers should not be an excuse for not producing well formed screens and documents; but it becomes more difficult for creators to justify extra effort in creating them if there is no technology that properly understand the structures. The community would have a much stronger hand if screen/document readers took full advantage of the effort authors put into structuring and tagging their documents.

Reply to Peter Abrahams?

6th November 2006: 'Doug' said:

Peter, although I have not tried it, I understand the new JAWS release works only with Freedom Scientific platforms.
As far as the lack of pauses with PDF files. Most authors do not put punctuation marks at the end of heads or subheads to give the pause.

Reply to Doug?

4th December 2006: 'Ian Litterick, www.dsylexic.com' said:

You are right that too much to do with accessibility is hard work. Accessibility must be easier which I guess means tackling it on four
fronts: 1) The user agents (eg screen readers) need to get another level cleverer, so that they can detect and use the navigation items, table of contents, flow order etc, without having to be told;
2) Authors need to be trained to include basic accessibility in their original authoring work flow -- e.g. to use styles rather than specific formatting in Word, to add descriptions to pictures;
3) The creation tools need to be more accessibility conscious (e.g.
prompts: "Are you sure you want to scan this just as an image. Reading impaired people may not be able to read it and it will probably not be indexed". "please add a description for this picture").
4) The publishing tools (Quark, Acrobat etc) need to be able to take the accessibility information in source files and pass it through to the final document. Incidental Obligatory Accessibility (I.O.A.) or Accessibility With Out Trying (AWOT) are where it has to go, notwithstanding the law, if accessibility is really to be universal. Standards are a good start but only directly influence those who know and care about standards. A tiny minority. And the standards hardly, as yet, touch my four points.

Reply to Ian Litterick, www.dsylexic.com?

17th March 2007: 'choro' said:

i agree with the article above, coz then how can a blind person can use a screenreader if he or she did not know how to navigate through the help at the firs time ? and isnt we all forgoting something? how can a screenreader can help a blind people if they cant afford to buy the software ? i think there should be a different in price also between corporate and a personal. specially for people with dissability....

Reply to choro?

28th April 2007: 'John Hilbourne' said:

Very useful survey, particuilarly for a pensioner like me who can not shell out £500 or so for Jaws and a nearly equivalant sum for HAL. It still rewquires you have a good knowledge of screen readers before you can understand some of the comments and the implications. I wonder whether if you were thinking or revising this you could do so from the standpoint of a series of "model" readers. e.g Jim who wants to be able to read and Edit text and e-mails from friends
Jane who wants to do this and occasionally surf the net. Julie who wants a screen reader to read say Project Gutenberg texts. John who is a member of a local or national assodfation committee an d needs to read reports, some statitical material and balance shees I seond point is that screen readers are used by people like me who are dyslexic and visually impaired, or dyslexic. We also use Voice dicatona programmes like Dragon Naturally Speaking, IBM Via Voice and those packaged with Microsoft operating systems to name but a few. A comment on the the sues of screen readers for those who are multiply handicaped or have other disabilities would be very helpful. I understand that 56% of the known visualy impaired in UK have additonal handicaps and some of these will make additonal demands on screen readers. But once again, thanks very much this got me thiniing about my needs in ways I had not before and the above are not meant as critcicism but just helpful suggestions from someone who has benifited greatly from what yhou have already done.

Reply to John Hilbourne?

The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.