Quick Web Accessibility Tips

Posted on Wednesday, October 1st, 2008 at 9:13 am in

The following “Quick Tips” summarise some of the key concepts of accessible Web design.

These are not complete guidelines, but should be viewed as “quick ‘n’ dirty” tests for some of the checkpoints from the Web Content Accessibility Guidelines (WCAG) 1.0.

WCAG 1.0 supporting documents include a simplified Checklist and a detailed document describing techniques for implementing the Guidelines that includes references to both HTML techniques and CSS techniques. There is also a multimedia curriculum presentation which explains how to use the guidelines but it should be noted that this presentation is dated March 2000 and, consequently, maybe be somewhat outdated in regard to current browser technology.

The Checks

Images & animations: Use the alt attribute to describe the function of each visual.
One method that has been previously described for checking alt text is to place the cursor over an image, or animation and look for a small tooltip window displaying the contents of the alt attribute. Unfortunately, this only works within Internet Explorer which, incorrectly, displays alt text in this fashion. One, cross-browser, method for checking that alt text is, not only present on appropriate image elements, but is also suitably descriptive, is to check a page within a graphical browser with image display disabled. Even better, try looking at the page using a text-only browser such as Lynx.
If you are using image buttons for navigation, is it still possible to navigate the page, or site, effectively within a text-only browser? If images display important additional information, is that information also available within the alt text?
Finally, imagine reading the page aloud over the telephone. What would you say, upon encountering an image, if you wanted to convey the correct information to the listener?
Image maps. Use the client-side map and text for hotspots.
If you are using image maps, try to use client-side maps rather than server-side maps. As well as providing a description of a map using the alt attribute, ensure that you also provide text links for each hot spot within the map to ensure that users of non-graphical browsers etc. can still navigate effectively.
Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
If you are making use of videos, have you provided alternative text which is synchronised to the video in order to obtain a ‘captioning’ effect? Do the captions convey the same basic information (where possible) as the video itself? Disable the video display. Can you still follow the presentation?
Are you using audio to convey information? If so, turn your speakers off and check that the text transcripts of your audio information convey the same basic information. Wherever possible, use simple language for audio transcripts as many deaf users will, by default, use sign language as their primary method of communication with spoken/written language as a second language.
Hypertext links. Use text that makes sense when read out of context. For example, avoid click here.
Screen reader users may jump from link to link within a given document without reading the intervening text. This is broadly analogous to the way in which sighted users often “scan” large documents looking for keywords or phrases before reading the surrounding text properly. In such a situation, link text along the lines of More information may be meaningless as there is no indication of what information is being referred to. Try reading link text out aloud without referring to the accompanying context. Does it make sense? Would a user be able to broadly understand where such a link was leading to? If not, amend the link text so that it reads, for example, More information on our full product range
Page organisation. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
View your page in a graphical browser with all styling disabled or using a text-only browser. Is the page organisation still clear? Can lists be easily identified? Does the structure of pages vary from one to another? Using a consistent structure within all pages on a site increases the chances that information can be located easily or avoided when necessary. Are your navigation bars, or menus, in the same place on every page? Are page headers and footers structured in a similar manner across the site? Using a random page from your site, is it possible to accurately predict where the main page content will be on any other page before you view it?
Graphs & charts. Summarise or use the longdesc attribute.
Graphs and charts should be treated in a similar manner to other graphics but may require more textual information than is appropriate with a simple photograph. Although WCAG 1.0 mentions the longdesc attribute, browser support for longdesc is currently limited. Try looking at the page using a text-only browser. Does the alt text convey enough information for those users who may be unable to see the chart or graph? If not, consider adding descriptions of such images on a separate page and provide a text link to the description near the graph, or chart, itself.
Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
Do not rely on client-side technology. Not all users have access to javascript, for example. Does your page still function effectively with javascript switched off? If you’re making use of Flash, test the page out in a browser that doesn’t have the appropriate plug-in. Is the information within the page still accessible? As above, using a text-only browser is an excellent way of checking for these accessibility issues but, be warned, incorporating a no-script alternative that simply suggests that users download the latest plug-in etc, is not an appropriate solution.
Frames. Use the noframes element and meaningful titles.
Whilst the number of older browsers that cannot access frames has undoubtedly fallen, it cannot be assumed that users will always arrive at a framed site by means of its frameset page. Try viewing one of the underlying framed pages without accessing the frameset. Can users still navigate to other areas of the site? Use the no-frames element to provide an alternative navigation mechanisem for those few users who are still using technologies that cannot access frames.
Tables. Make line-by-line reading sensible. Summarise!
Are you using tables? Do they contain data or are they used for layout? If possible, consider CSS for layout instead. Use the caption element to provide short summaries of tabulated data. Some older screen readers access tabulated information by column rather than by row, so ensure that the content still makes sense when read aloud on a column-by-column basis. W3C also provides a table lineariser that can be useful in this respect.
Check your work. Validate. Use tools, checklist, and guidelines.
One of the most basic requirements of an accessible page is that it has been built using compliant HTML techniques. If your page does not validate according to its DOCTYPE, then it may contain elements that cannot be accessed by a range of assistive technologies. Single pages can be validated online using W3C‘s HTML Validation Service. Multiple pages, and even entire sites (up to 100 pages), can also be validated using the Web Design Group’s Validation Service but be warned that some differences have been noticed between the two parsing engines when validating custom DTDs.

Basic online, automated, accessibility checks can be made using Hisoftware’s Cynthia Says portal but this should be supported by manual reference to the WCAG Guidelines.

You might also be interested in

WordPress Theme Development

Top