• No results found

Web accessibility standards and guidelines 35

3   Chapter 3: Overview of Specific Guidelines and Standards 24

3.4   Web accessibility standards and guidelines 35

The Web Content Accessibility Guidelines provide an international set of guidelines developed by the W3C, the governing body of the Web. These guidelines are based on four principles:

• Perceivable: Available to the senses (vision and hearing primarily) through the browser or through assistive technologies (e.g. screen readers, screen enlargers, etc.) • Operable: Users can interact with all controls and interactive elements using the

mouse, keyboard, or an assistive device.

• Understandable: Content is clear and limits confusion and ambiguity.

• Robust: A wide range of technologies (including old and new user agents and assistive technologies) can access the content.

The guidelines (summarised in Table 3.2) for developing an accessible website, provided by the WAI (Web Accessibility Initiative, 1999) are:

• Provide equivalent alternatives to auditory and visual content. • Prevent relying on colour alone.

• Use markup and style sheets.

• Clarify natural language usage through markup.

• Tables should be used for tabular information and developers should avoid using tables for layout or structure.

• New technologies featured on web pages must transform gracefully.

• The developer has to make sure the time-sensitive, dynamic objects can be paused or stopped.

• Developers have to design sites following principles of accessible design to ensure device-independent access to a site's functionality.

• Sites must be designed to be device-independent and elements should work with any input device.

• Interim solutions must be used to ensure that older browsers and assistive technologies will operate correctly.

• World Wide Web Consortium (W3C) technologies and guidelines must be used during site design.

• Provide contextual information about grouping complex elements or pages. • Keep navigation mechanisms clear and consistent.

• The use of consistent page layout, recognisable graphics and easy-to-understand language benefit all users.

Table 3.2: WAI accessibility guidelines

Below follows a detailed discussion of each of the mentioned guidelines:

• Provide equivalent alternatives to auditory and visual content. Although people with certain disabilities are not able to use certain technologies like images

and sounds, they can use equivalent alternatives. The alternatives have to provide the same purpose. Images and audio technologies used on sites should have equivalent text descriptions of their functionality. These text equivalents can be used by various assistive technologies like Braille Displays for blind people. Checkpoints to ensure that this guideline is met include:

o The use of text tags like alternate text (ALT). ALT tags provide a text equivalent to non-text components like images or video clips.

o Provide redundant text links for image-based links.

o Provide an auditory description of the important information of the visual track of a multimedia presentation.

o For any time-based multimedia presentation, synchronise equivalent alternatives with the presentation.

o Render text equivalents for client-side image-map links.

• Prevent relying on colour alone. People who are not able to differentiate between colours or with monochrome monitors may not receive information relayed through the use of colour alone. Checkpoints are:

o Ensure that information conveyed through colour is also available without colour.

o Ensure a significant contrast between foreground and background colours.

• Use markup and style sheets. Markup should not be used for presentation purposes, for example, the use of tables for site layout. Using these techniques make it difficult for user with specialised software to understand the layout and to navigate through the page. Checkpoints for this guideline include:

o Use existing markup rather than images to convey information. o Create documents that conform to published formal grammars. o Use style sheets to control layout and presentation.

o Use relative rather than absolute units in markup language-attribute values and style-sheet property values. Use percentage lengths rather than absolute units like centimetres

o Use header elements to convey document structure and use them according to specification. Use Heading 2 (H2) in HTML to indicate a subsection of Heading 1 (H1). Do not use headers for font effects.

o Mark up lists and list items properly, for example, Unordered List (UL) in HTML.

o Markup quotations. Do not use quotation markup for formatting effects such as indentation. For example, in HTML, use the QUOTE (Q) and BLOCKQUOTE elements to markup short and longer quotations, respectively.

• Clarify natural language usage through markup. When natural language changes are marked up in a document, assistive technologies can switch to the new language. The checkpoints are:

o Clearly identify changes in the natural language of a document's text and any text equivalents.

o Specify the expansion of each abbreviation or acronym in a document where it first occurs.

o Identify the primary natural language of a document.

• Tables should be used for tabular information and developers should avoid using tables for layout or structure. Tables for any use provide specific problems for screen readers. Some user agents (software that access web pages) allowed the user to navigate through that table structure. A table that is not marked up properly may cause difficulties with some user agents (assistive technology). Checkpoints for proper table usage are:

o Identify row and column headers.

o For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

o Do not use tables for layout unless the table makes sense when linearised (that is when the content of table cells is displayed as a series of paragraphs, one after another).

o If a table is used for layout, do not use any structural markup for the purpose of visual formatting.

o Provide summaries for tables.

o Provide abbreviations for header labels.

• New technologies featured on web pages must transform gracefully. For a site to transform gracefully, it should still function in older browsers or when the user decides to turn off certain technologies. Checkpoints for graceful transformation are:

o Ensure documents may be read without style sheets.

o Ensure that equivalents for dynamic content are updated when the dynamic content changes.

o Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

o For scripts and applets, ensure that event handlers are input device- independent.

o Ensure that dynamic content is accessible or provide an alternative presentation or page.

• The developer has to make sure the time-sensitive, dynamic objects can be paused or stopped. Disabled people may not be able to read or follow moving objects accurately. Checkpoints that need to be followed:

o Until user agents allow users to control flickering, avoid causing the screen to flicker.

o Until user agents allow users to control blinking, avoid causing content to blink.

o Until user agents allow users to freeze moving content, avoid movement in pages.

o Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.

o Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically.

• Developers have to design sites following principles of accessible design to ensure device-independent access to a site's functionality. Checkpoint:

o Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies

• Sites must be designed to be device independent and elements should work with any input device, for example, mouse, keyboard, voice, head wand, etc.

o Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. o Make sure that any element that has its own interface can be operated in a

device-independent manner.

o For scripts, specify logical event handlers rather than device-dependent event handlers.

o Create a logical tab order through links, form controls, and objects. o Provide keyboard shortcuts to important links.

• Interim solutions must be used to ensure that older browsers and assistive technologies will operate correctly. Checkpoints, until user agents have them built in, are:

o Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user

o Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.

o Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or

some other) for all tables that lay out text in parallel, word-wrapped columns.

o Until user agents handle empty controls correctly, include default, place- holding characters in edit boxes and text areas.

o Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.

• World Wide Web Consortium (W3C) technologies and guidelines must be used during site design. W3C specifications were drawn up with accessibility in mind, they get reviewed regularly and they are developed in an open, industry- consensus process. Checkpoints for this guideline are:

o Use the latest versions of W3C technologies when they are available and appropriate for a task.

o Avoid deprecated features of W3C technologies.

o Provide information so that users may receive documents according to their preferences.

• Provide contextual information about grouping complex elements or pages. Complex relationships between pages may be difficult for people with cognitive or visual disabilities to interpret. Checkpoints to follow are:

o Title each frame to facilitate frame identification and navigation.

o Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone

o Divide large blocks of information into more manageable groups. o Associate labels explicitly with their controls.

• Keep navigation mechanisms clear and consistent. Consistency will make the site easier to use for all users. Checkpoints for navigation are:

o Clearly identify the target of each link.

o Provide metadata to add semantic information to pages and sites. The semantic web is an evolving extension of the World Wide Web in which Web content can be expressed not only in natural language, but also in a form that can be understood, interpreted and used by software agents, thus permitting them to find, share and integrate information more easily (Wikipedia, 2007b).

o Provide information about the general layout of a site. o Use navigation mechanisms in a consistent manner.

o Group-related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

o If search functions are provided, enable different types of searches for different skill levels and preferences.

o Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

o Provide information about document collections (i.e., documents comprising multiple pages.).

o Provide a means to skip over multi-line American Standard Code for Information Interchange (ASCII) art.

• The use of consistent page layout, recognisable graphics and easy to understand language benefit all users. Clear and simple language usage promotes effective communications. Checkpoints are:

o Use the clearest and simplest language appropriate for a site's content. o Supplement text with graphic or auditory presentations where they will

facilitate comprehension of the page.

o Create a style of presentation that is consistent across pages.

The guidelines discussed above aim at ensuring that people with disabilities get equal access to information contained on websites. Furthermore, they aim at making sites accessible to all users using various types of devices as well as older and different

browsers. Each guideline aims at benefiting a certain disability group at once and, at the same time, the Web community as a whole.

To assist developers in implementing an accessible website, the WAI suggests the following implementation plan (Web Accessibility Initiative, 2002):

• Establish responsibilities - Establish a coordination team with a communication plan. This team should include members from key departments like Web development and marketing. In decentralised organisations, members from different regions should be included. A team member to track new techniques for accessibility should be defined, as well as a high-level spokesperson for accessibility.

• Conduct initial assessment - Find out whether the organisation is subject to external requirements regarding Web accessibility. Check requirements early in the process. A quick initial assessment of the website can provide information about the potential extent of the problems. An assessment of current awareness of the need for Web accessibility by survey or interviews within the organisation should be done. Estimate resources required to address the needs identified in the initial assessment.

• Develop organisational policy – Determine whether or not the organisation has an existing policy on website design and technologies. If not, establish an organisational policy on Web accessibility based on accessibility standards and guidelines. Develop initial and ongoing promotion plans to increase awareness of the organisation's policy, internally and externally. The new organisational policy should be announced through briefing and other organisational communications. • Select software – Authoring software most conformant to that accessibility

guidelines and standards should be selected. Software should be installed using recommended configurations which support production of accessible content. Select software for evaluating and repairing Web accessibility and develop a Web publishing process to counter any shortcomings of selected software.

• Provide training - Plan a range of training options to meet the needs of people with different roles in the organisation. Offer repeated training opportunities as staff and responsibilities change.

• Develop an accessible website - Make accessibility a priority throughout the development process and provide the development team with tools to ensure accessibility.

• Promote organisational awareness – Include the Web accessibility policy into key documents where appropriate and regularly reinforce the organisation's policy on Web accessibility.

• Monitor website accessibility - Specify the evaluation process to be used for website accessibility, and ensure quality of the process. Conduct ongoing monitoring of the organisation's website. Invite and respond to user feedback on the organisation's website. Periodically review all aspects of implementation plan for effectiveness.

Related documents