Web Content Accessibility Guidelines 1.0
`
`llllt.·'
`ffJv
`
`Web Content Accessibility Guidelines 1.0
`
`W3C Recommendation 5-May-1999
`
`This version:
`http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
`(plain text, PostScript, PDF, gzip tar file of HTML, zip archive of HTML)
`Latest version:
`http://www.w3.org/TR/WAI-WEBCONTENT
`Previous version:
`http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
`Editors:
`Wendy Chisholm, Trace R & D Center, University of Wisconsin -- Madison
`Gregg Vanderheiden, Trace R & D Center, University of Wisconsin -- Madison
`Ian Jacobs, W3C
`
`Copyright
`W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability,
`© 1999
`trademark, document use and software licensing rules apply.
`
`Abstract
`These guidelines explain how to make Web content [p. 26] accessible to people with
`disabilities. The guidelines are intended for all Web content developers [p. 26] (page
`authors and site designers) and for developers of authoring tools [p. 25] . The
`primary goal of these guidelines is to promote accessibility. However, following them
`will also make Web content more available to all users, whatever user agent [p. 30]
`they are using (e.g., desktop browser, voice browser, mobile phone,
`automobile-based personal computer, etc.) or constraints they may be operating
`under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free
`environment, etc.). Following these guidelines will also help people find information
`on the Web more quickly. These guidelines do not discourage content developers
`from using images, video, etc., but rather explain how to make multimedia content
`more accessible to a wide audience.
`This is a reference document for accessibility principles and design ideas. Some
`of the strategies discussed in this document address certain Web internationalization
`and mobile access concerns. However, this document focuses on accessibility and
`does not fully address the related concerns of other W3C Activities. Please consult
`the W3C Mobile Access Activity home page and the W3C Internationalization
`Activity home page for more information.
`
` 1
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 1 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`This document is meant to be stable and therefore does not provide specific
`information about browser support for different technologies as that information
`changes rapidly. Instead, the Web Accessibility Initiative (WAI) Web site provides
`such information (refer to [WAI-UA-SUPPORT] [p. 33] ).
`This document includes an appendix that organizes all of the checkpoints [p. 7] by
`topic and priority. The checkpoints in the appendix link to their definitions in the
`current document. The topics identified in the appendix include images, multimedia,
`tables, frames, forms, and scripts. The appendix is available as either a tabular
`summary of checkpoints or as a simple list of checkpoints.
`A separate document, entitled "Techniques for Web Content Accessibility
`Guidelines 1.0" ([TECHNIQUES] [p. 33] ), explains how to implement the
`checkpoints defined in the current document. The Techniques Document discusses
`each checkpoint in more detail and provides examples using the Hypertext Markup
`Language (HTML), Cascading Style Sheets (CSS), Synchronized Multimedia
`Integration Language (SMIL), and the Mathematical Markup Language (MathML).
`The Techniques Document also includes techniques for document validation and
`testing, and an index of HTML elements and attributes (and which techniques use
`them). The Techniques Document has been designed to track changes in
`technology and is expected to be updated more frequently than the current
`document. Note. Not all browsers or multimedia tools may support the features
`described in the guidelines. In particular, new features of HTML 4.0 or CSS 1 or CSS
`2 may not be supported.
`"Web Content Accessibility Guidelines 1.0" is part of a series of accessibility
`guidelines published by the Web Accessibility Initiative. The series also includes
`User Agent Accessibility Guidelines ([WAI-USERAGENT] [p. 33] ) and Authoring
`Tool Accessibility Guidelines ([WAI-AUTOOLS] [p. 33] ).
`
`Status of this document
`This document has been reviewed by W3C Members and other interested parties
`and has been endorsed by the Director as a W3C Recommendation. It is a stable
`document and may be used as reference material or cited as a normative reference
`from another documents. W3C’s role in making the Recommendation is to draw
`attention to the specification and to promote its widespread deployment. This
`enhances the functionality and universality of the Web.
`The English version of this specification is the only normative version. However,
`for translations in other languages see
`http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
`The list of known errors in this document is available at
`http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA. Please report errors in
`this document to wai-wcag-editor@w3.org.
`
` 2
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 2 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`A list of current W3C Recommendations and other technical documents can be
`found at http://www.w3.org/TR.
`This document has been produced as part of the W3C Web Accessibility Initiative.
`The goal of the Web Content Guidelines Working Group is discussed in the Working
`Group charter.
`
` 3
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 3 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`Table of Contents
`
`Abstract
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Status of this document
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`1. Introduction
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2. Themes of Accessible Design
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2.1 Ensuring Graceful Transformation
`.
`.
`.
`.
`.
`.
`.
`.
`2.2 Making Content Understandable and Navigable
`.
`.
`.
`.
`.
`3. How the Guidelines are Organized
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3.1 Document conventions
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4. Priorities
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`5. Conformance
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`6. Web Content Accessibility Guidelines
`.
`.
`.
`.
`.
`1. Provide equivalent alternatives to auditory and visual content.
`.
`.
`2. Don’t rely on color alone.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3. Use markup and style sheets and do so properly.
`.
`.
`.
`.
`.
`4. Clarify natural language usage
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`5. Create tables that transform gracefully.
`.
`.
`6. Ensure that pages featuring new technologies transform gracefully.
`7. Ensure user control of time-sensitive content changes.
`.
`.
`.
`.
`.
`.
`8. Ensure direct accessibility of embedded user interfaces.
`.
`.
`.
`9. Design for device-independence.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`10. Use interim solutions.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`11. Use W3C technologies and guidelines.
`.
`.
`.
`.
`.
`.
`12. Provide context and orientation information.
`.
`.
`.
`.
`.
`.
`13. Provide clear navigation mechanisms.
`.
`.
`.
`.
`.
`.
`14. Ensure that documents are clear and simple.
`.
`.
`.
`.
`.
`Appendix A. -- Validation
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Appendix B. -- Glossary
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Acknowledgments
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`References
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`
`.1
`
`
`.2
`
`.5
`
`.6
`
`.6
`
`.7
`
`.7
`
`.8
`
`.8
`
`.8
`
`.10
`
`.10
`
`.11
`
`.12
`
`.13
`
`.14
`.15
`
`.16
`
`.17
`
`.18
`
`.18
`
`.20
`
`.21
`
`.22
`
`.23
`
`.24
`
`.25
`
`.31
`
`.32
`
`The appendix list of checkpoints is available as either a tabular summary of
`checkpoints or as a simple list of checkpoints.
`
` 4
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 4 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`1. Introduction
`For those unfamiliar with accessibility issues pertaining to Web page design,
`consider that many users may be operating in contexts very different from your own:
`•
`•
`•
`•
`•
`•
`•
`
`They may not be able to see, hear, move, or may not be able to process some
`types of information easily or at all.
`They may have difficulty reading or comprehending text.
`They may not have or be able to use a keyboard or mouse.
`They may have a text-only screen, a small screen, or a slow Internet
`connection.
`They may not speak or understand fluently the language in which the document
`is written.
`They may be in a situation where their eyes, ears, or hands are busy or
`interfered with (e.g., driving to work, working in a loud environment, etc.).
`They may have an early version of a browser, a different browser entirely, a
`voice browser, or a different operating system.
`
`Content developers must consider these different situations during page design.
`While there are several situations to consider, each accessible design choice
`generally benefits several disability groups at once and the Web community as a
`whole. For example, by using style sheets [p. 29] to control font styles and
`eliminating the FONT element, HTML authors will have more control over their
`pages, make those pages more accessible to people with low vision, and by sharing
`the style sheets, will often shorten page download times for all users.
`The guidelines discuss accessibility issues and provide accessible design
`solutions. They address typical scenarios (similar to the font style example) that may
`pose problems for users with certain disabilities. For example, the first guideline
`[p. 10] explains how content developers can make images accessible. Some users
`may not be able to see images, others may use text-based browsers that do not
`support images, while others may have turned off support for images (e.g., due to a
`slow Internet connection). The guidelines do not suggest avoiding images as a way
`to improve accessibility. Instead, they explain that providing a text equivalent [p. 27]
`of the image will make it accessible.
`How does a text equivalent make the image accessible? Both words in "text
`equivalent" are important:
`•
`
`Text content can be presented to the user as synthesized speech, braille, and
`visually-displayed text. Each of these three mechanisms uses a different sense
`-- ears for synthesized speech, tactile for braille, and eyes for visually-displayed
`text -- making the information accessible to groups representing a variety of
`sensory and other disabilities.
`In order to be useful, the text must convey the same function or purpose as the
`image. For example, consider a text equivalent for a photographic image of the
`Earth as seen from outer space. If the purpose of the image is mostly that of
`
`•
`
` 5
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 5 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`decoration, then the text "Photograph of the Earth as seen from outer space"
`might fulfill the necessary function. If the purpose of the photograph is to
`illustrate specific information about world geography, then the text equivalent
`should convey that information. If the photograph has been designed to tell the
`user to select the image (e.g., by clicking on it) for information about the earth,
`equivalent text would be "Information about the Earth". Thus, if the text conveys
`the same function or purpose for the user with a disability as the image does for
`other users, then it can be considered a text equivalent.
`
`Note that, in addition to benefitting users with disabilities, text equivalents can help
`all users find pages more quickly, since search robots can use the text when
`indexing the pages.
`While Web content developers must provide text equivalents for images and other
`multimedia content, it is the responsibility of user agents [p. 30] (e.g., browsers and
`assistive technologies such as screen readers [p. 29] , braille displays [p. 26] , etc.)
`to present the information to the user.
`Non-text equivalents of text (e.g., icons, pre-recorded speech, or a video of a
`person translating the text into sign language) can make documents accessible to
`people who may have difficulty accessing written text, including many individuals
`with cognitive disabilities, learning disabilities, and deafness. Non-text equivalents of
`text can also be helpful to non-readers. An auditory description [p. 28] is an example
`of a non-text equivalent of visual information. An auditory description of a multimedia
`presentation’s visual track benefits people who cannot see the visual information.
`
`2. Themes of Accessible Design
`The guidelines address two general themes: ensuring graceful transformation, and
`making content understandable and navigable.
`
`2.1 Ensuring Graceful Transformation
`By following these guidelines, content developers can create pages that transform
`gracefully. Pages that transform gracefully remain accessible despite any of the
`constraints described in the introduction [p. 5] , including physical, sensory, and
`cognitive disabilities, work constraints, and technological barriers. Here are some
`keys to designing pages that transform gracefully:
`•
`•
`
`Separate structure from presentation (refer to the difference between content,
`structure, and presentation [p. 26] ).
`Provide text (including text equivalents [p. 27] ). Text can be rendered in ways
`that are available to almost all browsing devices and accessible to almost all
`users.
`Create documents that work even if the user cannot see and/or hear. Provide
`information that serves the same purpose or function as audio or video in ways
`suited to alternate sensory channels as well. This does not mean creating a
`prerecorded audio version of an entire site to make it accessible to users who
`
`•
`
` 6
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 6 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`•
`
`are blind. Users who are blind can use screen reader [p. 29] technology to
`render all text information in a page.
`Create documents that do not rely on one type of hardware. Pages should be
`usable by people without mice, with small screens, low resolution screens, black
`and white screens, no screens, with only voice or text output, etc.
`
`The theme of graceful transformation is addressed primarily by guidelines 1 to 11.
`
`2.2 Making Content Understandable and Navigable
`Content developers should make content understandable and navigable. This
`includes not only making the language clear and simple, but also providing
`understandable mechanisms for navigating within and between pages. Providing
`navigation tools and orientation information in pages will maximize accessibility and
`usability. Not all users can make use of visual clues such as image maps,
`proportional scroll bars, side-by-side frames, or graphics that guide sighted users of
`graphical desktop browsers. Users also lose contextual information when they can
`only view a portion of a page, either because they are accessing the page one word
`at a time (speech synthesis or braille display [p. 26] ), or one section at a time (small
`display, or a magnified display). Without orientation information, users may not be
`able to understand very large tables, lists, menus, etc.
`The theme of making content understandable and navigable is addressed
`primarily in guidelines 12 to 14.
`
`3. How the Guidelines are Organized
`This document includes fourteen guidelines, or general principles of accessible
`design. Each guideline includes:
`
`•
`•
`•
`
`•
`•
`
`The guideline number.
`The statement of the guideline.
`Guideline navigation links. Three links allow navigation to the next guideline
`(right arrow icon), the previous guideline (left arrow icon), or the current
`guideline’s position in the table of contents (up arrow icon).
`The rationale behind the guideline and some groups of users who benefit from
`it.
`A list of checkpoint definitions.
`
`The checkpoint definitions in each guideline explain how the guideline applies in
`typical content development scenarios. Each checkpoint definition includes:
`
`•
`•
`•
`•
`
`The checkpoint number.
`The statement of the checkpoint.
`The priority of the checkpoint. Priority 1 checkpoints are highlighted through the
`use of style sheets.
`Optional informative notes, clarifying examples, and cross references to related
`
` 7
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 7 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`•
`
`guidelines or checkpoints.
`A link to a section of the Techniques Document ([TECHNIQUES] [p. 33] ) where
`implementations and examples of the checkpoint are discussed.
`
`Each checkpoint is intended to be specific enough so that someone reviewing a
`page or site may verify that the checkpoint has been satisfied.
`
`3.1 Document conventions
`The following editorial conventions are used throughout this document:
`
`Element names are in uppercase letters.
`Attribute names are quoted in lowercase letters.
`Links to definitions are highlighted through the use of style sheets.
`
`•
`•
`•
`4. Priorities
`Each checkpoint has a priority level assigned by the Working Group based on the
`checkpoint’s impact on accessibility.
`
`[Priority 1]
`A Web content developer must satisfy this checkpoint. Otherwise, one or more
`groups will find it impossible to access information in the document. Satisfying
`this checkpoint is a basic requirement for some groups to be able to use Web
`documents.
`[Priority 2]
`A Web content developer should satisfy this checkpoint. Otherwise, one or
`more groups will find it difficult to access information in the document. Satisfying
`this checkpoint will remove significant barriers to accessing Web documents.
`[Priority 3]
`A Web content developer may address this checkpoint. Otherwise, one or more
`groups will find it somewhat difficult to access information in the document.
`Satisfying this checkpoint will improve access to Web documents.
`
`Some checkpoints specify a priority level that may change under certain
`(indicated) conditions.
`
`5. Conformance
`This section defines three levels of conformance to this document:
`
`•
`•
`•
`
`Conformance Level "A": all Priority 1 checkpoints are satisfied;
`Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;
`Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are
`satisfied;
`
` 8
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 8 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`Note. Conformance levels are spelled out in text so they may be understood when
`rendered to speech.
`Claims of conformance to this document must use one of the following two forms.
`Form 1: Specify:
`
`•
`•
`•
`•
`
`The guidelines title: "Web Content Accessibility Guidelines 1.0"
`The guidelines URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
`The conformance level satisfied: "A", "Double-A", or "Triple-A".
`The scope covered by the claim (e.g., page, site, or defined portion of a site.).
`
`Example of Form 1:
`
`This page conforms to W3C’s "Web Content Accessibility Guidelines 1.0",
`available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level
`Double-A.
`
`Form 2: Include, on each page claiming conformance, one of three icons provided
`by W3C and link the icon to the appropriate W3C explanation of the claim.
`Information about the icons and how to insert them in pages is available at
`[WCAG-ICONS] [p. 33] .
`
` 9
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 9 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`6. Web Content Accessibility Guidelines
`
`Guideline 1. Provide equivalent alternatives to auditory and
`visual content.
`
`Provide content that, when presented to the user, conveys essentially
`the same function or purpose as auditory or visual content.
`Although some people cannot use images, movies, sounds, applets, etc. directly,
`they may still use pages that include equivalent [p. 27] information to the visual or
`auditory content. The equivalent information must serve the same purpose as the
`visual or auditory content. Thus, a text equivalent for an image of an upward arrow
`that links to a table of contents could be "Go to table of contents". In some cases, an
`equivalent should also describe the appearance of visual content (e.g., for complex
`charts, billboards, or diagrams) or the sound of auditory content (e.g., for audio
`samples used in education).
`This guideline emphasizes the importance of providing text equivalents [p. 27] of
`non-text content (images, pre-recorded audio, video). The power of text equivalents
`lies in their capacity to be rendered in ways that are accessible to people from
`various disability groups using a variety of technologies. Text can be readily output
`to speech synthesizers and braille displays [p. 26] , and can be presented visually (in
`a variety of sizes) on computer displays and paper. Synthesized speech is critical for
`individuals who are blind and for many people with the reading difficulties that often
`accompany cognitive disabilities, learning disabilities, and deafness. Braille is
`essential for individuals who are both deaf and blind, as well as many individuals
`whose only sensory disability is blindness. Text displayed visually benefits users
`who are deaf as well as the majority of Web users.
`Providing non-text equivalents (e.g., pictures, videos, and pre-recorded audio) of
`text is also beneficial to some users, especially nonreaders or people who have
`difficulty reading. In movies or visual presentations, visual action such as body
`language or other visual cues may not be accompanied by enough audio information
`to convey the same information. Unless verbal descriptions of this visual information
`are provided, people who cannot see (or look at) the visual content will not be able to
`perceive it.
`
`Checkpoints:
`
`1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or
`in element content). This includes: images, graphical representations of text
`(including symbols), image map regions, animations (e.g., animated GIFs), applets
`and programmatic objects, ascii art, frames, scripts, images used as list bullets,
`spacers, graphical buttons, sounds (played with or without user interaction),
`stand-alone audio files, audio tracks of video, and video. [Priority 1]
`For example, in HTML:
`Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text
`
`•
`
`
`
`10
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 10 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`•
`
`equivalent in the content of the OBJECT and APPLET elements.
`•
`For complex content (e.g., a chart) where the "alt" text does not provide a
`complete text equivalent, provide an additional description using, for
`example, "longdesc" with IMG or FRAME, a link inside an OBJECT
`element, or a description link [p. 28] .
`For image maps, either use the "alt" attribute with AREA, or use the MAP
`element with A elements (and other text) as content.
`Refer also to checkpoint 9.1 and checkpoint 13.10.
`Techniques for checkpoint 1.1
`1.2 Provide redundant text links for each active region of a server-side image map.
`[Priority 1]
`Refer also to checkpoint 1.5 and checkpoint 9.1.
`Techniques for checkpoint 1.2
`1.3 Until user agents [p. 30] can automatically read aloud the text equivalent of a
`visual track, provide an auditory description of the important information of the visual
`track of a multimedia presentation. [Priority 1]
`Synchronize the auditory description [p. 28] with the audio track as per
`checkpoint 1.4. Refer to checkpoint 1.1 for information about textual equivalents
`for visual information.
`Techniques for checkpoint 1.3
`1.4 For any time-based multimedia presentation (e.g., a movie or animation),
`synchronize equivalent alternatives (e.g., captions or auditory descriptions of the
`visual track) with the presentation. [Priority 1]
`Techniques for checkpoint 1.4
`1.5 Until user agents [p. 30] render text equivalents for client-side image map links,
`provide redundant text links for each active region of a client-side image map.
`[Priority 3]
`Refer also to checkpoint 1.2 and checkpoint 9.1.
`Techniques for checkpoint 1.5
`
`Guideline 2. Don’t rely on color alone.
`
`Ensure that text and graphics are understandable when viewed without
`color.
`If color alone is used to convey information, people 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 deficits.
`
`
`
`11
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 11 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`Checkpoints:
`
`2.1 Ensure that all information conveyed with color is also available without color, for
`example from context or markup. [Priority 1]
`Techniques for checkpoint 2.1
`2.2 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. [Priority 2 for images, Priority 3 for text].
`Techniques for checkpoint 2.2
`
`Guideline 3. Use markup and style sheets and do so properly.
`
`Mark up documents with the proper structural elements. Control
`presentation with style sheets rather than with presentation elements
`and attributes.
`Using markup improperly -- not according to specification -- hinders accessibility.
`Misusing markup for a presentation effect (e.g., using a table for layout or a header
`to change the font size) makes it difficult for users with specialized software to
`understand the organization of the page or to navigate through it. Furthermore, using
`presentation markup rather than structural markup to convey structure (e.g.,
`constructing what looks like a table of data with an HTML PRE element) makes it
`difficult to render a page intelligibly to other devices (refer to the description of
`difference between content, structure, and presentation [p. 26] ).
`Content developers may be tempted to use (or misuse) constructs that achieve a
`desired formatting effect on older browsers. They must be aware that these practices
`cause accessibility problems and must consider whether the formatting effect is so
`critical as to warrant making the document inaccessible to some users.
`At the other extreme, content developers must not sacrifice appropriate markup
`because a certain browser or assistive technology does not process it correctly. For
`example, it is appropriate to use the TABLE element in HTML to mark up tabular
`information [p. 29] even though some older screen readers may not handle
`side-by-side text correctly (refer to checkpoint 10.3). Using TABLE correctly and
`creating tables that transform gracefully (refer to guideline 5) makes it possible for
`software to render tables other than as two-dimensional grids.
`
`Checkpoints:
`
`3.1 When an appropriate markup language exists, use markup rather than images to
`convey information. [Priority 2]
`For example, use MathML to mark up mathematical equations, and style sheets
`[p. 29] to format text and control layout. Also, avoid using images to represent
`text -- use text and style sheets instead. Refer also to guideline 6 and guideline
`11.
`Techniques for checkpoint 3.1
`
`
`
`12
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 12 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`3.2 Create documents that validate to published formal grammars. [Priority 2]
`For example, include a document type declaration at the beginning of a
`document that refers to a published DTD (e.g., the strict HTML 4.0 DTD).
`Techniques for checkpoint 3.2
`3.3 Use style sheets to control layout and presentation. [Priority 2]
`For example, use the CSS ’font’ property instead of the HTML FONT element to
`control font styles.
`Techniques for checkpoint 3.3
`3.4 Use relative rather than absolute units in markup language attribute values and
`style sheet property values. [Priority 2]
`For example, in CSS, use ’em’ or percentage lengths rather than ’pt’ or ’cm’,
`which are absolute units. If absolute units are used, validate that the rendered
`content is usable (refer to the section on validation [p. 24] ).
`Techniques for checkpoint 3.4
`3.5 Use header elements to convey document structure and use them according to
`specification. [Priority 2]
`For example, in HTML, use H2 to indicate a subsection of H1. Do not use
`headers for font effects.
`Techniques for checkpoint 3.5
`3.6 Mark up lists and list items properly. [Priority 2]
`For example, in HTML, nest OL, UL, and DL lists properly.
`Techniques for checkpoint 3.6
`3.7 Mark up quotations. Do not use quotation markup for formatting effects such as
`indentation. [Priority 2]
`For example, in HTML, use the Q and BLOCKQUOTE elements to markup short
`and longer quotations, respectively.
`Techniques for checkpoint 3.7
`
`Guideline 4. Clarify natural language usage
`
`Use markup that facilitates pronunciation or interpretation of
`abbreviated or foreign text.
`When content developers mark up natural language changes in a document, speech
`synthesizers and braille devices can automatically switch to the new language,
`making the document more accessible to multilingual users. Content developers
`should identify the predominant natural language [p. 29] of a document’s content
`(through markup or HTTP headers). Content developers should also provide
`expansions of abbreviations and acronyms.
`In addition to helping assistive technologies, natural language markup allows
`search engines to find key words and identify documents in a desired language.
`Natural language markup also improves readability of the Web for all people,
`including those with learning disabilities, cognitive disabilities, or people who are
`deaf.
`
`
`
`13
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 13 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`When abbreviations and natural language changes are not identified, they may be
`indecipherable when machine-spoken or brailled.
`
`Checkpoints:
`
`4.1 Clearly identify changes in the natural language of a document’s text and any
`text equivalents [p. 27] (e.g., captions). [Priority 1]
`For example, in HTML use the "lang" attribute. In XML, use "xml:lang".
`Techniques for checkpoint 4.1
`4.2 Specify the expansion of each abbreviation or acronym in a document where it
`first occurs. [Priority 3]
`For example, in HTML, use the "title" attribute of the ABBR and ACRONYM
`elements. Providing the expansion in the main body of the document also helps
`document usability.
`Techniques for checkpoint 4.2
`4.3 Identify the primary natural language of a document. [Priority 3]
`For example, in HTML set the "lang" attribute on the HTML element. In XML,
`use "xml:lang". Server operators should configure servers to take advantage of
`HTTP content negotiation mechanisms ([RFC2068] [p. 33] , section 14.13) so
`that clients can automatically retrieve documents of the preferred language.
`Techniques for checkpoint 4.3
`
`Guideline 5. Create tables that transform gracefully.
`
`Ensure that tables have necessary markup to be transformed by
`accessible browsers and other user agents.
`Tables should be used to mark up truly tabular information [p. 29] ("data tables").
`Content developers should avoid using them to lay out pages ("layout tables").
`Tables for any use also present special problems to users of screen readers [p. 29]
`(refer to checkpoint 10.3).
`Some user agents [p. 30] allow users to navigate among table cells and access
`header and other table cell information. Unless marked-up properly, these tables will
`not provide user agents with the appropriate information. (Refer also to guideline 3.)
`The following checkpoints will directly benefit people who access a table through
`auditory means (e.g., a screen reader or an automobile-based personal computer) or
`who view only a portion of the page at a time (e.g., users with blindness or low vision
`using speech output or a braille display, [p. 26] or other users of devices with small
`displays, etc.).
`
`Checkpoints:
`
`5.1 For data tables, identify row and column headers. [Priority 1]
`For example, in HTML, use TD to identify data cells and TH to identify headers.
`Techniques for checkpoint 5.1
`
`
`
`14
`
`ACCESSIBE LTD EXHIBIT 1011
`Page 14 of 34
`
`

`

`Web Content Accessibility Guidelines 1.0
`
`5.2 For data tables that have two or more logical levels of row or column headers,
`use markup to associate data cells and header cells. [Priority 1]
`For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL
`and COLGROUP to group columns, and the "axis", "scope", and "headers"
`attributes, to describe more complex relationships among data.
`Techniques for checkpoint 5.2
`5.3 Do not use tables for layout unless the table makes sense when linearized.
`Otherwise, if the table does not make sense, provide an alternative equivalent
`(which may be a linearized version [p. 28] ). [Priority 2]
`Note. Once user agents [p. 30] support style sheet positioning, tables should
`not be used for layout. Refer also to checkpoint 3.3.
`Techniques for checkpoint 5.3
`5.4 If a table is used for layout, do not use any structural markup for the purpose of
`visual formatting. [Priority 2]
`For example, in HTML do not use the TH element to cause the content of a
`(non-table header) cell to be displayed centered and in bold.
`Techniques for checkpoint 5.4
`5.5 Provide summaries for tables. [Priority 3]
`For example, in HTML, use the "summary" attribute of