Quick Tips for an Accessible Web Site
The following tips are things which can quickly and easily be done to any web site to ensure that it meets basic accessibility requirements. Please view the W3C-WAI checkpoints for a list of guidelines to create a fully accessible site.
1. Images & animations: Use the alt (alternative text) attribute to describe the function of each visual.
Images can be made accessible to those using non-graphical browsers (text only) or those with impaired sight who use screen readers by providing alternative text which aims to provide equivalent information to the user that is presented visually by the image.
Every single image must have an alt description tag giving equivalent functional, descriptive or contextual information in a clear text format. Alt text too often contains superfluous, un-necessary information, making it harder for screen reader users to extract the useful on-page information therefore, alt text should be kept short and succinct. However, if an image has no significant meaning then it must be given an empty alt tag in preference to no alt tag. An empty or null alt attribute is shown as alt="" and should be used for images that are intended to create purely visual (non-meaningful, non-semantic) design effects.
When a site is viewed without pictures it must have the same information and be as easily accessible as the graphic version of the site.
Ensure that alt attributes are used to convey meaning to your visitors, rather than meaning to you and your colleagues for example, on a logo that also works as a link back to a home page, use alt="Cardiff University home page" rather than alt="Cardiff University logo". To a vision impaired user it is of little interest that the image that they cannot see is a logo. The fact that by clicking the image they will be taken back to the home page is far more significant.
2. Image maps: Use client-side map element and text for hotspots.
An image map is an image that has "active regions". When the user selects one of the regions, some action takes place for example, a link may be followed, information may be sent to a server etc. To make an image map accessible, content developers must ensure that each action associated with a visual region may be activated without a pointing device.
Image maps are created with the map element and HTML allows for two types of image maps: client-side (the user’s browser processes a URL) and server-side (the server processes click co-ordinates). For all image maps, content developers must supply a text alternative for each active region of the map so that each link is navigable with keyboard access.
3. Multimedia: Provide captioning and transcripts of audio clips, and descriptions of video (LONGDESC attribute).
Alternative pure text or data material should be provided for users who may be text-only users or whose systems do not support multimedia. Provide a written description of any critical information contained in audio or video files on web pages. If you link to an audio or video file, indicate its format for example, WAV, .AU, MP3, WMP etc, and file size in kilobytes. Real Player can be used to create captioned video images.
A transcript or description of an audio or video clip can be located on a separate page that is linked to the clip. As these types of data are likely to be embedded using the OBJECT element, you can also include text that is shown by the browser if it does not support the Object. This text can be included between the <OBJECT></OBJECT> tags.
Macromedia Flash 4 and 5 provide limited accessibility options therefore it is recommended that you upgrade to Flash MX which has the ability to create audio tracks that describe navigational buttons, and is compatible with screen readers. Currently, the access improvements in Flash MX can be understood by Jaws and Window-Eyes. For tips on accessible Flash authoring, please visit the List Apart web site which surveys Flash access enhancements and their limitations.
4. Hypertext links: Use text that makes sense when read out of context for example, avoid "click here".
For users of assistive technology who are listening to the content of a web page, it is important to identify the target of links via link text. All link text, whether it is visible on a web page or as alt text on image links, must clearly tell the user the purpose and destination of the link. Phrases like "click here" or "more" are of little use to someone using a screen reader. It is important that link text describe the target of the link.
5. Page organisation: Use headings, lists, and consistent structure. Use CSS (Cascading Style Sheets) for layout and style where possible.
For users of assistive technologies, page structure and the use of headings is critical in visualising the content of the page however, defining the correct hierarchy of HTML headers and tables to convey structure can be problematic and confusing for web designers. The use of CSS eliminated the confusion by enabling designers to define explicitly the style of HTML elements separate from the structured markup and is a more efficient way of defining a web site’s presentation layout and style.
For example, you can create one style sheet that applies to all you web page. If you make a change to the style sheet, that change is reflected in all the pages.
6. Graphs & charts: Summarise or use the longdesc (Long Description) attribute.
If an image such as a graph or chart contains information beyond what can be conveyed in a short alt attribute (see point .1) allowing you to describe the image in as much detail as you like. The value of the longdesc attribute specifies a link to another page or file that contains a detailed description of the content of the image, the longdesc attribute should be used on the <img>element.
7. Scripts, applets, & plug-ins: Provide alternative content if case active features are inaccessible or unsupported.
Java and JavaScript applications (applets) are supported by a number of browsers but cause problems for certain screen readers and text only browsers. Java can be used to perform simple calculations for a form in a page or to replicate small fully functioning programs.
The level of accessibility of any Java or JavaScript application cannot be determined by the web designer. These are actual programming languages and as such require the programmer to have included accessibility features within the script, for example, if a script generates or changes the content dynamically from an event such as a ‘mouseover’ the text will not be read by a screen reader. Ensure that an alternative method of viewing the information is provided for non-mouse users.
Another problem is that anyone who relies on keyboard access will not be able to create the event that will cause the browser to generate the text. Some older screen readers will often read the content of the script itself which can cause greater confusion to the user.
Always provide an alternative content for the information or navigation given by the script. This can be done independently or by using the NOSCRIPT element, which will be rendered if the users’ browser is unable to handle the script.
8. Frames: Use noframes element and meaningful titles.
For visually enabled users, frames may organise a page into different zones, for non-visual users, relationships between the content in frames for example, one frame has a table of contents, another the contents themselves, must be conveyed through other means. The use of the title attribute of the frame element to describe the contents of each frame provides a label for the frame so that users can determine which frame to enter and explore in detail.
Note: the title attribute labels frames, and is different from the title element which labels documents. Both should be provided, since the first facilitates navigation among frames and the second clarifies the user’s current location.
Not all browsers can support frames and thus the noframes element is used so that the browser may still display the frame content. Meaningful content should be provided in the noframes element which follows the frameset and contains a body element. Meaningful content can include a version of the entire content of the fames in the frameset, or it can consist of instructions and links for users to find the content. Often the links point to the frame documents, outside their frames context. Noframes content must not consist of instructions for users to switch to a frames-capable browser.
9. Tables: Make line by line reading sensible. Summarise.
Each time a table is used, screen readers announce the existence of the table and its rown and columns. Use lots of tables, nested within each other, and you've got a usability nightmare for screen reader users.
Most accessibility problems encountered with tables arise from using these structural elements for aesthetic and presentational purposes. Before using tables, review the reasons for including them. Tables should only be used on web pages if they provide a logical format for the data and not because they are visually pleasing.
When it is necessary to use a table for layout, the table must linearise in a readable order where the contents of the cells become a series of paragraphs one after another. Cells should make sense when read in row order and should include structural elements (that create paragraphs, headings, lists etc) so the page make sense after linearization.
Identify table headers and use appropriate markup to associate data cells <td> and header cells <th> for tables that have two or more logical levels of row and column headers. In a table that lists members of academic and research staff, a typical table header might be Academic Staff, and table cells associated with it would include Paul Jackson, Mike Patterson, Andrew Ridgley, and so on. A sighted user who is using a graphical browser will see the connection between Academic Staff and the column of names directly below. But screen reader users require additional markup that connects the table headers to its associated data cells.
Structural markup should not be used to create visual formatting when tables are used to create a layout. If a cell is not actually a header for a row or column of data, use style sheets or the formatting attributes of the element.
More modern screen readers are getting quite good at spotting layout tables and are ignoring most of them, but to be on the safe side use stylesheets for layout, not tables.
10. Colour: Ensure that all information conveyed by colour is also available without colour.
Colour is useful for conveying information by should be be solely relied upon to communicate meaning. Not all users can easily perceive differences in colour and they would find it difficult to understand information which is communicated by colour alone, for example, a red-green colour-blind user will find it hard to distinguish between two identically shaped and sized buttons when one is green and the other is red.
Users who work with poor quality or monochrome display screens also find it hard to perceive colours.
If colour is used to denote information (such as clickability), reinforce it with additional signs for example, make the link text bold, underline the link. If you have turned off the underlining of links via CSS, consider making the link text bolder than normal text. However, if you do this be sure to avoid using bold on nonlinked text to prevent confusing colour-blind users as to which is bold text is hyperlinked and which bold text is simply bold.
Avoid referring to colour in text, for example, "visit the Red box for Help", as this is useless direction for users who can't see or who cannot distinguish between colours.
Ensure that the difference in contrast between the colour of text and the colour of the background are sufficient for users to be able to read the text, inlcuding users who have impaired colour vision or who use a black and white screen.
11. Avoid Un-necessary Punctuation:
Every form of punctation is read and announced to screen reader users. "." is announced as "full stop"; "/" as "forward slash" etc. As such, avoid any non-essential punctuation for example, removed those colons from form labels; avoid using "...." at the end of a sentence; take out the ">>" from submit buttons. If these items must be used, insert them as background images through the stylesheet, so that they do not get announced to screen reader users.
12. Remove Vertical Bars:
Vertical bars are commonly used to separate items in a horizontal navigation menu. However, screen readers announce, "vertical bar" each time a "|" is inserted. This means, that in any one navigation menu, around 50% of the words a screen reader user will hear are "vertical" or "bar". If you need to use vertical bars, insert them as a right (or left) border to each menu item through the stylesheet.
13. Check your work: Validate. Use tools, W3C-WAI checklists, and guidelines.
It is extremely important to validate your work, you’ll never get anyone to visit your site if the quality of the site is poor. A site can lose hundreds of visitors if they are made to wait more than a minute or so for a site to load, if links are broken or if your site is not accessible.
Take the time to validate and test your work before it is made live on a web site, you’ll save yourself some embarrassment, time and visitors.