Skip Navigation

Blog » Screen Readers Suck!

Accessibility has now become a major issue in web design. One benchmark of an accessible site is that it works in common screen reading programs. However, screen readers are making the job of conscientious web designers harder than it should be.

Accessibility has been brought to the forefront of the minds of many designers and developers over recent years. In many countries there can be legal repercussions if you have built a site and not made a reasonable effort to accomodate disabled users. One of the most often discussed parts of this process is making your site work with screen readers.

Screen readers are programs that are designed to read the contents of pages and programs to users, so that those with sight problems can still use computers. With most software, they work well. Microsoft Word, for example, works well with screen readers. However, on the web it is a very different story.

(Please note - I am well aware screen readers are very valuable to many web users and am not trying to ridicule them - just trying to help make the people that create screen readers shoulder some responsibility for making the web accessible.)

Screen readers have many problems when it comes to reading websites, aside from just the code used by web designers and developers. It should be simple enough for the makers of these programs to solve the problems with their software, but rather than there being pressure on them to do so, the pressure is on designers and developers to create sites that work perfectly with these sub-par applications.

The first major problem with screen readers and the web is that the web is a huge collection of very different documents. Every page has different code behind it, and every site has its own idiosyncracies and potential problems for a screen reader. Some sites use images without alt attributes, for example, forcing screen reader users to listen to "spacer.gif" over and over again. Some use bad link text, or have huge navigation systems without any method for the screen reader user to avoid hearing that navigation system read out to them, page after page after page.

These specific problems are down to accessible coding, but once you have a site that meets at least the basic accessibiltiy requirements, the problem is far from over. Meeting minimum accessibility requirements does not, by a long way, ensure that users of screen readers (and other assistive technology) will actually have a pleasant experience using your site.

CSS and modern web technologies have systems in place for resolving this issue. Media types in CSS allow you to specify different style sheets for a site depending upon what type of user agent is visiting the site, braille and speech being the two most closely related to accessibility. Using these media types, you can set specific parts of the page to be treated differently by screen readers. For example, you could hide all decorative images or re-order the page so content is first.

The title attribute of HTML allows you to provide more information about an element. Screen readers are not obliged to read the contents of the title attribute instead of the element contents, but it is widely accepted that for most elements in most circumstances the title attribute is very useful. Perhaps the screen readers should read both, or give the user an option. As it is, they allow the user to select whether they would prefer to hear the title or not, but only for links and images - no other elements.

HTTP headers are also designed to allow user agents to determine what content they are returned from a server, specifically with the HTTP_ACCEPT header. Internet Explorer, unfortunately, simply lies about what it can understand in this header, which seems to have devalued it somewhat. That said, the value of the header is immense. If a user agent, such as a screen reader, were to correctly identify what it can and cannot receive from a server, the server would be able to send its response in the best possible form. For example, if you are offering an audio version of an interview in mp3 form, and the HTTP_ACCEPT header was used properly by user agents, you would be able to send a text transcript of the interview to those users who cannot interpret MP3 files. The same applies to much of the content on the web.

Though it would not be ideal, designers and developers could achieve the same thing - delivering content appropriately to user agents depending on what they can use - if screen readers were to identify themselves correctly with a recognisable HTTP_USER_AGENT header. That would enable developers to identify requests from screen readers and send back the correct content.

The excuse generally used is (with both this and the HTTP_ACCEPT issue) that screen readers do not render web pages and are not user agents - they are, instead, simply programs that read the contents of web pages once rendered by a browser. However, there is no good reason screen readers could not modify the values of these HTTP headers before they are sent. Really, there is no good reason the makers of screen readers could not use an open source rendering engine such as Mozilla or KHTML in their products, and become web browsers in their own right as well.

Consider this example - I have a breadcrumb system on a site, using "»" as the separator between the breadcrumbs. I like that symbol, and I'd like to keep using it. Unfortunately, a screen reader will read that literally as "right double angle bracket". This could mean my breadcrumb trail, though it looks nice enough, sounds through a screen reader like: "home right double angle bracket products right double angle bracket betty boop right double angle bracket bobbler". Not ideal - and only really fixable by changing the separator or using an image instead of text - but that is how things currently work.

However, if screen readers were able to understand the CSS media property, I could hide those symbols from screen readers. If the title attribute were used better, I could set it to nothing or "separator", making the breadcrumb trail far more useful. If neither of these were possible, I could at least serve a slightly modified file to the screen reader user, with the symbol replaced by something more useful, based on their HTTP_USER_AGENT.

The irony with all of this is that if screen readers (or rather web readers) were to make life easier, more and more designers and developers would ensure that their sites work perfectly with screen readers. More and more people may well then make use of these technologies.

I can appreciate that there may be financial constraints on the creators of these programs, and that improving how they handle web sites may not be at the top of their list of priorities, but these are still important flaws in screen readers and should be fixed. I can't help but think that if the web design community were to put pressure on the people that make these programs, it would be easier to create accessible web sites. More people would then create accessible websites (or improve the accessibility of their already-accessible sites), giving the users of screen readers a better experience on the web.

Screen Readers Suck!, by Dave Child, was posted on 15 September 2005 and has been tagged with accessibility.