Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document is a gateway to the documents describing techniques for authoring accessible content using different web technologies. It also includes information about satisfying the guidelines that is applicable in any technology. This document is intended to help authors of Web content who wish to claim conformance to "Web Content Accessibility Guidelines 2.0" [WCAG20]. While the techniques in this document should help people author content that conforms to "Web Content Accessibility Guidelines 2.0", these techniques are neither guarantees of conformance nor the only way an author might produce conforming content.
Note: This document contains a number of examples that illustrate accessible solutions but also deprecated examples that illustrate what content developers should not do. The deprecated examples are highlighted and readers should approach them with caution -- they are meant for illustrative purposes only.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show the way a Gateway Document for Techniques for WCAG 2.0 might read. This draft is not yet based on consensus of the WCAG Working Group nor has it gone through W3C process. The content of this draft has not changed significantly since the September 2000 draft of Core Techniques for WCAG 1.0.
Please refer to "Issue tracking for WCAG 2.0 Core Techniques" for a list of open issues related to this Working Draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. A list of current W3C Recommendations and other technical documents is available.
The Working Group welcomes comments on this document at public-comments-wcag20@w3.org. The archives for this list are publicly available. Archives of the WCAG WG mailing list discussions are also publicly available.
Patent disclosures relevant to this specification may be found on the WCAG Working Group's patent disclosure page in conformance with W3C policy.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.
Introduction on princ. 1
All non-text content that can be expressed in words should have a text equivalent of the function or information that the non-text content was intended to convey.
Text is considered accessible to almost all users since it may be interpreted by screen readers, non-visual browsers, and braille readers. It may be displayed visually, magnified, synchronized with a video to create a caption, etc. As you design a document containing non-textual information (images, applets, sounds, multimedia presentations, etc.), you should supplement that information with textual equivalents wherever possible.
When a text equivalent is presented to the user, it fulfills essentially the same function (to the greatest extent possible) as the original content. For simple content, a text equivalent may need only describe the function or purpose of the content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include more verbose descriptive information.
Text equivalents must be provided for logos, photos, image buttons, applets, bullets in lists, ASCII art, and all of the links within an image map as well as invisible images used to lay out a page.
Editorial Note: This (actually almost all of the) content is way to HTML specific and it needs to be generalized.
A good test to determine if a text equivalent is useful is to imagine reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?
Text equivalents are often dependant on context where the content with the equivalent is used to give an example the author's point. Although a thorough text equivalent such as a complete description of the contents of a photograph can be reused, it may often need to be adapted and it is important that authors consider context when using pre-written text equivalents.
For example, a map can be described by the relationship between a number of points. However in many cases the map is there to illustrate a primary route from one place to another, this is what should be emphasized in the text equivalent. That does not preclude also including more surrounding information but it is important that additional information does not obscure the main point.
Text equivalents are not always appropriate, or sometimes they give additional information which may not be useful to all users. It is important not to overload users with information which may not be necessary.
For example in HTML text equivalents can be added using the alt, title and longdesc attributes. In some cases using title is more appropriate than alt text since most screen reader user agents allow reading the title as optional for people who want more information. An image might be used to represent the subsequent link is to a PDF. By using the title rather than alt attribute to signify that the link is to a PDF information is only read to those people who have their screen readers enabled to read the title. This is because the information could be considered ancillary. This way in a document with 50 links the user is not inundated with the same information which they may not want again and again, but still has the option to turn it on.
Editorial Note: The techs task force has agreed on the point, but we need a better example since the use of title is not always implemented.
For more information on how to write good quality text alternatives (specific examples given in HTML) please refer to [RNIB].
Editorial Note: I am still not entirely happy is there something better or should we write our own?
Provide text equivalents to describe visual and auditory elements.
Editorial Note: @@ Joe Clark has agreed to write a proposal for this section. Possibly from scratch.
When necessary, a text equivalent should be provided for visual and auditory information to enable understanding of the page. For example, consider a repeating animation that shows cloud cover and precipitation as part of a weather status report. Since the animation is supplementing the rest of the weather report (that is presented in natural language - text), a less verbose description of the animation is necessary. However, if the animation appears in a pedagogical setting where students are learning about cloud formations in relation to land mass, then the animation ought to be described for those who can not view the animation but who also want to learn the lesson.
Editorial Note: Since HTML is not a multimedia format I don't think we can say anything in HTML Techniques about how to provide text equivalents for multimedia. That information should be in SMIL, SVG, scripting, and cross-technology techniques. From the previous section (on embedding multimedia and programmatic objects) we should link to these other sections that will provide information on writing and synchronizing media equivalents. Thus, I propose we delete this section.
@@
Ensure that you have provided text transcripts of audio and video content.
Editorial Note: @@ Joe Clark has agreed to write a proposal for this section. Possibly from scratch.
Collated text transcripts allow access by people with both visual and hearing disabilities. They also provide everyone with the ability to index and search for information contained in audio/visual materials.
Collated text transcripts include spoken dialogue as well as any other significant sounds including on-screen and off-screen sounds, music, laughter, applause, etc. In other words, all of the text that appears in captions as well as all of the descriptions provided in the audio description.
Audio descriptions of the visual track provide narration of the key visual elements without interfering with the audio or dialogue of a movie. Key visual elements include actions, settings, body language, graphics, and displayed text. Audio descriptions are used primarily by people who are blind to follow the action and other non-audio information in video material.
Note. If there is no important visual information, for example, an animated talking head that describes (through prerecorded speech) how to use the site, then an audio description is not necessary.
For movies, provide audio descriptions that are synchronized with the original audio. Refer to the section on audio information for more information about multimedia formats.
Here's an example of a collated text transcript of a clip from "The Lion King" (available at [DVS]). Note that the Describer is providing the audio description of the video track and that the description has been integrated into the transcript.
Simba: Yeah! Describer: Simba races outside, followed by his parents. Sarabi smiles and nudges Simba gently toward his father. The two sit side-by-side, watching the golden sunrise. Mufasa: Look Simba, everything the light touches is our kingdom. Simba: Wow.
Provide Illustrations to supplement the text where appropriate, to aid explanation difficult or complex concepts.
For people who do not read well or not at all, multimedia (non-text) equivalents may help facilitate comprehension. Beware that multimedia presentations do not always make text easier to understand. Sometimes, multimedia presentations may make it more confusing.
Examples of multimedia that supplement text:
A chart of complex data, such as sales figures of a business for the past fiscal year.
A translation of the text into a Sign Language movie clip. Sign Language is a very different language than spoken languages. For example, some people who may communicate via American Sign Language may not be able to read American English.
Pre-recorded audio of music, spoken language, or sound effects may also help non-readers who can perceive audio presentations. Although text may be generated as speech through speech synthesis, changes in a recorded speaker's voice can convey information that is lost through synthesis.
Editorial Note: @@ Joe Clark has agreed to write a proposal for this section.
Ensure both [information/substance] and structure are separable from presentation.
When designing a document or series of documents, content developers should strive first to identify the desired structure for their documents before thinking about how the documents will be presented to the user. Distinguishing the structure of a document from how the content is presented offers a number of advantages, including improved accessibility, manageability, and portability.
Identifying what is structure and what is presentation may be challenging at times. For instance, many content developers consider that a horizontal line communicates a structural division. This may be true for sighted users, but to unsighted users or users without graphical browsers, a horizontal line may have next to no meaning. For example, in HTML content developers should use the HTML 4.01 [HTML4] heading elements (H1-H6) to identify new sections. These may be complemented by visual or other cues such as horizontal rules, but should not be replaced by them.
Editorial Note: This paragraph is HTML-specific. Need broader range of examples, or more generic explanation.
The inverse holds as well: content developers should not use structural elements to achieve presentation effects. For instance in HTML, even though the BLOCKQUOTE element may cause indented text in some browsers, it is designed to identify a quotation, not create a presentation side-effect. BLOCKQUOTE elements used for indentation confuse users and search robots alike, who expect the element to be used to mark up block quotations.
Editorial Note: Will this example make any sense to someone who doesn't know HTML?
The separation of presentation from structure in XML documents is inherent. As Norman Walsh states in "A Guide to XML" [WALSH], "HTML browsers are largely hard coded. A first level heading appears the way it does because the browser recognizes the H1 tag. Again, since XML documents have no fixed tag set, this approach will not work. The presentation of an XML document is dependent on a stylesheet."
To determine if content is structural or presentational, create an outline of your document. Each point in the hierarchy denotes a structural change. Use structural markup to mark these changes and presentational markup to make them more apparent visually and aurally. Notice that horizontal rules will not appear in this outline and therefore are not structural, but presentational. Note. This quicktest addresses chapter, section, and paragraph structure. To determine structure within phrases, look for abbreviations, changes in natural language, definitions, and list items.
Ensure the structure has been made perceivable to more people through presentation(s), positioning, and labels.
Editorial Note: This needs a rewrite
Ensure that visual motion does not make content unreadable.
Editorial Note: Most of this is covered in 2.2.2 Animated Content. It is not obvious how to split up the topics of animation and control. Perhaps this section should just have a reference to 2.2.2. Alternatively it could have the section on animated images and a reference to 2.2.2.
Ensure that foreground content is easily differentiable from background for visual presentations.
Many people see disabilities as absolute, people are either completely impaired or not at all. This is not the case, the vast majority of disabilities are partial disabilities, people having a range of ability. As such it is important that people with a partial disability can differentiate between content and background. In auditory content this means good sound quality and that background noise is kept to a minimum. Visually users have a variety of contract needs. Some users also have issues with color. See section on color.
Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.
People with color deficits have trouble seeing viewing certain combinations of color together. People with non color related vision impairments can also hindered from reading content with a lack on color contrast, when it is combined with other issues such as size. This means that it is important to select colors which provide sufficient contrast to be readable for a variety of needs.
An example of good color contrast is the document that you are reading, which is by default rendered in black text on white. Sometimes other colors of background are used but they also provide high contrast with the black text. This does not mean that the only colors used must be black and white, it does however provide insight into the contrast needed to identify letters on a page.
Editorial Note: Add in a page with fading shades of yellow on white, to illustrate lower and lower color contrast.
People who have color defect in their vision also have specific needs related to the colors they can and can't contrast. Color deficits are caused by different things but have the same effect, they cause ranges of color to be viewed in non differentiable shades often grey. The three main color deficits are protanopia, deuteranopia, and tritanopia. These are deficiencies of sensitivity to the red, green and blue spectrums of light respectively. Protanopia and deuteranopia causes an inability to differentiate between red and green, although protanopia also causes reds to look darker. Tritanopia, causes a lack of differentiation between blues and greens. All these color deficits are individual and although there each individual person with a color deficit may see colors differently they have common characteristics which allows a general approach to be taken which can address many of their needs.
@@
@@
Ensure that audio presentations contain sufficient contrast to be perceivable by someone with a hearing deficit.
Provide a text transcript with Audio content to allow users to follow along with audio content.
Audio presentations must be accompanied by text transcripts, textual equivalents of audio events. When these transcripts are presented synchronously with a video presentation they are called captions and are used by people who cannot hear the audio track of the video material.
Some media formats (e.g., QuickTime 3.0 and SMIL) allow captions and video descriptions to be added to the multimedia clip. SAMI allows captions to be added. The following example demonstrates that captions should include speech as well as other sounds in the environment that help viewers understand what is going on.
Until the format you are using supports alternative tracks, two versions of the movie could be made available, one with captions and audio descriptions, and one without. Some technologies, such as SMIL and SAMI, allow separate audio/visual files to be combined with text files via a synchronization file to create captioned audio and movies.
Some technologies also allow the user to choose from multiple sets of captions to match their reading skills. For more information see the SMIL 1.0 ([SMIL]) specification.
Editorial Note: reference to SMIL techniques?
Equivalents for sounds can be provided in the form of a text phrase on the page that links to a text transcript or description of the sound file. The link to the transcript should appear in a highly visible location such as at the top of the page. However, if a script is automatically loading a sound, it should also be able to automatically load a visual indication that the sound is currently being played and provide a description or transcript of the sound.
Note. Some controversy surrounds this technique because the browser should load the visual form of the information instead of the auditory form if the user preferences are set to do so. However, strategies must also work with today's browsers.
For more information, please refer to [NCAM].
Editorial Note: reference to Joe Clark's work?
Captions for a scene from "E.T." The phone rings three times, then is answered.
[phone rings] [ring] [ring] "Hello?"
Ensure that all functionality is operable at a minimum through a keyboard or a keyboard interface.
Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links, activate form controls, etc. Content developers must ensure that users may interact with a page with devices other than a pointing device. A page designed for keyboard access (in addition to mouse access) will generally be accessible to users with other input devices. What's more, designing a page for keyboard access will usually improve its overall design as well.
Keyboard access to links and form controls may be specified in a few ways: Provide keyboard shortcuts so that users may combine keystrokes to navigate links or form controls on a page. Note. Keyboard shortcuts -- notably the key used to activate the shortcut -- may be handled differently by different operating systems. On Windows machines, the "alt" and "ctrl" key are most commonly used while on a Macintosh, it is the apple or "clover leaf" key. Refer to the Keyboard access for links and Keyboard Access to Forms sections for examples.
Editorial Note: Update references to WCAG10. Should we even be including pointers to technology specific items in our gateway discussion?
Provide a logical tab order through the content.
Tabbing order describes a (logical) order for navigating from link to link or form control to form control (usually by pressing the "tab" key, hence the name).
Editorial Note: Other ideas for this section: strategies to navigate into long lists, jump over chunks into middle of chunks; how structure relates to navigation; workflow; relation to UAAG; menus and scripting, keyboard access
Ensure that users can control any time limits on their reading, interaction, or responses unless control is not possible due to nature of real time events or competition.
Content developers sometimes create pages that refresh or change without the user requesting the refresh. This automatic refresh can be very disorienting to some users. Instead, in order of preference, authors should:
Configure the server to use the appropriate HTTP status code (301). Using HTTP headers is preferable because it reduces Internet traffic and download times, it may be applied to non-HTML documents, and it may be used by agents who requested only a HEAD request (e.g., link checkers). Also, status codes of the 30x type provide information such as "moved permanently" or "moved temporarily" that cannot be given with META refresh.
Replace the page that would be redirected with a static page containing a normal link to the new page.
Ensure that animated content has mechanisms that allow the user to pause the animation.
Animations can make a page more visually appealing, however for some people with cognitive disabilities some animation can be distracting to the point of making a page unusable. Animating content can also make it difficult for people with visual impairments who are unable to track content which is moving faster than they can read it.
It is important that content which is displayed as animation takes account of user needs. This means that it is important that animations finish by themselves after a short duration, or has a mechanism by which they can be stopped. Some types of animation, such as images (gif, png) are not powered by a 'player' which would allow the user to pause animation. This means that animations provided by images should stop after one or two loops of the animation or some other reasonable amount of time. It is also important to be aware that if all the content is not present on screen at the end of the animation many users may have been unable to perceive that content, and will have lost its value. As such animated images should only include content which is duplicated or is shown in its entirety at the end of the image.
Editorial Note: Check if, and which browser allow gif animations to be turned off. Is this a UUAG requirement?? Any source on what is reasonable??
For animations provided by an interpreted set of code such as SVG or Flash it is important to ensure that the browser or plug-in capabilities to pause or stop the animation are both enabled and able to function. If the browser of plug-in mechanism is unable to pause an animation you must provide a mechanism within the content to pause or stop its motion. This may be a beneficial feature for all users not just those with disabilities, who may find animated content difficult to track, and may not realize a browser or plug-in method exists to pause content.
Editorial Note: Probably can't refer to non-w3c tech, is there a name for these types of animated content?
Editorial Note: Add some example of images which stop at the end of their animations, and some SVG examples of animation which are difficult to track and a mechanism to allow users to pause them.
Ensure that users can avoid experiencing screen flicker.
A flickering or flashing screen may cause seizures in users with photosensitive epilepsy and content developers should thus avoid causing the screen to flicker. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).
Editorial Note: A lot of this is now in the Guidelines, need to discuss with the WCAG WG how much should here. Also need information on testing and a reference to Trace's new tool. (currently in the Guideline) depending on the resolution of the WG.
Ensure that structure and/or alternate navigation mechanisms have been added to facilitate orientation and movement in content.
Use metadata to describe collections.
Editorial Note: Is this going to be moved to Server-side/RDF techniques (under the banner of metadata)? Does it still need a mention here without specific implementations?
Bundled documents can facilitate reading offline. To create a coherent package:
Use metadata to describe the relationships between components of the package (refer to link metadata for HTML).
Use archiving tools such as zip, tar and gzip, and StuffIt to create the package.
Ensure that the language of content can be programmatically determined.
Where the technology support it ensure that all content is provided with a primary language, specified with an international language code specified in the document. When a change of language occurs make a note of the change of language with a mechanism provided by the technology. Often in languages include 'borrowed' words. For example English takes the phrase 'laissez faire' from the French, however it has been almost naturalized into the language. Many authors would choose not to mark this as a change of language because it has been naturalized, however screen readers and audio browsers are not capable of pronouncing this correctly without the language change being noted. 'Laissez faire' is pronounced "lay-sez fair" however a screen reader might pronounce it "la-is-sez fair-ee" because it is trying to apply English grammar rules to the word. This will not be true of all borrowed words but authors should be aware of the issue and try to ensure that phrases which may be mispronounced by assistive technology are marked up as a change in language.
Editorial Note: Add a reference to the language codes.
It is imperative however that any significant changes in language of a document are marked up. If a document contains several primary languages, it should be marked with the primary language as that with the most content and the rest declared individually in blocks.
Ensure that all characters and words in the content can be unambiguously decoded.
Editorial Note: This has been carried over from WCAG 1.0. I (Tom) am slightly unsure as to the meaning or need implied by this technique.
Use spelling and grammar checkers.
A person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Grammar checkers will help to ensure that the textual content of your page is correct. This will help readers for whom your document is not written in their native tongue, or people who are just learning the language of the document. Thus, you will help increase the comprehension of your page.
Ensure that the definition of abbreviations and acronyms can be unambiguously determined.
Editorial Note: References to dictionaries, and site wide glossary definitions. Perhaps use the w3.org as an example.
Ensure that the content writing is simple and well organized.
Editorial Note: This is covered much more in-depth by the guidelines. It is unsure where this content should be. It is also very English centric. It should be discussed with the main group where this is to go and if it is merely going to refer to a techniques document for each language or whether it will be adapted during translation.
The following writing style suggestions should help make the content of your site easier to read for everyone, especially people with reading and/or cognitive disabilities. Several guides (including [HACKER]) discuss these and other writing style issues in more detail.
Strive for clear and accurate headings and link descriptions. This includes using link phrases that are terse and that make sense when read out of context or as part of a series of links (Some users browse by jumping from link to link and listening only to link text.) Use informative headings so that users can scan a page quickly for information rather than reading it in detail.
State the topic of the sentence or paragraph at the beginning of the sentence or paragraph (this is called "front-loading"). This will help both people who are skimming visually, but also people who use speech synthesizers. "Skimming" with speech currently means that the user jumps from heading to heading, or paragraph to paragraph and listens to just enough words to determine whether the current chunk of information (heading, paragraph, link, etc.) interests them. If the main idea of the paragraph is in the middle or at the end, speech users may have to listen to most of the document before finding what they want. Depending on what the user is looking for and how much they know about the topic, search features may also help users locate content more quickly.
Limit each paragraph to one main idea.
Avoid slang, jargon, and specialized meanings of familiar words, unless defined within your document.
Favor words that are commonly used. For example, use "begin" rather than "commence" or use "try" rather than "endeavor."
Use active rather than passive verbs.
Avoid complex sentence structures.
To help determine whether your document is easy to read, consider using the Gunning-Fog reading measure (described in[SPOOL] with examples and the algorithm online at [TECHHEAD]). This algorithm generally produces a lower score when content is easier to read. As example results, the Bible, Shakespeare, Mark Twain, and TV Guide all have Fog indexes of about 6. Time, Newsweek, and the Wall St. Journal an average Fog index of about 11.
Use link text to describe your target page as clearly as possible.
Good link text should not be overly general; don't use "click here." Not only is this phrase device-dependent (it implies a pointing device) it says nothing about what is to be found if the link if followed. Instead of "click here", link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page". Note that for the latter case (and other format- or language-specific documents), content developers are encouraged to use content negotiation instead, so that users who prefer text versions will have them served automatically.
Do not use the same link phrase more than once when the links point to different URLs.
If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.
If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.
Ensure that layout and behavior of content is consistent or predictable, but not identical.
A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to skip navigation mechanisms more easily to find important content. This helps people with learning and reading disabilities but also makes navigation easier for all users. Predictability will increase the likelihood that people will find information at your site, or avoid it when they so desire.
Examples of structures that may appear at the same place between pages:
navigation bars
the primary content of a page
advertising
A navigation mechanism creates a set of paths a user may take through your site. Providing navigation bars, site maps, and search features all increase the likelihood that a user will reach the information they seek at your site. If your site is highly visual in nature, the structure might be harder to navigate if the user can't form a mental map of where they are going or where they have been. To help them, content developers should describe any navigation mechanisms. It is crucial that the descriptions and site guides be accessible since people who are lost at your site will rely heavily on them.
When providing search functionality, content developers should offer search mechanisms that satisfy varying skill levels and preferences. Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.
Editorial Note: This section seems to be discussing benefits more than techniques.
Ensure that the technologies used are used according to specification.
Ensure that the technologies that are relied upon by the content are declared and widely available.
Editorial Note: This discussion needs a lot of work. We need an explicit reference to UAAG and its test suites. Need to talk about what to look for as someone reads the techniques, e.g., browser and AT support.
Support: Note. At the time of this writing, not all user agents support some of the HTML 4.01 [HTML4] attributes and elements that may significantly increase accessibility of Web pages.
Please refer to the W3C Web site ([WAI-UA-SUPPORT]) for information about browser and other user agent support of accessibility features.
In general, please note that HTML user agents ignore attributes they don't support and they render the content of unsupported elements.
Use automatic evaluation to assist in ensuring accessibility conformance
A validator can verify the syntax of your pages (e.g., HTML, CSS, XML). Correct syntax will help eliminate a number of accessibility problems since software can process well-formed documents more easily. Also, some validators can warn you of some accessibility problems based on syntax alone (e.g., a document is missing an attribute or property that is important to accessibility). Note, however, that correct syntax does not guarantee that a document will be accessible. For instance, you may provide a text equivalent for an image according to the language's specification, but the text may be inaccurate or insufficient. Some validators will therefore ask you questions and step you through more subjective parts of the analysis. Some examples of automatic validators include:
Use accessibility repair tools to fix accessibility problems found.
Validators usually report what issues to solve and often give examples of how to solve them. They do not usually help an author walk through each problem and help the author modify the document interactively. The WAI Evaluation and Repair Working Group ([WAI-ER]) is working to develop a suite of tools that will help authors not only identify issues but solve them interactively.
Use Java accessibility APIs to make applets directly accessible.
If an applet (created with either OBJECT or APPLET) requires user interaction (e.g., the ability to manipulate a physics experiment) that cannot be duplicated in an alternative format, make the applet directly accessible.
If an applet creates motion, developers should provide a mechanism for freezing this motion (for an example, refer to [TRACE]). Also, please refer to the next section for information about making audio and video presentations accessible.
For more information about developing accessible applets, please refer to [JAVAACCESS] and [IBMJAVA]. These companies have been developing an Accessibility API as well as making the Java Swing classes accessible.
Ensure that technologies used for presentation and user interface support accessibility or alternate versions of the content are provided that do support accessibility.
Brief overview of current W3C technologies:
MathML for mathematical equations
HTML, XHTML, XML for structured documents
RDF for meta data
SMIL to create multimedia presentations
CSS and XSL to define style sheets
XSLT to create style transformations
PNG for graphics (although some are best expressed in JPG, a non-w3c spec)
Editorial Note: From WCAG1 document: Are there others that we need to discuss? WebCGM? Do we want to recommend HTML over XHTML? what about CSS1 and CSS2? What about non-W3C specifications like PDF, Flash, etc.
Editorial Note: Link to Java, PDF, Flash techs?
Although it is possible to make most content accessible, it may happen that all or part of a page remains inaccessible. Additional techniques for creating accessible alternatives include:
Allow users to navigate to a separate page that is accessible, contains the same information as the inaccessible page, and is maintained with the same frequency as the inaccessible page.
Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
Editorial Note: Should move to ServerSide Techniques
Refer to the examples for Frames and Scripts.
Editorial Note: Should move to HTML techniques?
Provide a phone number, fax number, e-mail, or postal address where information is available and accessible, preferably 24 hours a day
Here are two techniques for linking to an accessible alternative page:
Provide links at the top of both the main and alternative pages to allow a user to move back and forth between them. For example, at the top of a graphical page include a link to the text-only page, and at the top of a text-only page include a link to the associated graphical page. Ensure that these links are one of the first that users will tab to by placing them at the top of the page, before other links.
Use meta information to designate alternative documents. Browsers should load the alternative page automatically based on the user's browser type and preferences
Some elements import objects (e.g., applets or multimedia players) whose interfaces cannot be controlled through the markup language. In such cases, content developers should provide alternative equivalents with accessible interfaces if the imported objects themselves do not provide accessible interfaces.
There are a variety of strategies to allow users to negotiate to select the appropriate content:
Include links to other versions of content, such as translations. For example, the link "Refer to the French version of this document" links to the French version.
Indicate content type or language through markup (e.g., in HTML use "type" and "hreflang").
Use content negotiation to serve content per the client request. For example, serve the French version of a document to clients requesting French.
Ensure the backward compatibility of the technologies used.
Editorial Note: It isn't clear where the following info should go, or even whether it is still all good advice!
Content developers must consider backward compatibility when designing Web pages or sites since:
Some user agents do not support some HTML features,
People may use older browsers or video players,
Compatibility problems may arise between software
Therefore, when designing for older technologies, consider these techniques:
Provide inline text equivalents. For example, include a description of the image immediately after the image.
Provide links to long text equivalents either in a different file or on the same page. These are called description links or "d-links". The link text should explain that the link designates a description. Where possible, it should also explain the nature of the description. However, content developers concerned about how the description link will affect the visual appearance of the page may use more discrete link text such as "[D]", which is recommended by NCAM (refer to [NCAM]). In this case, they should also provide more information about the link target so that users can distinguish links that share "[D]" as content (e.g., with the "title" attribute in HTML).
Manually test pages with various user agents and settings used by people with disabilities.
Keep in mind that most user agents (browsers) and operating systems allow users to configure settings that change the way software looks, sounds, and behaves. With the variety of user agents, different users will have very different experiences with the Web. Therefore:
Test your pages with a text-only browser such as Lynx ([LYNX]) or a Lynx emulator such as Lynx Viewer ([LYNXVIEW]) or Lynx-me ([LYNXME]).
Use multiple graphic browsers, with:
sounds and images loaded,
images not loaded,
sounds not loaded,
no mouse,
frames, scripts, style sheets, and applets not loaded.
Use several browsers, old and new. Note. Some operating systems or browsers do not allow multiple installations of the browser on the same machine. It may also be difficult to locate older browser software.
Use other tools such as a self-voicing browser (e.g., [PWWEBSPEAK] and [HOMEPAGEREADER]), a screen reader (e.g., [JAWS] and [WINVISION]), magnification software, a small display, an onscreen keyboard, an alternative keyboard, etc. Note. If a Web site is usable with one of these products it does not ensure that the site will be usable by other products. For a more detailed list of assistive technologies used to access the Web refer to ([ALTBROWSERS]).
Editorial Note: @@ add references section and other appendix information as needed