1.17 If you cannot make a page accessible, provide an equivalent accessible page
Contents
WAI checkpoint 11.4
Full WAI text: "If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page."
If it is impossible to create an equally accessible web page, provide a link to another page, which is universally accessible and is built with technologies endorsed by the World Wide Web Consortium (W3C). This page should provide the same information or functionality as the inaccessible page but in an accessible format. Changes to content or functionality should be made to both pages simultaneously.
The World Wide Web Consortium (W3C), an independent, international body that creates Internet and programming language standards. Its recommendations and standards are highly regarded.
Rationale
It is very frustrating for users to navigate to an alternative page, only to find that content is out of date or missing. This can happen if no editorial or quality assurance process is in place to ensure that all versions of a web page are equally up to date.
If non-W3C technologies are used, the user may be forced to download plug-ins or stand-alone applications which could be inaccessible. W3C technologies include standardised versions of HTML, XML, Style sheets, multimedia and many other technologies. The W3C continually review these technologies for accessibility. They are non-proprietary, making them usable across a wide variety of browsers and user agents. By using them, you are more likely to embed accessibility in your website.
Directions and Techniques
Provide a clear link to alternative version(s) at the top of each page
Providing the link at the top of the page means that the user does not have to wade through inaccessible content to view the alternative version. You should also provide a link to allow the user to navigate back to the original version.
Use scripts to automatically detect different browsers and present appropriate versions of web pages
A 'browser detect' is a script which can detect the type of browser used by a visitor to a site. If a browser detect is used in combination with alternative versions, it is possible to present the user with a version of the page which works well in their browser. Note that it is not possible to detect if the user is using a screen reader because they are not browsers.
Consider using user profiles for frequently visited pages
If the site contains information or services which a user is likely to use on an ongoing basis, consider providing them with the option to save a profile, which would save their presentation preferences, thus avoiding the need to navigate to an alternate version with each visit.
Use server side scripts to generate alternative pages on demand
Server side scripts, such as Java servlets, or PHP can be used to create alternative presentations of a page if the user requests one through their browser. The benefit of providing alternative pages in this way is that there is no requirement to maintain different 'versions' of a website which reduces the maintenance effort and ensures that up to date content is delivered to the user, regardless of the version they select.
Provide an offline equivalent
If it is absolutely impossible to deliver an accessible page, provide an offline service, delivered by trained personnel. Provide contact details such as email, telephone number, postal address and information on getting to the location if this is needed. This way information or services can be delivered over the phone, by correspondence or in person. Because people often access the web at times outside normal office hours, you should consider offering this service on a 24-hour basis.
How you could check for this:
Compare the page in different browsers or user agents
Opening the page in different browsers, especially older browsers will show you how it renders and whether or not functionality is supported or if information is missing. If it is, then the information or functionality is not equivalent. You should also test like this with user agents - things like screen readers or kiosks. If you don't have direct access to this technology, get someone who knows how to evaluate the site to do so with these user agents.
Guidelines for Web Accessibility - Priority 1- 1.1 Provide a text equivalent for every non-text element
- 1.2 Ensure that information does not rely on colour perception
- 1.3 Avoid causing the screen to flicker
- 1.4 Provide an auditory description of the visual information in multimedia presentations
- 1.5 For multimedia, ensure that timing of alternative descriptions is synchronised with the presentation
- 1.6 Use the clearest and simplest language appropriate
- 1.7 Identify language changes in text
- 1.8 Ensure that equivalents for dynamic content are updated when the dynamic content changes
- 1.9 For data tables, identify row and column headers
- 1.10 For complex data tables, use mark-up to associate data cells and header cells
- 1.11 Add titles to frames
- 1.12 Ensure that documents can be read without style sheets
- 1.13 Provide text links to emulate server-side image maps
- 1.14 Use client-side image maps rather than server-side image maps where possible
- 1.15 Ensure that scripts and applets that provide the only source of important functionality are directly accessible or compatib
- 1.16 Ensure that pages are usable without support for scripts, applets, or other programmatic objects
- 1.17 If you cannot make a page accessible, provide an equivalent accessible page
