Web Access Centre

Instant accessibility: does it work? - Article - Web Access Centre

Summary: A critical look at the claims made about the accessibility and utility of automatically generated text-only versions of websites. By Donna Smillie, Senior Web Accessibility Consultant, RNIB.

• Introduction
• Myth 1: text only = automatic accessibility
• Myth 2: software can transform inaccessibility into accessibility
• Example
• Conclusions
• Other articles
• Copyright and distribution

---

Introduction

There are a small but growing number of products appearing on the market which claim to be able to produce an accessible website from an inaccessible one. These products are generally:

• Based on the twin premises that creating a text-only version of a site addresses the accessibility requirements of users and the law, and that a text-only version is automatically accessible.
• Marketed on the basis that you don't have to do anything else in order to create an accessible website - simply put your (inaccessible) website in at one end, and get an accessible, text-only version of the site out at the other end.

Oh if only it was all true!

Myth 1: text only = automatic accessibility

Creating a text-only version of a website addresses the accessibility requirements of users and the law, and a text-only version is automatically accessible.

If web accessibility was only about making website content accessible to blind people, there might be some (not much, but potentially some!) justification for this approach. But of course web accessibility isn't just about blind people. And for anyone who has learning or reading difficulties, a site which consists of nothing but text is likely to be something of a nightmare. For many of us, colour, layout and images are aids to accessing and understanding the content of web pages.

What about the need to ensure that both keyboard and mouse users can navigate and access the site content? If the navigation relies on complex JavaScript which can only be triggered by being able to point and click, simply converting the site into a text-only version is not going to address the problem.

What about the need for data tables to be marked up to indicate the row and/or column headings and for layout tables to provide a correct reading order? Will the transforming software guess correctly for the headings? How could it know about reading order for layout tables?

Myth 2: software can transform inaccessibility into accessibility

You don't have to do anything else in order to create an accessible website - simply put your (inaccessible) website in at one end, and get an accessible, text-only version of the site out at the other end.

All of the products produced so far create the text-only version by reprocessing the existing site. One inevitable result of this is that any accessibility problems that exist in the current site are reproduced in the text-only version.

I'm not aware, for example, of any software which, in the process of creating a text-only version of a site, analyses the page content and creates an appropriate and logical heading structure. They all take the existing heading structure and reproduce it in the text-only version.

And images - if you have poor alternative text (ALT text) for the images in the graphic version of a page, the text-only version will use that poor alternative text, with predictably poor results. Any images with no alternative text may simply vanish from the text-only version, along with any information they might contain. With many sites using graphical text for their menus, this means that the navigation for the site may simply disappear completely. At best, there might be a marker to indicate the presence (in the original version of the page) of an image, with, perhaps, a link to the image itself. But that is no more accessible than it was in the graphic version of the page.

And what about Flash? Or Java Applets? While these elements might be reproduced in the text-only version, they will still only be as accessible or inaccessible as they are in the graphical version. And if no text alternatives have been provided in the graphical version, these elements may disappear completely from the text-only version. How accessible is that?

Example

I took a quick look at the home page of a company offering one of these software packages, and used the button provided on the page to view it after it was transformed by their own software.

• All of the headings were coded as H1 headings, exactly as they were on the original version of the page, giving no relative sense of importance to these headings.
• Two link texts consisted simply of "read more" and "find out more" - these went to different pages. Two link texts consisted simply of the name of the product, but each went to a different page. And a "download it" link didn't, as you might expect if you read the link in a list of links on the page, result in a download of the software itself, but was a link to download Acrobat Reader.
• The original page included a randomly selected image containing informative text, plus accompanying textual information. None of this was presented in the text-only version of the page.
  (This was actually because code had been inserted into the HTML code to specify what should and should not be included in the text-only version of the page. It did leave me wondering why one might choose to spend time adding additional code to the page for the text-only conversion software, instead of simply using that time to fix the accessibility of the original page in the first place!)

These are accessibility issues, and their replication on the text-only version of this company's own home page demonstrate the inherent flaw in this approach to accessibility.

While the page I looked at above was far from being garbage in terms of accessibility, the old software adage does still apply, I'm afraid, when it comes to automated production of text-only web pages from graphic web pages:

"Garbage in, garbage out".

Conclusions

Software packages which automatically generate a text-only version of a web page or website are not the "magic bullet" that mysteriously creates accessible websites from inaccessible ones. They may well be useful tools for web managers looking to provide their users with an element of choice in terms of the format in which they are presented with web content. However the text-only version generated by these software tools can, at present, only be as accessible as the graphic version on which it is based.

A potentially simpler alternative exists, though, as a result of the increasingly solid browser support for full Cascading Style Sheet (CSS) design and formatting. Once you switch to using CSS for all web page formatting and layout, you can, in addition to ensuring that your web pages work with different browser settings, provide users with a choice of style sheets, and create stylesheets for different technologies (full size PC and monitor, mobile phone/PDA, etc). If you want to, you can include a "text-only" style sheet as one of the options available to your users, along with a range of different text and background colour schemes, different layouts, etc - the opportunities are limited only by the extent of the web designer's imagination and skill.

Donna Smillie
Senior Web Accessibility Consultant
RNIB

September 2005

Other articles

• GIS and accessibility
• Place-holding text in form elements

Copyright and distribution

Copyright September 2005, RNIB.

You are welcome to copy and circulate this article freely, as long as:

• No charge is made for providing copies.
• Full attribution of the origin and copyright is included.
• These conditions are included.

Back to Articles

For Web Access Centre updates email webaccess@rnib.org.uk

Content author: webaccess@rnib.org.uk

Last updated: 06/03/2008 15:41