Audits and site reviews
Our accessibility review process offers a standard way of benchmarking the accessibility of a web site against both the W3C standards and real world accessibility issues; it's the next best thing to user testing, and considerably quicker and cheaper to arrange.
There are three aspects to reviewing a site;
- Assessing the general structure, copywriting, colours, design approach, navigation and so on that is common across the site - a qualitative approach that covers the missing "manual checks" reported by automated tools.
- A quantitative check to look for things that are essentially oversights or omissions. We use automated tools to check for the sort of problems that can be checked in this way, such as missing alt text, or links that read just "more" or "click here".
- Emulating different users and viewing conditions to try to identify any problems with using the site. This includes situations such as CSS off, screen readers, keyboard-only navigation, and so on. These are also things that software emphatically cannot test.
- Reporting back on any issues and recommended steps to take. Our reports are written by hand, not generated by a machine and always include three key things;
- Executive summary for business people; what's the bottom line?
- Technical report of the issues found, if any
- Prioritised recommendations for what steps to take to address any problem
A full audit consists of:
1. Automatic check of every page/a selection of pages using software tools. This is a quantitative check that ensures there are no inadvertent mistakes, and covers HTML validation, CSS validation and simple accessibility basics (alt text, form labels, that sort of thing). In the production process, or through the use of a CMS over a period of time, it may be that simple errors have crept in; this test aims to ensure the quality control has been acceptable and that no new problems have been introduced since the site launch in the case of content-managed sites.
If there is sufficient time, we recommend checking every page. To meet lower budgets, we can sample a smaller set of pages. This is the only item that is normally run on every page in the site; the other items that follow below are usually based on certain sets of pages, or common user journeys in the case of functional sites.
2. General assessment of the site design and navigation - looking for usability issues, design issues, layout issues that may cause issues for one or more groups of users. This part of the review also covers situations where images or diagrams may need more explanation than is possible through simple alt text; for example charts, which present a unique set of problems.
3. Browser check - sometimes a site may have issues when viewed in different browsers; there are more browsers in use than ever before, and we run an extensive test suite to ensure that the site remains readable and usable in all popular browsers, although the design may not be maintained.
4. Screen reader tests - we run the site through several popular screen reader applications (typically used by people with low vision or no vision) to ensure that there are no serious problems likely to be encountered by users of these
5. Viewing variations - we ensure that the site is accessible in the following cases;
- text-only browser
- with images off
- with CSS off
- with JavaScript off
- without the Flash player
- low bandwidth situations
- keyboard-only navigation
6. Textual review - part of web accessibility is ensuring that the language used on a site is as clear and simple as possible. Badly written copy, writing that is too technical, or writing that uses jargon that is inappropriate for the audience can create accessibility problems, so we review a random selection of pages to check these sorts of issues
7. Colours check - It is important to avoid the use of colour combinations that some groups of users may find hard to read (for example, users with low vision, colour deficits in their vision or other vision problems may have greater difficulty in using a site if the colours are poorly chosen). We use a selection of tests to identify any colour combinations or instances where there is insufficient contrast.
8. Proprietary formats - we check the site for any PDF files or other proprietary files where there may be problems accessing the content for one or more groups of users. We may recommend providing alternative formats in some cases where necessary.
9. Multimedia content check; we check the site to see if there is any content provided as sound files, video, or other multimedia. If this sort of content is used, there are a specific set of criteria that may need to be met; for example, providing text transcripts if content is only provided as a sound file.
10. Assessment of the site against the WAI Web Content Accessibility Guidelines to measure the compliance level. This tends to be rather subjective - different people will make subtly different judgements since much of WCAG is down to interpretation - but it is often useful to have a rough idea of how the site compares against the W3C accessibility compliance levels (A, AA or AAA). Where issues are found in the above tests, we try to match them up with the relevant checkpoint in the Web Content Accessibility Guidelines, so that the W3 priority can be used as part of the decisions regarding what to address first if any problems are found.
The report will include an executive summary of the findings, a detailed list of tests made and issues found, and a set of recommendations for any issues that need to be addressed, prioritised where appropriate by the severity of the issue and the number of users affected.