WD-WAI-PAGEAUTH-19980918-table
W3C Working Draft -18 September 1998
This is an alternate, table view of the WAI Page Author Guidelines. The normative version of the guidelines is non-tabular and is at http://www.w3.org/TR/WD-WAI-PAGEAUTH
This document is a list of guidelines that page authors should follow in order to make their pages more accessible for people with disabilities as well as more useful to other users, new page viewing technologies (mobile and voice), and electronic agents such as indexing robots. Tools that generate documents in HTML (authoring tools, file conversion packages, or other products) should make it easy for authors to produce documents that follow these guidelines. This document is part of a series of accessibility documents published by the Web Accessibility Initiative.
Accessibility does not mean minimal page design, it means thoughtful page design. These guidelines outline procedures for authors, particularly those using multimedia content, to ensure that the content and functions provided by those elements are available to all users. In general, authors should not be discouraged from using multimedia, but rather should use it in a manner which ensures that the material they publish is accessible to the widest possible audience.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the WAI GL Working Group.
This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a Proposed Recommendation for authoring accessible Web pages. The goal of the WAI-GL working group is discussed in our charter.
Please send detailed comments on this document to w3c-wai-gl@w3.org. Public comments about the WAI author guidelines can also be sent to this mailing list.
Each Guideline and each Technique has a priority listed. For the guidelines, the priority refers to the importance of addressing the issue identified by the guideline. For Techniques, the priority refers to which technique best improves accessibility with respect to this guideline. For example, a Priority 1 Guideline may have a Priority 1 Technique, which must be done to provide accessibility, and a Priority 3 Technique, which may also be done to help address the issue.
To "transform gracefully" means that a page remains usable despite user, technological, or situational constraints. In order to use the page at all, some users may need to "turn off" features specified by the author (font size, color combinations, etc.). For example, a person with low vision might need to display all text in 36-point font, so any formatting based on an author-determined font size will fall apart.
To create documents that transform gracefully, authors should:
Guidelines A.1 - A.12 address these issues.
Guideline | Rationale | Techniques | |
---|---|---|---|
1. | Provide alternative text for all images, applets, and image maps. [Priority 1] This includes images used as submit buttons, bullets in lists, and all of the links within an image map as well as invisible images used to layout a page. Alternative text does not describe the visual appearance of an image, applet, or image map. Rather, it is used to represent the function that the image, applet, or image map performs whether it be decorative, informative, or for purposes of layout. |
|
|
2. | Provide descriptions for important graphics, scripts, or applets if they are not fully described through alternative text or in the document's content. [Priority1] | Otherwise, important information presented graphically (charts, billboards, diagrams) will not be perceivable to people with blindness, some people with low vision, and users who have chosen not to view graphics, scripts, or applets or whose browser does not support scripts or applets. |
|
3. | Provide textual equivalents (captions) for all audio information. If the audio is associated with a visual presentation (movie or animation), synchronize the textual equivalents with the visual presentation. [Priority 1] | Otherwise, users who are deaf, or hard of hearing, or any user who cannot or has chosen not to hear sound cannot perceive the information presented through speech, sound effects, music, etc. |
|
4. | Provide verbal descriptions of moving visual information in both auditory and text form (for movies, animations, etc.).If the visual presentation is associated with an auditory presentation (e.g., for a movie), synchronize the audio version of the descriptions with the existing auditory presentation and collate the text version of the descriptions with the text transcript (captions) of the primary audio track. [Priority 1] | Otherwise, if actions, body language, or other visual cues present information that is not expressed through auditory means as well (through dialogue, sound effects, etc.), users who cannot see (or look at) the page will not be able to perceive it. The collated text version allows access to the information by devices that do not play movies and by people who are deaf-blind. |
|
5. | Ensure that text and graphics are perceivable and understandable when viewed without color. [Priority 1] | Otherwise, if color
is used to convey information, users who cannot differentiate
between certain colors (and users with devices that
have non-color or non-visual displays) will not receive the
information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color blindness. |
|
6. | Indicate structure with structural elements, and control presentation with presentation elements and style sheets. [Priority 2] |
When structural elements and attributes are used to create presentation effects, user agents that allow users to navigate through the structure will be unable to do so properly. Such practices also make it difficult to render the page on other media and devices. For instance, don't use H1 to create large, bold face text unless that text is actually a top-level heading. |
|
7. | Ensure
that moving, blinking, scrolling, or auto-updating objects or pages
may be paused or frozen. This is particularly important for objects
that contain text. [Priority 1]
Note. This does not apply to instant redirection. |
Some people with cognitive limitations or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second. |
Note 1. BLINK and MARQUEE are not defined in any W3C HTML specification and should not be used. See C.1 Note 2. See also A.4.1 which discusses animated "gifs." |
8. | Provide supplemental information needed to pronounce or interpret abbreviated or foreign text. [Priority 2] | Unless changes between multiple languages on the same page are identified, and expansions for abbreviations and acronyms are provided, they may be indecipherable when spoken or brailled. |
|
9. | Ensure that pages using newer W3C features (technologies) will transform gracefully into an accessible form if the feature is not supported or is turned off. Some more recent features that are not completely backwards compatible include frames, scripts, style sheets, and applets. [Priority 1] | Each release of HTML has included new language features. For example, HTML 4.0 added the ability to attach style sheets to a page and to embed scripts and applets into a page. Older browsers ignore new features and some users configure their browser not to make use of new features. These users often see nothing more than a blank page or an unusable page when new features do not transform gracefully. For example, if you specify an image as the source of a frame (via the "src" attribute), then there is no simple way to attach alt-text (see A.1) to that image. |
See also C.1.2 - alternative pages. |
10. | Elements that contain their own user interface should have accessibility built in. [Priority 2] | The accessibility of objects with their own interface is independent of the accessibility of the user agent. Accessibility must therefore be built into the objects or an alternative must be provided (see A.11.4). |
|
11. | Use features that enable activation of page elements via input devices other than a pointing device (e.g., via keyboard, voice, etc.). [Priority 1] | Someone who is using the page without sight, with voice input, or with a keyboard (or input device other than a pointing device, e.g., a mouse or braille display) will have a difficult time navigating a page if operation requires a pointing device. If a page is usable via a keyboard, it is more likely that it should also be operable via speech input, or a command line interface. Access to image maps is impossible for these users if alternatives are not provided. |
|
12. | Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. [Priority 2] | Older browsers are unable to "Tab" to edit boxes, text areas and lists of consecutive links, making it difficult to impossible for users to access them. Users not operating in a graphical environment are disoriented by being transferred to a new window without warning. | Until most users
are able to secure newer technologies that address these issues:
|
To provide context and orientation information means that additional information is provided to help users gain an understanding of the "big picture" presented by a page, table, frame, or form. Oftentimes users are limited to viewing only a portion of a page, either because they are accessing the page one word at a time (speech synthesis or braille display), or one section at a time (small display, or a magnified display).
To create documents that provide context and orientation information, authors should:
Guidelines B.1-B.3 address these issues.
Guideline | Rationale | Techniques | |
---|---|---|---|
1. | For frames, provide sufficient information to determine the purpose of the frames and how they relate to each other. [Priority 1] | Users with blindness and low vision often access the screen with "tunnel vision" and are unable to get an overview understanding of the page. Complex relationships between frames may also be difficult for people with cognitive disabilities to use. |
|
2. | Group controls, selections, and labels into semantic units. [Priority 2] | This provides contextual information about the relationship between controls, which is useful for all users. |
|
3. | Ensure that tables (not used for layout) have necessary markup to be properly restructured or presented by accessible browsers and other user agents. [Priority 1] | Many user agents
restructure tables to present them. Without appropriate markup, the
tables will not make sense when restructured. Tables also present special
problems to users of screen readers.
These guidelines benefit users that are accessing the table through auditory means (e.g., an Automobile PC which operates by speech input and output) or viewing only a portion of the page at a time (e.g., users with blindness or low vision using speech or a braille display, or other users of devices with small displays, etc.). |
|
4. | Wherever
possible, create link phrases that:
[Priority 2] |
"Auditory users," people who are blind, have difficulty seeing, or who are using devices with small or no displays are unable to scan the page quickly with their eyes and often use a list of links to get an overview of a page or to quickly find a link. When links are not descriptive enough, do not make sense when read out of context, or are not unique, the auditory user must stop to read the text surrounding each link to identify it. | Wherever possible:
|
Good design is accessible design and vice-versa. For instance, many of the practices that lead to more accessible pages also make them accessible to indexing engines as well as more usable by all users. Good design practices include consistency, generality, simplicity, reuse, and validation.
Guideline | Rationale | Techniques | |
---|---|---|---|
1 | Only use technologies defined in a W3C specification and use them in an accessible manner. Where not possible, provide an accessible alternative page that does. [Priority 1] |
Many non-HTML technologies (e.g., PDF, Shockwave, and other non-W3C data formats) used to encode information require either plug-ins or stand-alone applications that often create pages that cannot be viewed or navigated using standard Web access tools. Also, W3C technologies may be used in ways that do not transform gracefully (e.g., because the visual components are too complex, or because assistive technologies or user agents (browsers) are lacking a specific feature). By avoiding non-standard features (elements, attributes, properties, etc. only supported by a specific browser type) and ensuring that all technologies transform gracefully, your pages will be accessible to more people using a wider variety of hardware and software. Note. Not all PDF pages are accessible or readable after being run through a PDF translator. Individually test each page for readability after the translation process. If a page does not automatically translate, revise the page until its PDF representation converts appropriately through the publicly-available converter(s) or prepare and post an HTML or plain text equivalent. |
|
2. | Provide mechanisms that facilitate navigation within your site. Through good design, increase the chance that a person can easily find what they are looking for and can easily navigate throughout the site. [Priority 3] | Consistent page layouts
between pages and a clear navigation structure will not only benefit
people with cognitive disabilities, but everyone
that visits your site.
To decrease the amount of sifting readers perform to find important information, place distinguishing information at the beginning of headings, paragraphs, lists, etc. This is commonly referred to as "front-loading" and is especially helpful for people accessing information serially. |
|
3. | Create a single downloadable file for documents that exist as a series of separate pages. [Priority 3] | This helps people reading documents off-line. Currently, an archival or compression program is needed to create the single file. In the near future, user agents will be able to collate separate pages based on meta information. |
|
Validate your pages and assess the accessibility with automated tools, manual tests, and other services.
It is important to test your site with various types of browsers, older versions of current browsers, and services that emulate browsers. Testing your site with a variety of browsers and other services will allow you to gain firsthand experience of some of the issues people deal with. Adjustments to your design based on the results of tests will increase the likelihood that your site will be usable by a wide range of people and technologies.
(__) (oo) /-------\/ / | || * ||----|| ^^ ^^