The four principles used in WCAG2.0 are that information should be:
- Perceivable - Information and user interface components must be presentable to users in ways they can perceive.
This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses) - Operable - User interface components and navigation must be operable.
This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform) - Understandable - Information and the operation of user interface must be understandable.
This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding) - Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)
If you are familiar with WCAG1.0 you can see that this approach is different, but after interpretation of the WCAG2.0 guidelines and addition of guidelines for good usability, the steps to accomplishing inclusive content break down into the following:
- Structure: Ensure your pages are properly structured xhtml/html and that text works effectively both for communicating the information and being easily visible and adjustable.
- Layout: Make sure the templates for your pages include relevant inclusive navigation aids
- Validation: Ensure your templates and your pages are valid xhtml/html, and that your stylesheets are valid css. Any Javascript should also be validated.
- Style: Use stylesheets (CSS) rather than formatting mark-up. Ensure that the page makes sense if the stylesheet is not used. Use a multipurpose stylesheet, with additional 'special use' stylesheets so they are easy to maintain. Ensure you have an adequate print stylesheet.
- Colour: Pay attention to colours used (the contexts are described below)
- Images: Be cautious about the number of images you use. Always optimise graphics and use descriptive alt tags unless they are purely decorative, in which case use a null alt tag (alt=" ")
- Non-xhtml/html content: Multimedia, scripts and forms may all reduce or block access to the information for some
- User experience: Test for user experience against a number of different graphical browsers (and different versions of the same browser) on different platforms, not forgetting smartphones and test either with lynx, the most widely used non-graphical browser, or with a speaking browser or screen reader. Make your pages dynamic. If fixed width is required, use a 'standard' width of, say 800 pixels, set with the stylesheet.
- Don't use old technologies such as frames or image maps
1 Structure
Properly structured xhtml/html
Good xhtml/html content should be properly structured with a title, metadata, headings, paragraphs, lists, etc. This structuring will make adding styling easier and it will add to the meaning of the content, particularly for those who use tools to listen to the web pages and also for search engines. Using a recent xhtml/html editor may ensure that your code is correct and can be checked within the editor.
In the future html5 will start to become more common but it will take several years (at least) before all the common browsers and assistive technologies in use support it, so don't remove current accessibility solutions in a hurry. See http://webaim.org/ for further information.
Effective text
Users become less willing to read down when pages get long. Various measures will help all readers get more from a page:
- using an active voice to give the text energy
- putting a summary at the top of the page
- breaking information into chunks
- making lists of points rather than using a narrative style
- to enhance readability, make sentences 20 words or less, and paragraphs 6 sentences or less.
Although the text as a whole should be written clearly, pay particular attention that the title of the page and the links within the text are in clear and concise language.
Adjustable text
You cannot hope to make a web page for which the size of the type suits everyone. The aim is for pages that are comfortable to read in standard browser setting by people with normal eyesight, but on which the type can be scaled to a larger (or smaller) size by the user and the page still works as a whole. To allow for this user-based resizing, the font sizes in your style sheets should be relative (sized in ems or percentages rather than pixels). This is all taken care of in the University stylesheets, but for working with your own, see further information in the article 'How to Size Text in CSS' at A List Apart (http://www.alistapart.com/articles/howtosizetextincss).
One of the clearest and most readable typefaces to use for continuous text on web pages is Verdana. It is the screen-adapted version of Arial - the adaptations are visible in the capital I and the number one, the chunkier type and more defined inter-letter spacing (see below for comparisons of Verdana [top] and Arial [bottom], both 12pt):
2 Layout
Order of elements on the page
The layout of your pages should reflect the logical order of the information on the page, so that people using screen readers hear the information in a sensible order. The best way to make sure your templates work effectively is to draw out a diagram of the parts of the page relative to each other and satisfy yourself that the ordering of them is what you need. The most common problem areas are the placing of tabbed navigation and page headings relative to the left hand navigation of the content and the text content of the page itself, and the use of tables or positioning.
- WAVE is a very effective tool for looking at this problem - put your url into the page at http://wave.webaim.org/ and look at the results under the tab 'Structure/Order'.
- In the Firefox web developer toolbar, go to Information > Display div order to see similar information. You can also use Miscellaneous > Linearize page to see the logical order of the information in the page.
Appearance of the page
For design purposes space on a page is vital however too much space between elements can be problematic for those using a screen magnifier. Make sure the final layout is cohesive and doesn't have space that such a user could get lost in (all common operating systems have a screen magnifier built in that you can test with).
Navigation
Consistent navigation at several levels is essential for a website. The levels of navigation available should include some of the following
- global navigation that is included on every page, usually associated with a search box (essential)
- Tabbed navigation to take users to well-defined sections of a site
- Breadcrumb trail to cue users about where they are within the site and allow them to step upwards (essential)
- Left-hand navigation for finding your way between sub-sections or pages in a section, which may include sub-navigation (essential)
- 'Contents list' navigation at the top of a long page
Within each of these navigation elements, there needs to be some sort of flag to show users where they are - an 'active' state that changes the appearance of the element. Use of colours in navigation needs to be approached with some care (see section on colour for the issues involved and how to tackle them). Any scripted navigation must be usable by keyboard as well as by mouse.
'Invisible' navigation
Extra elements can be added to a page that are spoken but are styled in such a way that they aren't seen. Some of these elements are used and others maybe not much but once they are provided in your template they are no extra work to maintain. They include:
- 'Skip' links, very usefully allow users to bypass the global information at the top of a file and get to the content of the page (see http://www.rnib.org.uk/professionals/webaccessibility/designbuild/navigation/Pages/hidden_navigation.aspx)
- Access keys - use numbers as some letter-key combinations are reserved for operating systems (see http://www.rnib.org.uk/professionals/webaccessibility/designbuild/navigation/Pages/access_tabs.aspx for information). Because of this access keys present some problems and help pages will be needed to explain what access keys are available.
3 Validation
If you have used a good xhtml/html editor to write your code you might already trust that it is valid, but you still ought to validate it. The dtd in the head of the file, which might look like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
tells a browser what type of page you have created, and the browser processes and renders the page accordingly. The validator checks the code against the dtd and tells you if you have any errors, which you then ought to fix, as they could present traps for browsers and cause your pages to be rendered wrongly.
Stylesheets can be validated in a similar way. Javascript (and other code) should be validated before use.
Validation tools
One of the easiest ways to get quick access to validators is to use Firefox and install into it the web developers toolbar (http://chrispederick.com/work/web-developer/). This gives access to many useful tools, mentioned elsewhere in this information, but for validation you will find what you need under the 'Tools' menu:
The options at the top of the menu will directly validate the page currently being viewed in the browser, while at the bottom of the menu there are options to check pages that are being viewed locally (not available through a url). The validators being used are already configured but you can change them if you wish to use a different service.
Another handy extension in Firefox, HTML Validator (http://users.skynet.be/mgueury/mozilla/), adds a little icon to the bottom right of your window, which is a green tick if the page is valid, a warning sign if there is a possible problem, and a red cross if there is an error. This is a really quick glance way of seeing if there is a problem with a page, although it shouldn't be entirely trusted.
4 Using stylesheets
For accessibility purposes (and in order to be up to date) you should use web templates that are controlled by stylesheets, with no formatting in the code of the pages. If you have never used stylesheets before, a good introduction and set of tutorials can be found at HTMLdog (http://htmldog.com). Providing the web pages are composed of properly structured xhtml/html and the layout allows the information to sequence in the correct order, the information on them should be usable with the style sheets turned off (which you can view via the Firefox web developers toolbar).
As noted above, stylesheets can and should be validated and this can conveniently be done via the Firefox web developers toolbar.
A main stylesheet, with additional 'special use' stylesheets will be the easiest to manage and maintain. If you want to use the University templates and add extra styles then we advise you add an extra stylesheet for them. Ensure you have an adequate print stylesheet and then you may be able to minimize the number of pdfs in use. Make good use of notation with stylesheets. This is especially useful for styles added for particular purposes and for noting changes. Loading long stylesheets is an overhead in the time taken to render a web page, so remove from stylesheets styles that become redundant.
5 Colour and web pages
There are a number of different issues with colour that need to be addressed - if you do this for your template as whole you will only have to do it once:
- There needs to be adequate contrast between type and background (this contrast is given a value for the different levels of accessibility). The level of contrast can be measured by using appropriate tools, either via the web accessibility toolbar (for Internet Explorer only - see http://www.wat-c.org/tools/index.html) or via the Firefox WCAG Contrast checker (https://addons.mozilla.org/en-US/firefox/addon/7391) extension.
- Since you have no way of knowing whether users can see the page in colour, you must not use colour as the sole means of distinguishing between information - for instance the right answers in one colour and the wrong answers in another - the difference must also be distinct without the use of colour.
- You must select your colours keeping in mind that 8% of northern European men are red/green colourblind (see http://www.visibone.com/colorblind/ for red/green colour blind view of web-safe colour palette). http://www.vischeck.com has on it a tool that simulates colourblind vision - it doesn't work on all web pages but allows you to upload images as well.
- When you add styling for any link colours, make sure you style all of them otherwise a user-selected value might intervene and cause problems with legibility.
- For third world users in particular, using the web-safe colour set (216 colours) is important to ensure cross-browser and cross-platform consistency.
- Alternate-row background tints can be very useful for helping eye tracking in tables or lists.
The Firefox web developer toolbar Information > View color information will show you the colours in use on a page.
6 Images
As with colours there are a number of issues concerned with the use of images.
- Graphics on a web page will make loading the page take longer, so it is wise to keep the number low. You can get an indication of the size of your images from the Firefox web developer toolbar Images > Display Image File Sizes and how long a page takes to load Information > View document size or via many other tools
- Make sure the images you use are optimised for use on the web - they should be at 72dpi and are at a size suitable for their use on the page. Don't use a bigger file than you need and resize it in the browser. When possible do add height and width measurements in the browser to allow for faster loading of the page.
- Use descriptive alt tags unless the image is purely decorative, in which case use a null alt tag (alt=" "). For a functional image, such as a button, use an alt tag that describes what the button is for unless it is part of a link that already does that, in which case the alt text would duplicate it. Some image links duplicate nearby text links, so look carefully at the page with images disabled to check that only one set of links appear and that they are clear.
- Avoid using a background image on a page as it can make text impossible to read. If you have to use a background image, also use a complimentary background colour so the text is legible if the image doesn't load.
- Avoid using moving images (by default) for the following reasons:
- they can be very distracting and movement may stop the user from reading the page properly
- moving images such as flash presentations will not be viewable by users without the plugin and may be version dependent - use them to add interest but also make the information available in an accessible form (see next section on non-xhtml/html content).
- Don't provide words within images - if you are providing text, do so in xhtml/html. The words within images are not indexed in search engines and are not readable to those who cannot see the image, unless you make provide the words at alt text or a long description. Words within images are difficult to magnify so are awkward for those who use screen magnifiers.
7a Non-xhtml/html content: Multimedia
PDFs, Flash, PowerPoint and video and audio players may all reduce or block access to the information for some, so you need to be aware of what you need to do to make the information accessible. A first step is to always make sure there is a link to update or acquire a media player. WebAim has a series of articles about how to add accessibility to multimedia - see http://www.webaim.org/articles/.
In the last 10 years Adobe has worked very hard to make Flash and Acrobat produce accessible content, but to do so you do need to actively engage with the process when producing the content files.
If you are producing Flash (or are commissioning it), the pages at http://www.adobe.com/accessibility/products/flash/ and http://www.rnib.org.uk/professionals/webaccessibility/designbuild/multimedia/Pages/flash.aspx give good guidelines on how to proceed. If the Flash presentation provides meaningful content (for instance for teaching and learning purposes) then that content needs to be made available from a link next to the Flash presentation.
Most people put PDFs on the web. Wherever possible the information should also be provided in an alternative form (xhtml/html, Word or text)
- PDFs are often produced from a scanned document, which produces images of the pages so cannot be used by blind or partially sighted people. Acrobat Pro can perform Optical Character Recognition (OCR) to produce text from the image and embed that in the PDF file.
- At a very basic level most disabled users can access from a PDF a converted text document but the content can often be chaotic - there is often no structure so headings and text are indistinguishable; forms can be particularly difficult to use. Use Acrobat Pro with an existing PDF or during production of a PDF to add accessibility features for forms and buttons and to add structure to text.
There are a number of resources at http://www.adobe.com/accessibility/products/acrobat/training.html that will help you produce more accessible PDFs.
PowerPoint (and other presentation software): Slide presentations can be problematic for screen readers but much of the problems can be resolved by properly structuring your slides with headings, text and lists. Using a provided template will help a lot. The only sure-fire way to ensure that people using screen readers can access the information is to make available an xhtml/html version (converted from the PowerPoint file) or use another method for creating the slides. If slides are converted to PDFs or Flash (as with some slide upload services like Slideshare), the access problems associated with those formats apply. Providing a transcript of the talk or a very thorough handout may be a better alternative than converting slides. Useful help at http://www.rnib.org.uk/professionals/accessibleinformation/electronicdocuments/fileformats/Pages/powerpoint.aspx and http://www.webaim.org/techniques/powerpoint/.
Video and audio
Providing audio and video content should be thought of as a visual aid, and not the primary means of presenting content. It can enhance web pages for many users but because the media presents content primarily for one sense, it can cause difficulties for the blind, partially sighted, deaf and deaf-blind, for whom the content ought to be available as a text transcript. For a video the transcript may need to be descriptive so that action without dialogue can be understood. Captioning should not be thought of as the same as a transcript - often it can be a précis.
When providing audio and video, there should be controls (for stopping and starting) and links to alternative media players (for those with incompatible browsers).
Webcasts are not accessible for all but will provide benefits for some and alternatives can be added after the event. Any potential users need to be aware of issues they may present before the event.
7b Non-xhtml/html content: Scripts and forms
- xhtml/html forms: Long forms can be arduous to use when using a speaking browser or accessing via a keyboard. The RNIB gives detailed information about what to look out for (see http://www.rnib.org.uk/professionals/webaccessibility/designbuild/scriptsforms/Pages/forms.aspx). For all forms, making them usable will help with accessibility, and tips for usability of forms may be found at http://www.usability.gov/government/lssnslearned/form.html
- Javascript and AJAX: Javascript can add valuable interactivity to pages, but it can cause problems for those using speaking browsers or magnifiers, or those who are not using a mouse. Further details and techniques are available at http://www.rnib.org.uk/professionals/webaccessibility/designbuild/scriptsforms/Pages/javascript.aspx, http://www.webaim.org/techniques/javascript/ and http://www.webaim.org/techniques/ajax/
- Don't use Javascript when using xhtml/html would work instead
- Try not to add text through the Javascript, but if you do ensure it is available via <noscript> tags.
- Ensure the scripts work if the user is only able to use a keyboard (use the ONKEYPRESS event handler as well as the ONCLICK one)
- If you are using Javascript to enhance navigation (usually by opening dynamic drop-down menus), make sure the navigation is adequate when the enhancement is not available (the target page contains all the navigation the user needs). For decorative effects the lack of accessibility shouldn't matter.
- If you are providing essential information on a page that changes on the fly, make sure that information is also available in a static form and is kept up to date. Screen reading software cannot cope with content changing under its feet.
- Java applets: The main accessibility problems with java applets are that they need to be available to those who don't use a mouse, so use the ONKEYPRESS event handler as well as the ONCLICK one. Descriptive text alternatives should be included for Java Applets and other objects. These should be inserted between the opening and closing <object></object> tags in the web page. Then, if the browser does not support the applet or object, the alternative content will be presented in its place.
8 User experience and usability testing
Test for user experience against a number of different graphical browsers (and different versions of the same browser) on different platforms, not forgetting smartphones, and test either with lynx, the most widely used non-graphical browser, or with a speaking browser or screen reader. The first preference should be to make your pages size dynamically. If fixed width is required, use a 'standard' width of, say 800 pixels, set with the stylesheet.
Find out how fit-for-purpose your design/architecture is by watching some users work through a set of tasks. Identify your most important user groups (three or four at most) and recruit five individuals or pairs (useful because they talk to each other, with individuals you'll have to ask them to talk to you). They must be individuals who are not already familiar with the pages. The Computing Service can run the user testing for you and let you have the results - our software records the screen usage and audio records the session - contact helen.sargan@ucs.cam.ac.uk.
9 Old technologies
Don't use old technologies such as frames or image maps - they have been superseded for a purpose and have intrinsic accessibility problems.
Last updated: 8 March 2012