Clean, crisp, accessible HTML – why not?

By Gareth Powell

Web developers and designers continually face choices about the web sites that they build. Often it seems that obtaining a desired look forces the design away from standards or making an accessible website automatically makes it “boring”. In actual fact, these are false choices, and especially with the advent of more standards-compliant browsers, it’s possible to construct fully standards-compliant Web sites with great accessibility.

I’m not going to claim that simply reading this paper will transform all your inherited, legacy sites into beautiful models of standard accessibility, but at least it should help make the issues clearer.

What does accessible even mean?

While accessibility means different things to different people, it can be summarized simply by saying that every user out there should be equally welcome at your site. That if you’re selling something – anything from widgets to airplanes – you aren’t accidentally stopping someone from making a purchase because of the way your site is set up. That your e-government site is not discriminating against senior users because font size cannot easily be enlarged. And even that the sign up form for your social Web app does not jump crazily when moving between fields using the keyboard.

While there’s a range of disabilities that can prevent someone from fully engaging with your site, by far the most common – and most impeding – is severe visual impairment: blindness or something close to it. Because the web is primarily a visual medium, with text images, layout, links and interaction all basically defined visually, it is very difficult for blind users to interact with it at all.

Other individuals whose needs need to be considered are those who – because of some motor impairment – cannot use a mouse and must interact and navigate websites using only a keyboard.

Although there are other groups whose disabilities degrade their web experience, these issues are much less common and affect a much smaller portion of the experience. Because of this, this article will deal almost exclusively with the issues associated with individuals who cannot see the screen, or cannot interact with it using a mouse.

At a technical level, there are two major definitions of what it means to be accessible: the US Rehabilitation Act, Section 508¹ which specifies the accessibility requirements for web sites built for US government agencies, and the Web Accessibility Initiative’s guidelines on accessibility (WCAG) . While these express concepts in different ways, the basic messages are the same, and, in general, conforming to the WCAG² recommendations will result in pages that conform to Section 508.

Some of the accessibility requirements (such as mandatory alt text) are part of the basic HTML standard, and non-accessible pages will thus be reported as invalid HTML.

How blind users experience the web

Fairly obviously, blind users cannot see the web content on the page. Instead, what they need is a tool called a screen reader to literally read it aloud to them.

One such screen reader is IBM’s Home Page Reader³ ; while for Firefox users there is a “voicing” plug-in called FireVox⁴ .

These products look at the web page that has been accessed and literally start at the top and work their way through the page, reading every word until they reach the end. Of course, the user does have some control over this process – they can follow links, skip between sections by jumping to the next header, navigate tables and forms using the arrow keys, back up to earlier text and so on. But the process is essentially linear – they cannot take in the whole page in one go as sighted users can.

Non-mouse web interaction

The usual method of interacting with a website is to glance at the page, dismiss the unimportant stuff, and use the mouse to scroll to and click on the interesting content.

If you can’t see the screen, or if you can’t use a mouse, this method of interaction is not available. Blind or vision-impaired users generally find a mouse of no value whatsoever: they cannot follow the focus point – the cursor – around the screen.

Instead, these users have to interact using just the keyboard, which leads to a much more complex experience. In particular, it requires that the user navigate around a page using specific keystrokes to jump to “the next element” (of a particular type). In fact, one of these operations is quite common among all users: the tab key navigates to the next “active” element, that is, a link or form element.

In order to make the experience more practical, most screen readers offer keystrokes to move through the page based on other context. For example, FireVox has a keystroke (Ctrl-Shift-H) which pops up a list of all the heading levels used in the document. Each level is a submenu in its own right, and lists all the headings at that level in a document. Depending on the document and the level, this can be overwhelming in its own right, but, with correctly semantically prepared documents, is a great advantage over reading the whole document!

Duplicating the experience

In the abstract, this can be all pretty hard to understand. How can you duplicate this experience as a sighted web developer?

Well, it is entirely possible to download the same tools that visually impaired users will use – FireVox for example is a free extension – and try navigating your site with your monitor turned off and your mouse unplugged.

It probably won’t take very much time doing that before you appreciate the need to build an accessible website (if you didn’t already!) and want to move rapidly towards adopting the appropriate standards. Once you’ve understood the issues at play, you’ll want to move back to using your mouse and monitor.

It is also possible to use Lynx⁵ , a text-only browser, to see a visual representation of what the screen readers will encounter and attempt to speak. This gives a version of the content which is more easily grasped by sighted individuals who are used to grasping the meaning of websites by using the graphical layout.

How it works

Screen readers work by examining the content of a web page – these days, that will be the DOM version of the downloaded content, and turning it into a form that can be spoken. The easiest such rendition is to linearize the page and speak all of the words on it in turn.

This analysis of the document is an analysis of the content of the document, and not the way it is rendered by browsers. While two different source codes could render the same visual effects, they could be completely different at the markup level, and thus be analyzed completely differently by screen readers. For example, when generating a list of headers, the reader is looking for specific h1, h2, etc. elements; not for text which is marked up in bold. Although these two elements may appear the same on the screen to sighted users, they are fundamentally different.

How XHTML provides for accessibility

After the initial success of the web, it became clear to certain individuals and groups that generic web browsers and web sites were not accessible to several groups of individuals with disabilities. In particular, the high dependence on images for navigation, the use of tables to lay out pages, information about content being “buried” in specific formatting (generally using the font tag) and poor formatting of form elements meant that many pages and sites were simply impossible for blind users to navigate, understand or interact with. Currently, over 90% of the Web sites are non standards-compliant, which automatically means they are not accessible at all. Add all the non-easily accessible media, such as Flash or Silverlight, and you realize that the Web revolution is indeed leaving many literally in the dark.

A number of W3C working groups decided to tackle these issues alongside other issues such as modern technologies and browser compatibilities, and produced an updated version of HTML (4.01) as well as a new XML compliant version of the markup language (XHTML) which were intended for describing content, and a new, separate language for defining style issues separate from the logical content (CSS). All of these were designed with the intent of providing the greatest support for designers to build accessible websites.

Of course, XHTML and CSS making provision for designers to build accessible websites does not mean that they will, but at least the features are there, ready to be used. As browsers work towards an ever-improving implementation of these standards – both IE8 and Firefox 3 are treating them very seriously – attractive, engaging, accessible websites using web standards can now be built that work across modern browsers.

Handling visual content

The majority of visual content on web pages is in the form of images. This is largely what makes users judge a web site as “interesting” or “engaging” rather than “boring”. However, the fact is that screen readers cannot automatically turn a picture into words, even when the image is just a beautifully styled word (such as “Search” or “Go”).

To address this issue, images have an alt attribute (which is a required attribute in valid XHTML documents), which enables them to provide “alternative” text which will be displayed (or spoken) when the graphical images cannot be rendered. There are three common cases:

When a screen reader is in effect, the alternative text will be spoken;
When the user is using a text only browser (such as Lynx), the alternative text will be displayed in place of the image;
When the user has turned off images (usually for performance reasons over a slow connection).

In each of these cases, the same alternative text will be displayed, which therefore needs to provide “equivalent” information as gained from the image.

What counts as “equivalent” information? That depends on the role of the image.

If the image is simply there as “eye candy”, that is, if it serves just to make the site more visually appealing, the alternative text should be nothing. Because the alt attribute is a required attribute on all images, specifying no alternative text is done by using the attribute value alt=””. Note that it is important not to put any other characters there (such as “ “ or “ ”) as these can confuse some screen readers, which will then read aloud “space”.
If the image is presenting a link or a button choice, then the alternative text should say where the link is headed, or what will happen when the button is pressed, for example “search”, “submit”, or “buy now”. Remember that while there is value in clarity, there is no value in verbosity – screen reader users, already slowed by having to listen to content, will not thank you for having to listen to “this is your opportunity to buy now” rather than the more concise “buy now”. If in doubt, download a screen reader and try it for yourself!
If the link is presenting information, or a heading, the alternative text should communicate the same information, again, as succinctly as possible.
Finally, note that when an image – or link – appears to present information, but in fact is a duplicate of text right next to it (for instance, the image of a question mark, with the word “help” next to it), these two should, if possible, be contained in the same anchor tag, with the alternative text for the image being blank: in reality, it’s merely eye candy.

In addition to the alt attribute on images, there are a number of other attributes which have been added to XHTML to improve accessibility:

longdesc: provides a long description for an element. While users will generally not wish to listen to the long description of all the images on a page, if the image is particularly interesting, they may choose to listen to it. Specifying longdesc text gives them this option.
caption: provides the opportunity to describe the purpose of a table for all users. But in particular, this provides visually impaired users with a summary of the purpose of the table, without requiring them to listen to the descriptions of all the row and column headers.
summary: provides the opportunity to describe the contents of a table for all users.

Finally, note that alternative text is not just for images: it is supported on a range of other content tags, especially object, providing the opportunity to tag other content such as audio, which is not accessible to deaf users.

Using CSS styling

One of the biggest issues with accessibility is Web sites that have a superficially elegant appearance, but that appearance is cobbled together using a collection of tags which produce visual effects without communicating any intent in the document. This leads to significant problems for assistive technologies such as screen readers, which are unable to “reverse engineer” the site’s formatting and extract the semantic content that really matters for them: they are reduced to scanning the page one word at a time, unable to distinguish between styling markup and actual content.

Instead, Web sites should be designed content-first. The physical layout of the page should naturally flow from its intended structure. In this way, the main page heading should be inside an h1 tag; section headings on a page (such as Navigation, Content, etc) should be marked up as h2; and so on.

CSS styling can then be applied to these elements to obtain the desired visual effects. With appropriately marked up content, this task actually becomes easier, since the tag name can be used rather than more specific class or id attributes. By enclosing the content in appropriate blocks (see below), additional styling can easily be obtained by using the context-based features of CSS.

CSS can also help in resolving the apparent conflict between content intended for sight-impaired users and the “normal” content display. Content intended only for vision-impaired users can be associated with the CSS style “visibility: hidden;”. This content is not displayed on the screen, but because screen readers look at the content, not what is rendered on the screen, this content will be read out.

Using CSS layout

Tables exist in HTML to present tabular data, such as information about schedules, rates or the weather. As such, they are expected to have heading rows to provide context as to the meaning of a particular entry. Assistive technologies have special modes to deal with tables and assist visually impaired users in understanding, interpreting and navigating them. Making these tables accessible is discussed in the next section.

Tables are also used (out of convenience) to render layouts. The main reason for this is historical: the only way to accurately position content on the screen before the advent of CSS was to use a table. However, even since CSS has become widely available, a number of issues, mainly concerned with the erratic adoption of CSS in successive Internet Explorer incarnations, have left many developers continuing to use tables for layout.

This presents a major challenge to assistive technologies however. When faced with table-based layouts, there are two choices: ignore the layout altogether and just proceed through the cells (usually repeatedly across the rows, slowly moving down the table), or to treat the table as a data table and try and understand its meaning.

Neither is a particularly attractive option for the visually impaired reader. Faced with a layout which appears to be randomly organized, and where the actual page content is often the last text encountered, a screen reader may spend a minute reading long lists of links and other ancillary information before reaching the main content. While use of semantic headers is of great help – allowing the user to skip through the headings – a non-table-based layout would convey much more accurately the intent of the document’s markup.

As a general rule, each section of a page should be enclosed in its own div, with its own id tag. This enables the content to be identified, styled and laid out appropriately by the CSS styling specifications. It also conveys the general structure of the page to assistive technologies, which can then take advantage of that when presenting information to the user.

Accessible Data Tables

For sighted users, the usual way of navigating a table is to look for the most interesting header, and then scan down or across to find the data values, cross-referencing from time to time with the headers from the other dimension.

For visually impaired users, however, this same process can be very time-consuming. Depending on the assistive technology in use, navigation of the table may be relatively easy or complicated. If the table is just read in the most straightforward fashion, the first row (where the column headers are usually located) is read first, then each subsequent row in turn, with the user required to keep track of both the current row heading and column heading.

It is, of course, possible to do better than this. For example, if the screen reader offers a table navigation mode, it is possible to use the arrow keys to move around a table one cell at a time. In doing so, it can announce the appropriate (row or column) new header as the cells change.

But here’s the rub: how does the technology know what text is the header? For sighted users, it’s generally intuitive: the layout of the table, as well as the styling of the headers, makes them stand out. Not so for assistive technologies, which need to analyze the page source to understand how the elements of the table relate to each other.

XHTML again provides support in the form of the th element⁶ and its accessibility attributes. By using the th element it is possible to clearly indicate that a cell is a heading. If it is unclear (for example in the top-left corner) whether this is a row or column heading the scope attribute may be used.

Sometimes, complex tables (such as those with nested levels), will have nested headers, or even headers that do not appear in “the usual place”. In this case, it is necessary to specifically identify where the headers are located for each table cell. This can be done by specifying the headers attribute for the table cell. This is a list of the ids of the th cells which contain the appropriate headings for this cell.

If table headings contain long explanations for some reason (for example, explaining how a column is calculated), this explanation will be repeated every time a user asks what is the context of a table cell. To avoid this, it is possible to use an attribute abbr, which gives abbreviated text to be read most of the time.

Accessible Forms

Input forms – vital for obtaining users’ credit card details to complete that purchase from your Web site – present similar challenges to tables for accessibility. Generally, data input fields, such as a text entry box for a credit card number, are detached from the text that describes its purpose.

To handle this, it is possible to use a label tag, which has a for attribute that specifies the id of the input element with which it is associated. This tag can be wrapped around the standard text to be displayed as the label and acts simply as a link. This enables assistive technologies to read the label when the user enters the form cell.

If there is no need visually to display the label (for example, if it is clear that three consecutive boxes make up an address), it is possible to specify the label tags and their content, and then use CSS styling to make the text invisible.

Alternative Stylesheets

A little-discussed benefit of CSS styling is the ability to provide multiple stylesheets for the same page. These different stylesheets allow correctly marked up HTML to be easily rendered differently for different user communities. In particular, it is possible to mark up a page in much stronger colors, and larger fonts, for some visually impaired individuals.

At the same time, correct use of CSS allows the browser much more control over page layouts and screen resolutions than is possible with traditional layouts. Indeed, it is possible for users to provide their own stylesheets, which override the stylesheets you provide. This provides a great opportunity for visually impaired individuals to help themselves – providing they have a fundamentally sound page to work with.

What you should do now

Having given an extremely brief overview of the issues surrounding accessibility, this section gives a checklist of the actions you should take now to make your pages accessible.

As with everything else in software development, adding a new dimension at the last minute is more expensive than building it in from the beginning. In the case of accessibility, making well-designed, web-standards-compliant pages accessible is much easier that starting with a legacy non-standard page, but even so, moving towards accessibility now will be quicker than waiting until the end of your project.

Live in Their World

First and foremost, you should make sure you understand the issues, and work in an environment as close as possible to that of your target audience – the visually impaired. Obtain a screen reader and use it to access your pages. Turn off your monitor and unplug your mouse. For everyday development, use Lynx more to check out how your site linearizes and that it makes sense without images.

Add alternative text everywhere

Everywhere that you have any visual styling that has meaning – mainly images – make sure that there is a text alternative that conveys the same meaning. Use alt=”” where there is no meaning.

Remember to keep alternative text short and meaningful. Alternative text for links should explain the intent of pressing the link, not describe the image. Longer descriptions belong in the title or longdesc attributes.

Move all your templates to use semantic styling

Remove or replace all those deprecated font tags. Use semantic markup, especially heading tags, as much as possible. Divide your documents logically using clearly identified div elements.

Extract all styling information to CSS stylesheets

Remember that if you use CSS, you or your users can override all your styling with more accessible styling. Anything you put inline in your document cannot be overridden. Remove all the explicit styling and convert everything to CSS. Then make sure all the CSS is extracted to stylesheets that can be replaced.

Make sure that your styling follows accessible guidelines – use relative font sizes rather than absolute pixel values, for example.

Consider providing alternative stylesheets

Once all your styling is in separate stylesheets, consider creating one or more alternative stylesheets – a large, high-contrast, uncluttered layout for the visually impaired, for example.

Move away from table-based layouts

As discussed earlier, tables are for data, not for layout. Using tables for layout can confuse screen readers and their users. Instead, use div or other content elements to break your content into meaningful chunks, and then use CSS styling to lay out your page visually as you wish.

Make all data tables accessible

All your remaining tables should now be data tables. Make sure that they make sense to screen readers by clearly identifying the header cells with th tags (correctly styled using CSS), and that if there’s any possibility of confusion about the layout that you’ve used the headers attribute on every table cell in the table to indicate which headers apply to that cell. Use the abbr attribute on the th cells to provide quicker access to long headings.

Make all your forms accessible

Remember that without clear labeling, users won’t know where to put their credit card number and where to put their name. If they can’t be sure, they’ll go somewhere else where they can.

Use the label tag to indicate which text is the label for which input box. Generally buttons are self labeling, but be sure to provide text alternatives when they’re not.

If you don’t feel it is necessary to display prompts to sighted users, use CSS styling to make the label text invisible to them.

How Aggiorno can help

Aggiorno is a tool to assist in improving web sites automatically. If the above list of “urgent” action items threatens your schedule – or your sanity – you might want to check out its list of Aggiornings that support the creation of accessible web content.

Add alt-text to images

This Aggiorning searches one or more files in a project for images that do not have alternative text specified, and then allows the user to enter the appropriate text for each image in a dialog box. Each image is then updated to contain the appropriate alt-text.

Replace font tags with CSS styling

Deprecated tags, such as font and center are removed and replaced with appropriate CSS styling. While this does not automatically make the content semantically valid, it does make it clearer to see what is going on and to later use the appropriate semantic tags.

Extract inline CSS style to stylesheet

In order to have the maximum transparency of styling, Aggiorno can collect all the inline style attributes into a single stylesheet.

Extract tables to div/CSS layout

Replacing existing table layouts with CSS-specified layouts is notoriously difficult. Aside from the problems of specifying certain types of layouts in CSS, it is difficult to handle all of the bugs in the different browsers.

Aggiorno will be able to deal with many of these challenges by automatically extracting many table-based layouts to web-standards-based div and CSS based layouts.

Although not all table layouts can be automatically translated exactly, the transformations are sufficiently complex that having the bulk of the work done, and then touching up the resulting code is generally much easier than making the entire transformation by hand.

Keeping up-to-date

At the current time of writing, Aggiorno is still very new. Additional Aggiornings will continue to emerge both from the company and the user community using the extension SDK. Keep up to date with the latest product news at where?

Other benefits of creating accessible web sites

While many would argue that making sites accessible is just “the right thing to do”, and others would point out that an increasing number of clients, especially governments, are mandating accessible Web sites (and lawsuits are following those that are not), there are a number of other benefits that come from making your sites accessible.

Most obviously, if you are trying to make information available, or sell products or services over the internet, you are eliminating at least part of your potential market if your site either cannot be accessed, or transactions cannot be carried out by them. When designing forms for credit card transactions, remember that your return on investment is proportional to the number of people that can make the transaction!

Other users also ignore images in favor of alternative text. The most important of these are search engine “bots” which cannot “see” the image, but will read (and score) your site based on its alternative text options. Failure to let the search bots know that your content is interesting and well linked together will cost you those valuable search rankings – thus lowering the number of people that ever find your site.

Mobile users often turn off – or have their browsers turn off for them – image downloads since these take up screen real estate and add relatively little value. Accessible text will appear in place of the image, thus making your site faster and more popular with mobile users.

If you construct a web page primarily focused on the content, and then apply the styling afterwards – as is required to produce semantically valid and accessible pages – the style and layout becomes much easier to change after the fact. See the CSS Zen Garden⁸ for examples.

Conclusion

Although a minority of web users, users with disabilities – particularly visual impairments – will try to access and use your website. But they need a little help. Part of that comes from assistive technologies such as screen readers. But part of it needs to come from the Web site developers.

The Web standards published by the W3C already contain everything that is needed to make accessible websites, and these standards are increasingly supported by the main browsers out there – Internet Explorer, Firefox, Safari, Opera.

Web developers need to use these facilities to make their Web sites accessible. Each construction that has a visual layout – images, layouts, tables, forms – needs to have a correlative connection in the code to enable assistive technologies to access that information.

Tools such as Aggiorno can automate many of the routine tasks associated with making Web sites accessible.

For information on Section 508, please visit http://www.section508.gov/ or http://www.access-board.gov/sec508/guide/1194.22.htm
Currently still at version 1 from 1999: http://www.w3.org/TR/WAI-WEBCONTENT/, but in the process of being updated to version 2: http://www.w3.org/TR/WCAG20/
At the current time, a 30-day trial version can still be downloaded from http://www-03.ibm.com/able/solution_offerings/hprtrial3.html, although the product itself has been discontinued by IBM.
See http://www.firevox.clcworld.net/about.html.
Based at http://lynx.isc.org/
Described in the HTML 4.01 reference at http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.6.
Available from http://www.aggiorno.com/.
The CSS Zen Garden can be found at http://www.csszengarden.com/. Note that while all the examples here are “real”, the content of this page has been designed to be especially CSS-friendly in a way that is generally not practical.