Chapter 5: Electronic Documents

  • 501  General
  • 502  Non-Text Content
  • 503  Adaptable Presentation of Content
  • 504  Distinguishable Presentation of Text Content
  • 505  Navigation and Orientation
  • 506  Readability
  • 507  Input Assistance
  • 508  Compatible Technologies

501 General

501.1 Scope.  The provisions of this chapter shall apply where required by Chapter 1 or where referenced by a requirement in this document.

Exception:  Electronic documents complying with the WCAG 2.0 Level AA Success Criteria and Conformance Requirements shall not be required to comply with other requirements of this chapter.

Advisory 501.1 Scope.  The provisions of this chapter apply to electronic documents, which are mostly static, read-only, non-interactive electronic content.  Examples include Word files, PDFs, PowerPoint presentations, Excel spreadsheets, and simple web pages (which do not contain Flash).  However, electronic documents may also contain interactive content, such as hypertext links, buttons, and form elements or fields.  All of these elements are covered in this chapter.  Electronic content covered by this chapter includes most non-paper documents and web content, regardless of format.

This chapter is oriented towards document authors, rather than developers. 

Provisions relevant to more robust user interaction, including scripting, are found in Chapter 4 (Platforms, Applications, and Interactive Content).

Additional requirements for audio and video content are found in Chapter 6 (Synchronized Media Content and Players).

502 Non-Text Content

502.1 General.  When ICT provides non-text content, the non-text content shall conform to 502.

502.2 Text Alternatives.  When non-text content is provided, text alternatives for the non-text content shall conform to 502.2.1 or 502.2.2.

Advisory 502.2 Text Alternatives.  The intent of this provision is to provide text alternatives for any non-text content so that the non-text content can be changed into alternate formats that people with disabilities can use.  Some text alternatives shall identify the purpose of the non-text content, as in 502.2.1.  Some text alternatives shall describe the non-text content, as in 502.2.2.

502.2.1 Equivalent Purpose.  When non-text content is provided, text alternatives for the non-text content shall serve the equivalent purpose.

Advisory 502.2.1  Equivalent Purpose.  Examples of text alternatives that serve the equivalent purpose include:

  • A search button uses an image of a magnifying glass.  An appropriate text alternative for the button is “search” and not “magnifying glass”.
  • A picture shows how a knot is tied including arrows showing how the ropes go to make the knot.  An appropriate text alternative for the picture describes how to tie the knot, not “picture of ropes being tied into a knot.”
  • An animation shows how to change an ink cartridge.  A short text alternative for the animation identifies what the animation is about.  A long text alternative for the animation describes how to change an ink cartridge.
  • A logo of the TechTron Company appears next to each of their products in a list.  A short text alternative for this logo is “TechTron”.
  • A chart shows sales for October of Acme Co.  A short text alternative for the chart is “Acme Co. October sales chart”.  A long text alternative for the chart provides all of the information on the chart.
  • A heading contains an image of the words, “The History of War” in elaborately stylized text.  The alternative text for the image is “The History of War”.
  • An image of a series of books on a shelf contains interactive areas that provide links to a web page about each book.  The text alternative for the image is “Books available in this section.  Select a book for more details about that book.”

502.2.1.1 Images of Text.  When non-text content is images of text, the text alternative shall be the text in the image.

Advisory 502.2.1.1 Images of Text.  A best practice is to use text instead of images of text.

502.2.1.2 Controls or Inputs.  When non-text content is a control or accepts user input, the non-text content shall have a name that describes its purpose.

Advisory 502.2.1.2 Controls or Inputs.  A “name” is programmatically determinable text by which software can identify a component within content to the user.  While the name might not be visually presented to users, it must be programmatically determinable by assistive technology.

502.2.1.3 Decoration, Formatting, or Invisible.  When non-text content is pure decoration, is used only for visual formatting, or is not presented to users, the non-text content shall be implemented in a way that can be ignored by assistive technology.

Advisory 502.2.1.3 Decoration, Formatting, or Invisible.  An example of a text alternative that is implemented in a way that can be ignored by assistive technology is using alt="" on an HTML image that does not convey information.

502.2.2 Descriptive Identification.  When non-text content is provided, text alternatives for the non-text content shall conform to 502.2.2.1 through 502.2.2.4, as applicable to the type of non-text content.

502.2.2.1 Audio or Video.  When non-text content is audio or video content, text alternatives shall provide descriptive identification of the non-text content.

502.2.2.2 Test or Exercise.  When non-text content is a test or exercise that would be invalidated if presented in text, text alternatives shall provide descriptive identification of the non-text content.

Advisory 502.2.2.2 Test or Exercise.  An example of a test or exercise that would be invalidated if presented in text is an audio-only spelling quiz.  For this example, the text alternative might be “audio-only spelling quiz”.

502.2.2.3 Sensory Experience.  When non-text content is primarily intended to create a specific sensory experience, text alternatives shall provide descriptive identification of the non-text content.

Advisory 502.2.2.3 Sensory Experience.  An example of non-text content that is primarily intended to create a specific sensory experience is an audio-only recording of an orchestra.  For this example, the text alternative might be “recording of city orchestra”.

Another example is an unattended and automatically updating weather satellite photo.  For this example, the text alternative might be “photo from weather satellite updated every hour”.

A third example is video from an unattended camera at an airport.  For this example, the text alternative might include the current temperature and wind speed.

A best practice is for the descriptive identification to provide as much textual information as possible.

502.2.2.4 CAPTCHA.  When the purpose of non-text content is to confirm that the content is being accessed by a person rather than a computer, text alternatives that identify and describe the purpose of the non-text content shall be provided.

502.3 Audio and Video Content.  Audio and video content shall conform to Chapter 6 (Synchronized Media Content and Players).

503 Adaptable Presentation of Content

503.1 General.  Content shall conform to 503.

Advisory 503.1 General.  A best practice is to create content that can be presented in different ways without losing information or structure.  An example is providing end-users the option to choose a high contrast presentation for a web site.

503.2 Information, Structure, and Relationships.  Information, structure, and relationships presented visually to the user shall be programmatically determinable or be available in text.

Advisory 503.2 Information, Structure and Relationships.  The intent of this provision is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.  An example is the presentation format changing when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

The sub provisions under 503.2 are not an exhaustive list of information, structure, and relationships that might be presented to an end-user.

503.2.1 Data Tables.  When data tables are provided, data tables shall conform to 503.2.1.1 and 503.2.1.2.

503.2.1.1 Data Tables.  Row and column headings shall be programmatically determinable.

503.2.1.2 Multi-Level Tables.  When data tables have two or more logical levels of row or columns headings, associations between data cells and heading cells shall be programmatically determinable.

503.2.2 Forms.  When forms are provided, labels associated with form fields shall be programmatically determinable.

503.2.3 Section Headings.  When content is divided into sections, section headings shall be programmatically determinable.

503.3 Logically Correct Reading Sequence.  When the sequence in which content is presented affects its meaning, a logically correct reading sequence shall be programmatically determinable.

Advisory 503.3 Logically Correct Reading Sequence.  A logically correct reading sequence is a sequence where words and paragraphs are presented in an order that does not change the meaning of the content.

There may be more than one choice for a logical reading sequence of some content.  An example is a sidebar item that might reasonably be read before, after, or in the middle of the main body content.  Content authors and developers have flexibility in deciding a logically correct reading sequence.

An example of a reading sequence that is not logically correct is where content is divided into two or more newspaper-style columns, but the programmatically determined reading sequence reads across columns rather than down each column. 

Another example is using a style sheet to visually position blocks of text on a page.  If the reading sequence used by assistive technology follows a reading sequence implied visually, then the reading sequence is logically correct.  If the programmatically determined reading sequence seems random and does not follow any reading sequence implied visually, then the reading sequence is not logically correct.

503.4 Sensory Characteristics.  Instructions provided for understanding and operating content shall not rely solely on those characteristics of components perceived through the senses of hearing or vision, such as shape, size, visual location, orientation, or sound.

Advisory 503.4 Sensory Characteristics.  Rather than stating, “Click the oval button to the right when done”, an instruction should tell the user to “Activate the Submit button when done.”

Object information (provided per 503) which describes the necessary visual cues or relationships, may be used in providing instructions that conform to this provision.

504 Distinguishable Presentation of Text Content

504.1 General.  Text content or images of text content shall conform to 504.

Advisory 504.1 General.  A best practice is to make it easier for users to see content, including separating visual foreground from background.

504.2 Text and Images of Text Contrast Ratio.  The visual presentation of text and images of text shall conform to 504.2.1 or 504.2.2.

Exception:  When visual presentations of text or images of text are part of an inactive user interface component, are pure decoration, are not presented to users, are part of a picture that contains significant other visual content, or are part of a logo or brand name, there is no contrast requirement.

Advisory 504.2 Text and Images of Text Contrast Ratio Exception.  An example of an “inactive user interface component” is an item within a menu that automatically “grays out” when its selection is not available.  In this example, the deemphasized item remains in the menu as a placeholder.

An example of images of text in “part of a picture that contains significant other visual content” is the lettering on a shop window in a photograph of a street scene when the lettering on the window is not relevant to the purpose of the photograph.

504.2.1 Large-Scale Text Contrast Ratio.  Large-scale text and images of large-scale text shall have a contrast ratio of at least 3:1.

504.2.2 Text Contrast Ratios.  Text and images of text that are not large scale text shall have a contrast ratio of at least 4.5:1.

Advisory 504.2.2 Text Contrast Ratios.  For further clarification of this requirement, consult WCAG 2.0 Success Criteria 1.4.3 “Contrast (Minimum)”.

See also the WCAG 2.0 definitions for “contrast ratio” found at:
http://www.w3.org/TR/WCAG20/#contrast-ratiodef.

504.3 Resize and Reflow Text.  Text content shall support the native capability of the platform for text to resize and reflow text without loss of content or functionality.

Exception:  Captions and images of text are not required to conform to 504.3.

504.3 Resize and Reflow Text.  Most content formats and platforms natively provide a capability for users to adjust font size.  Content can be developed which interferes with this native capability and thus creates a barrier to accessibility for users with low vision.

Reflow of text is necessary because just making letters larger would result in text moving off the screen or text appearing on top of other text.

A best practice is for captions and images of text to support the resizing and reflow of text.

Another best practice is to use text, rather than images of text, wherever possible, because text gives users more control over font size.

Web documents that support resize and reflow of text are sometimes described as “fluid”, “liquid”, or “elastic”.

505 Navigation and Orientation

505.1 General.  Content shall conform to 505.

Advisory 505.1 General.  A best practice is for authors to provide ways to help users navigate, find content, and determine where they are.

505.2 Document Titles.  Documents shall have titles that describe topic or purpose.

505.3 Link Purpose.  The purpose of each link shall be determinable from the link text alone, or from the link text together with its programmatically determined link context.

Exception:  When the purpose of a link is ambiguous to users in general, the purpose of that link shall not be required to conform to 505.3.

Advisory 505.3 Link Purpose.  The intent of this provision is to help users understand the purpose of each link so that they can decide whether they want to follow the link.

A best practice is to provide link text that identifies the purpose of the link without needing additional context.

Assistive technology has the ability to provide users with a list of links that are on the Web page.  Link text that is as meaningful as possible will aid users who want to choose from this list of links.  Meaningful link text also helps those who wish to tab from link to link.  Meaningful link text helps users choose which links to follow without requiring complicated strategies to understand the page.

In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link.  An example of this is when only one word in a sentence is a link, and the purpose of this link is made apparent from the context provided by the entire sentence.

When the link text alone is not sufficiently descriptive, this provision requires that a user be able to identify the purpose of a link without moving focus from the link.

Users should be able to arrive on a link and find out more about where the link leads without losing their place in content.  Examples of programmatically determined link context include:  putting the description of the link in the same sentence, paragraph, list item, a heading immediately preceding the link, and table headings cell for a link in a data table.

An example of link text being used together with its programmatically determined link context is a list of books available in three formats:  HTML, PDF, and MP3.  In this example, so that screen reader users do not have to hear the title of each book three times (once for each format), the first link for each book is the title of the book, the second link says “PDF”, and the third says “MP3”.

Text that is in title or alt attributes is programmatically determinable and may also be used for compliance with this provision.  An example of this technique is a news article summary where the main page lists the first few sentences of each article followed by a “Read More” link.  In this example, each “Read More” link includes a title attribute with a value that is unique to each article.

505.3 Link Purpose Exception.  An example where links are ambiguous to all users in general is an online quiz that has possible answers identified only with an arbitrary number.  In this example, descriptive link text might influence choices, and invalidate the purpose of the quiz.

505.4 Descriptive Headings and Labels.  When supported by the technology and appropriate to the task, headings and labels shall describe topic or purpose.

Advisory 505.4 Headings and Labels.  An example of this provision would be descriptive section headings in a document. 

An example of a technology that does not allow the document author to create headings or labels which describe topic or purpose is a spreadsheet; therefore, this provision would not apply to spreadsheets. 

An example of a situation where headings and labels are not appropriate to the task is a data table.  Short non-descriptive identifying labels are appropriate for this task.  Headings for data tables are required by 503.2.1.

506 Readability

506.1 General.  Text content shall conform to 506.

506.2 Language of Document.  The default human language of each document shall be programmatically determinable.

506.3 Language of Passage or Phrase.  When supported by the technology, the human language of each passage or phrase in the content shall be programmatically determinable.

Exception:  The human language for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text, shall not be required to be programmatically determinable.

Advisory 506.3 Language of Passage or Phrase.  An example of technology that does not support the human language of a passage or a phrase being programmatic determinable is plain ASCII text.

507 Input Assistance

507.1 General.  Content shall conform to 507.

Advisory 507.1 General.  A best practice is for authors to help users avoid and correct mistakes.  For example, instructions for filing out a form should help the reader to complete the form.

507.2 Labels or Instructions.  When content requires user input, labels or instructions shall be provided.

Advisory 507.2 Labels or Instructions.  The intent of this provision is to ensure that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Labels do not need to be lengthy.  A word, or even a single character, may be sufficient if it provides an appropriate cue to finding and navigating content.

An example of a sufficient label for a telephone number data entry field is the use of a hyphen, and not just white space, to separate parts of the phone number.

An example of an insufficient label for a telephone number data entry field is the use of formatting implied only visually by shape, size, or location of the parts of the phone number.

508 Compatible Technologies

508.1 General.  Content shall conform to 508.

508.2 Markup Language Used According to Specification.  Content that is implemented using markup languages shall conform to 508.2.1 through 508.2.4.

Advisory 508.2 Markup Language Used According to Specification.  HTML (hyper text markup language) and XML (extensible markup language) are examples of markup languages which are used in the creation of electronic content.

The intent of this requirement is to ensure that user agents, including assistive technologies, can accurately interpret and parse content using markup language.  Content that is properly coded using all of the above requirements is correctly read by user agents, such as screen readers.

In markup languages, errors in element and attribute syntax and failure to provide properly nested start and end tags lead to errors that prevent user agents from parsing the content reliably.  This provision requires that the content can be parsed using only the rules of the formal grammar for the technology.

Many authoring tools ensure unambiguous parsing.  When available for the content format, validation ensures unambiguous parsing.  A best practice is to use authoring tools that provide validation or otherwise ensure unambiguous parsing.  See section 413 for more guidance on the use of authoring tools.

Content which is poorly coded and omits any one of the requirements in the provision may be unreadable by a user agent.  For example, a table is coded, but the nested (508.2.2) start and end tags (508.2.1) are omitted.  As a result, the screen reader tool reports “not in a table” when the user tries to invoke table navigation commands to move from one data cell to another.  The screen reader is unable to properly read the poorly coded document, since some of the requirements, such as properly nested start and end tags in this case, were omitted. 

Some user agents use “repair techniques” to render poorly coded content but the resulting rendering can be unpredictable, and documents that rely on such repair techniques are not conformant to this provision.  If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. 

Repair techniques vary among user agents.  A best practice is for content to be created according to the rules defined in the formal grammar for that technology.  When this best practice is not followed, authors cannot assume that content will be accurately parsed into a data structure.  Authors also cannot assume that content will be rendered correctly by specialized user agents, including assistive technologies.  Markup language must be used according to specification.

508.2.1 Tags.  Elements shall have complete start and end tags.

508.2.2 Nesting.  Elements shall be nested according to their specifications.

508.2.3 No Duplicate Attributes.  Elements shall not contain duplicate attributes.

508.2.4 Identity.  When identity attributes are used, identity values shall be unique unless the specifications allows for duplication.

508.3 User Interface Components.  User interface components shall be used according to their specification and shall conform to 411.2.

Advisory 508.3 User Interface Components.  The intent of this provision is to ensure that document authors do not disrupt accessibility features.  This provision is applicable but not limited to form elements, links, and components generated by scripts.

Examples of user interface components in documents include hypertext links, buttons, and form elements or fields.

Standard HTML controls and form elements conform to this requirement when used according to specification.

Chapter 4 (Platforms, Applications, and Interactive Content) contains requirements for user interface components.