Assessment Framework

Version: Dec. 2010

Important Note

This is a technical document intended for use in performing product assessments. More user-friendly guidance is provided by the various support documents provided on the Accessible Digital Office Document (ADOD) Project website:  http://adod.idrc.ocad.ca/.

Abstract

The Accessible Digital Office Documents (ADOD) Assessment Framework is a mechanism, based primarily on the WCAG 2.0 and ATAG 1.0 Recommendations of the W3C, for assessing various aspects of office documents and office applications related to accessibility.

Contents

Important Note
Abstract
Scope
Relationship between ADOD and WCAG 2.0/ATAG 1.0
Conformance
ADOD Assessment Framework
Part 1: [ADOD-Office-Documents] Assessing the accessibility of office documents
Part 2: [ADOD-Office-Formats] Assessing the accessibility of office document formats
Part 3: [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces
Part 4: [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents
Glossary of ADOD-Specific Terms
References
W3C Recommendations:
Other Resources Consulted:
Appendices
Appendix A: Rationale for inclusion of success criteria in “Part 1: [ADOD-Office-Documents] Assessing the accessibility of office documents”
Appendix B: Rationale for inclusion of success criteria in “Part 2: [ADOD-Office-Formats] Assessing the accessibility of office documents formats”
Appendix C: Rationale for inclusion of success criteria in “Part 3: [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces”
Appendix D: Rationale for inclusion of success criteria in “Part 4: [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents”
Appendix E: Comparison between ADOD and Section 508 Regulations (2001)
Accessibility of Office Documents (Part 1 [ADOD-Office-Documents] Assessing the accessibility of office documents)
Accessibility of Office Document Formats (Part 2 [ADOD-Office-Formats] Assessing the accessibility of office document formats)
Accessibility of Office Application User Interfaces (Part 3 [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces)
Support for Authoring Accessible Office Documents (Part 4 [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents)
Acknowledgments

Scope

The ADOD Assessment Framework applies specifically to office documents, which are defined as computer documents that are:

  • Intended to be used by people (i.e., not computer code),
  • Text-based (i.e., not simply images, although they may contain images),
  • Fully printable (i.e., where dynamic features are limited to automatic page numbering, table of contents, etc. and do not include audio, video, or embedded interactivity),
  • Self-contained (i.e., without hyperlinks to other resources unlike web content), and
  • Typical of office-style workflows (Reports, letters, memos, budgets, presentations, etc.).

The ADOD Assessment Framework does not simply apply to any document produced by an office application using an office document format. This is an important distinction because office document formats and office applications have been extended over the years to allow the creation of content with many of the same dynamic and interactive features as web content technologies offer (e.g., hyperlinking to other resources, multimedia support, and programmability). When office document formats are used to create dynamic and/or interactive content (whether or not for the Web), WCAG 2.0 rather than the ADOD Assessment Framework should be consulted to assess accessibility.
Since full inclusion includes allowing everyone to be both consumers and producers of content, the ADOD Assessment Framework addresses the question of office document accessibility from several perspectives:

Accessibility of office documents

  • Part 1 ([ADOD-Office-Documents] Assessing the accessibility of office documents) addresses the accessibility of complete office documents, ready for sharing with other users. This section is based on WCAG 2.0.

Accessibility of Office Document Formats

  • Part 2 ([ADOD-Office-Formats] Assessing the accessibility of office document formats) addresses the accessibility of the underlying office document formats, regardless of how they are presented to users in the various office applications. This section is based on a subset of [ADOD-Office-Documents], above.

Accessibility of Office Application User Interfaces

  • Part 3 ([ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces) addresses the accessibility to users with disabilities of the user interfaces provided by office applications. This section is based on ATAG 1.0 Guideline 7 (“Ensure that the authoring tool is accessible to authors with disabilities.”)

Support for Authoring Accessible Office Documents

  • Part 4 ([ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents) addresses the features that office applications provide to all users to support and encourage production of accessible office documents. This section is based on ATAG 1.0 Guidelines 1-6.

Note re: Presentations: Of the three types of office documents, presentations are the most likely to make use of dynamic or interactive content (e.g., audio, video, multimedia, animations, hyperlinks to other resources, etc.). When this is the case, WCAG 2.0 should be used to assess accessibility, rather than ADOD’s Assessment Framework.

Note re: Document editing is not considered “dynamic/interactive” content: One of the typical features of office documents is that they are often editable and during editing, a certain amount of interactivity and dynamism may occur (e.g., the document updates to reflect the user’s last entry, when the use updates a spreadsheet cell other cells may also update). However, the ADOD Assessment Framework does not consider changes caused by editing an office document to constitute interactive/dynamic content.

Relationship between ADOD and WCAG 2.0/ATAG 1.0

The W3C-WAI Web Content Accessibility Guidelines (WCAG 2.0) and W3C-WAI Authoring Tool Accessibility Guidelines (ATAG 1.0*) provide open, comprehensive and respected guidance on how to develop accessible web content and accessible web content authoring tools. The ADOD Assessment Framework is an attempt to usefully apply these guidelines to the context of office documents/application with as little “adjustment” as possible.

The adjustments are necessary because simply applying WCAG 2.0 and ATAG 1.0 to the context of office documents/applications has several drawbacks:

  • Vocabulary confusion: ATAG 1.0 and WCAG 2.0 both make frequent use of terms such as “web content” and “authoring tool” that need to be re-mapped to be applicable to office documents and office applications. Creating adjusted sets of success criteria for the ADOD Assessment Framework allowed the office document-specific terms to be inserted
  • Numerous non-applicable success criteria: Because ADOD focuses specifically on office documents without dynamic or interactive content, many WCAG 2.0 success criteria are not applicable. Creating an adjusted set of office document accessibility success criteria for the ADOD Assessment Framework allowed the non-applicable success criteria to be dropped.
  • Multiple conformance levels: In formulating an easy-to-use assessment framework for office documents it was judged that the multiple conformance levels were an unnecessary complication. Creating adjusted sets of success criteria for the ADOD Assessment Framework at WCAG 2.0 Level AA meant that the level identifiers could be removed.
  • ATAG 1.0 references WCAG 1.0: ATAG 1.0 references WCAG 1.0, rather than the current W#C Recommendation, WCAG 2.0. Creating adjusted sets of success criteria for the ADOD Assessment Framework meant that the references could be changed to WCAG 2.0.
  • ATAG 1.0 is prioritized differently that WCAG 2.0: In WCAG 2.0, “success criteria” are assigned a “Level” between Level A and Level AA. In ATAG 1.0, “checkpoints” are assigned a “Priority” between priority 1 and priority 3. “Relative Priority” items take their priority level from the WCAG content in question. Creating adjusted sets of success criteria for the ADOD Assessment Framework meant that common wording could be employed.

At the same time, in order to reduce the risk of “fragmenting” the guidance provided to office application developers, who have only a limited budget for maintaining and improving of accessibility features, the ADOD Assessment Framework:

  • Uses the W3C-WAI numbering schemes and
  • Uses the original W3C-WAI wording except where vocabulary adjustments are indentified with square brackets.

* At the time of writing, ATAG 1.0 is the current Recommendation of W3C; ATAG 2.0 is under development.

Conformance

Since the ADOD Assessment Framework is essentially a “view” of WCAG 2.0 and ATAG 1.0 that is specific to office documents and office applications, an ADOD-specific conformance model is unnecessary. Instead, official conformance claims should be made to WCAG 2.0 (for office documents) and ATAG 1.0 (for office applications), noting that any Web-specific wording has been interpreted for an office document/application context.

If the document or application meets the criteria for being an office document or office application under the ADOD definition (i.e., used by people, text-based, fully printable, self-contained, and is typical of office-style workflows) then “Not Applicable” can be entered for all of the WCAG 2.0/ATAG 1.0 success criteria that are left out of the ADOD Assessment Framework.

ADOD Assessment Framework

Part 1: [ADOD-Office-Documents] Assessing the accessibility of office documents

These success criteria relate to assessing the accessibility of office documents to users with disabilities. They are based largely on WCAG 2.0 up to Level AA (see “Relationship between ADOD and WCAG 2.0/ATAG 1.0” for more information).

  • Note: This part of the framework does not cover office documents that contain dynamic or interactive content (e.g., audio, video, multimedia, animations, hyperlinks to other resources, forms, etc.). In these cases, refer instead to WCAG 2.0.
  • See Appendix A for:
    • The original WCAG 2.0 success criteria wording (certain Web-specific terms and references have been adjusted to apply to office documents and applications). In [ADOD-Office-Documents] the adjusted terms or references are marked with “[ ]”.
    • The rationale for inclusion or exclusion of success criteria.
  • For clarity, the WCAG 2.0 numbering scheme has been maintained with the added prefix “[ADOD-Office-Documents]”.

[ADOD-Office-Documents 1.1.1] Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

[ADOD-Office-Documents 1.3.1] Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

[ADOD-Office-Documents 1.3.2] Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

[ADOD-Office-Documents 1.3.3] Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. Note: For requirements related to color, refer to Guideline 1.4.

[ADOD-Office-Documents 1.4.1] Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

[ADOD-Office-Documents 1.4.3] Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: 

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

[ADOD-Office-Documents 1.4.5] Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: Note: Logotypes (text that is part of a logo or brand name) are considered essential.

  • Customizable: The image of text can be visually customized to the user's requirements;
  • Essential: A particular presentation of text is essential to the information being conveyed.

[ADOD-Office-Documents 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content [in office documents].

[ADOD-Office-Documents 2.4.2] Page Titled: [Office documents] have titles that describe topic or purpose.

[ADOD-Office-Documents 2.4.3] Focus Order: If [an office document] can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

[ADOD-Office-Documents 2.4.4] Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

[ADOD-Office-Documents 2.4.6] Headings and Labels: Headings and labels describe topic or purpose.

[ADOD-Office-Documents 3.1.1] Language of Page: The default human language of each [office document] can be programmatically determined.

[ADOD-Office-Documents 3.1.2] Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except 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.

[ADOD-Office-Documents 3.2.4] Consistent Identification: Components that have the same functionality within a set of [office documents] are identified consistently.

Part 2: [ADOD-Office-Formats] Assessing the accessibility of office document formats

These success criteria relate to assessing the intrinsic accessibility supports provided by office document formats (not the accessibility of actual office documents created by authors - for this, see Part 1, above).
Essentially, each [ADOD-Office-Formats] success criterion refers to the office formats ability to support any functionality pre-supposed by the [ADOD-Office-Documents] success criterion of the same number. For example, “[ADOD-Office-Formats 1.1.1] The office format provides mechanism(s) for short and long text alternatives for non-text content and the ability to indicate that non-text content should be ignored by assistive technology.” tests the ability of the format to be used to create office documents that meet “[ADOD-Office-Documents 1.1.1] Non-text Content: All non-text content that is presented to the user has a text alternative…”
Note: This part of the framework does not cover the use of office formats to create office documents that contain dynamic or interactive content (e.g., audio, video, multimedia, animations, hyperlinks to other resources, forms, etc.).

  • See Appendix B for:
    • The rationale for inclusion or exclusion of success criteria.
  • For clarity, the WCAG 2.0 numbering scheme has been maintained with the added prefix “[ADOD-Office-Formats]”.

[ADOD-Office-Formats 1.1.1] The office format provides mechanism(s) for short and long text alternatives for non-text content and the ability to indicate that non-text content should be ignored by assistive technology.

[ADOD-Office-Formats 1.3.1] The office format provides mechanism(s) for providing information, structure, and relationships programmatically.

[ADOD-Office-Formats 1.3.2] The office format provides mechanism(s) for encoding reading sequences.

[ADOD-Office-Formats 2.4.1] The office format provides mechanism(s) for bypassing blocks of content.

[ADOD-Office-Formats 2.4.2] The office format provides mechanism(s) for document title.

[ADOD-Office-Formats 2.4.3] The office format provides mechanism(s) for specifying navigation sequences.

[ADOD-Office-Formats 2.4.4] If the office format supports hyperlinking, it provides mechanism(s) for specifying the purpose of links (e.g., the link text).

[ADOD-Office-Formats 2.4.6] The office format provides mechanism(s) for headings and labels.

[ADOD-Office-Formats 3.1.1] The office format provides mechanism(s) for setting the default human language of office documents.

[ADOD-Office-Formats 3.1.2] The office format provides mechanism(s) for setting the default human language of parts of office documents.

Part 3: [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces

These success criteria relate to assessing the accessibility of office applications to users with disabilities. They are based largely on ATAG 1.0 Guideline 7 up to Priority 2 (see “Relationship between ADOD and WCAG 2.0/ATAG 1.0” for more information).

  • See Appendix C for:
    • The original ATAG 1.0 Guideline 7 wording (certain Web-specific terms and references have been adjusted to apply to office documents and applications). In [ADOD-Office-Applications-UI] the adjusted terms or references are marked with “[ ]”.
    • The rationale for inclusion or exclusion of success criteria.
  • For clarity, the ATAG 1.0 numbering scheme has been maintained with the added prefix “[ADOD-Office-Applications-UI]”.

[ADOD-Office-Applications-UI 7.1] Use all applicable operating system and accessibility standards and conventions that are important or essential to accessibility. The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications.
ADOD Note: The Checkpoint is very general, and includes: Supporting relevant accessibility API(s); Web-based tools conforming to WCAG; Keyboard access; Providing keyboard shortcuts where recommended for a platform; Respecting platform settings (such as “high contrast” modes); and Providing documentation.

[ADOD-Office-Applications-UI 7.2] Allow the author to change the presentation within editing views without affecting the [office document]. This allows the author to edit the document according to personal requirements, without changing the way the document is rendered when published.

[ADOD-Office-Applications-UI 7.3] Allow the author to edit all properties of each element and object in an accessible fashion.

[ADOD-Office-Applications-UI 7.4] Ensure that the editing view allows navigation via the structure of the document in an accessible fashion.

[ADOD-Office-Applications-UI 7.5] Enable editing of the structure of the document in an accessible fashion.

[ADOD-Office-Applications-UI 7.6] Allow the author to search within editing views.

Part 4: [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents

These guidelines relate to determining the degree to which office applications support all users in the production of office documents that are accessible to users with disabilities. They are based largely on ATAG 1.0 Guidelines 1-6 up to Priority 2 (see “Relationship between ADOD and WCAG 2.0/ATAG 1.0” for more information).

  • See Appendix D for:
    • The original ATAG 2.0 Part B success criteria wording (certain Web-specific terms and references have been adjusted to apply to office documents and applications). In [ADOD-Office-Applications-Supports] the adjusted terms or references are marked with “[ ]”.
    • The rationale for inclusion or exclusion of success criteria.
  • For clarity, the ATAG 2.0 numbering scheme has been maintained with the added prefix “[ADOD-Office-Applications-Supports]”.

[ADOD-Office-Applications-Supports 1.1] Ensure that the author can produce accessible [office document] content in the [office formats] supported by the [office application].

[ADOD-Office-Applications-Supports 1.2] Ensure that the [office application] preserves all accessibility information during authoring, transformations, and conversions.

[ADOD-Office-Applications-Supports 1.3] Ensure that when the [office application] automatically generates [content] it conforms to [ADOD-Office-Documents].

[ADOD-Office-Applications-Supports 1.4] Ensure that templates provided by the [office application] conform to the [ADOD-Office-Documents].[ADOD-Office-Applications-Supports 2.2] Ensure that the [office application] automatically generates valid [office documents].

[ADOD-Office-Applications-Supports 3.1] Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video).
Note: Some checkpoints in the [ADOD-Office-Documents] may not apply.

[ADOD-Office-Applications-Supports 3.2] Help the author create structured content and separate information from its presentation.
Note: Some checkpoints in [ADOD-Office-Documents] may not apply.

[ADOD-Office-Applications-Supports 3.3] Ensure that prepackaged [office document] content conforms to the [ADOD-Office-Documents].
For example, include captions, an auditory description, and a collated text transcript with prepackaged movies.

[ADOD-Office-Applications-Supports 3.4] Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty.
For example, prompt the author for a text equivalent of an image. If the author has already provided a text equivalent for the same image used in another document, offer to reuse that text and prompt the author for confirmation.

[ADOD-Office-Applications-Supports 4.1] Check for and inform the author of accessibility problems.
Note: Accessibility problems should be detected automatically where possible. Where this is not possible, the [office application] may need to prompt the author to make decisions or to manually check for certain types of problems.

[ADOD-Office-Applications-Supports 4.2] Assist authors in correcting accessibility problems.
At a minimum, provide context-sensitive help with the accessibility checking required by checkpoint 4.1

[ADOD-Office-Applications-Supports 5.1] Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the [office application].

[ADOD-Office-Applications-Supports 5.2] Ensure that accessible authoring practices supporting [ADOD-Office-Documents] checkpoints are among the most obvious and easily initiated by the author.

[ADOD-Office-Applications-Supports A] Document all features that promote the production of accessible [office documents].

[ADOD-Office-Applications-Supports B] Ensure that creating accessible [office documents] is a naturally integrated part of the documentation, including examples.

Glossary of ADOD-Specific Terms

Terms specific to WCAG 2.0 and ATAG 1.0 are defined in those Recommendations.

office documents (digital office documents)
Computer files encoded in office document formats that are:
  • Intended to be used by people (i.e., are not computer code),
  • Text-based (i.e., are not simply images, although they may contain images),
  • Fully printable (i.e., dynamic features are limited to automatic page numbering, table of contents, etc. not audio, video, and embedded interactivity),
  • Self-contained (i.e., without links to other resources as is common with web content), and
  • Typical of office-style workflows (Reports, letters, memos, budgets, presentations, etc.).

Note: This purposefully excludes most documents making use of dynamic and interactive content (audio, video, hyperlinks to other resources, forms, programmability, etc.), since the accessibility of these are better assessed using WCAG 2.0. ADOD does, however, cover some dynamic content (animations, audio and video) in the context of presentations.

office document formats (digital office document formats)
Computer file formats that are produced and viewed primarily by office applications, such as word processor formats (e.g., Microsoft Word (*.doc, *.docx), OpenDocument Text (*.odt)), spreadsheet formats (Microsoft Excel (*.xls, *.xlsx) and OpenDocument Spreadsheet (*.ods)), and presentation formats (e.g., Microsoft Powerpoint (*.ppt, *.pptx) and OpenDocument Presentation (*.odp)).
office applications (digital office applications)
Computer programs that are used to create office documents. Office applications are available for desktop platforms, mobile devices, web-based etc.
office application suite
A set of office applications that are distributed together. The applications that make up a suite often share relatively consistent user interfaces and the ability for enhanced interaction between them (e.g., the ability to paste a spreadsheet directly into a word processing document). ADOD covers the typical core members of most office suites: word processors, spreadsheet applications, and presentation applications. In addition, some suites include note-takers, flow-chart editors, image editors, formula editors, etc.

References

W3C Recommendations:

Other Resources Consulted:

Appendices

Appendix A: Rationale for inclusion of success criteria in “Part 1: [ADOD-Office-Documents] Assessing the accessibility of office documents”

These success criteria relate to assessing the accessibility of office documents to users with disabilities.
 WCAG 2.0 (Level A and Level AA Success Criteria) has been used as a basis for [ADOD-Office-Documents] (see “Relationship between ADOD and WCAG 2.0/ATAG 2.0”), with the following exceptions:

  • Some terminology and references need to be interpreted differently:
    • * Web-specific terms. These should be interpreted in the context of office documents and office applications (see “Relationship between ADOD and WCAG 2.0/ATAG 2.0”)
      •  “web page(s)” is to be interpreted as “office document(s)”
      •  “(web) content” is to be interpreted as “(office document) content”
      •  “web content technology” is to be interpreted as “office document format”
  • Some success criteria are not applicable. The reasons for this include:
    • (interactive/dynamic): The success criterion refers to a level of interactivity or dynamism (e.g., “live audio”) exceeding that typically found in word processor, spreadsheet or presentation documents.
    • (application responsibility): The success criterion is typically handled by the viewing functionality of office applications (e.g., focus indicator, parsing, etc.)
  • Some Level A success criteria are superseded by other level AA success criteria.
    • [WCAG 2.0 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages*. (Level A) is adjusted somewhat more than the other requirements. Instead of simply switching the vocabulary, the requirement is changed to refer to bypassing blocks of content within a document, not just when the block appear on multiple documents (i.e., “[ADOD-Office-Documents 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content [in office documents].”) The reason for this is that office documents are typically more self-contained than Web documents and provide more built-in navigation mechanisms (e.g., table of contents, page numbering).
WCAG 2.0 Success Criteria (Level A and AA) ADOD Applicability and/or Modifications
[WCAG 2.0 1.1.1] Non-text Content: All non-text content* that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
  • Test: If non-text content* is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content*.
  • Sensory: If non-text content* is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content*.
  • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content* is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
The following exceptions are not applicable (interactive/dynamic):
  • Controls, Input
  • Time-Based Media
  • CAPTCHA
[WCAG 2.0 1.2.1] Audio-only and Video-only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)
  • Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content*.
  • Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content*.
Not applicable (interactive/dynamic)
[WCAG 2.0 1.2.2] Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A) Not applicable (interactive/dynamic)
[WCAG 2.0 1.2.3] Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content* is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A) Superseded by [WCAG 2.0 1.2.5]
[WCAG 2.0 1.2.4] Captions (Live): Captions are provided for all live audio content in synchronized media. (Level AA) Not applicable (interactive/dynamic)
[WCAG 2.0 1.2.5] Audio Description (Prerecorded): Audio description is provided for all prerecorded video content in synchronized media. (Level AA) Not applicable (interactive/dynamic)
[WCAG 2.0 1.3.1] Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) For ADOD this includes using the default “named styles” since these facilitate content transformations (e.g., to HTML) and automated table of contents generation.
[WCAG 2.0 1.3.2] Meaningful Sequence: When the sequence in which content* is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)  
[WCAG 2.0 1.3.3] Sensory Characteristics: Instructions provided for understanding and operating content* do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A) Note: For requirements related to color, refer to Guideline 1.4.  
[WCAG 2.0 1.4.1] Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A) Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.  
[WCAG 2.0 1.4.2] Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A) Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Not applicable (interactive/dynamic)
[WCAG 2.0 1.4.3] Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content*, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
 
[WCAG 2.0 1.4.4] Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) Not applicable (application responsibility). Office applications typically include magnification options.
[WCAG 2.0 1.4.5] Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA) Note: Logotypes (text that is part of a logo or brand name) are considered essential.
  • Customizable: The image of text can be visually customized to the user's requirements;
  • Essential: A particular presentation of text is essential to the information being conveyed.
 
[WCAG 2.0 2.1.1] Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A) Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. Not applicable (interactive/dynamic)
[WCAG 2.0 2.1.2] No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)  Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Not applicable (interactive/dynamic)
[WCAG 2.0 2.2.1] Timing Adjustable: For each time limit that is set by the content, at least one of the following is true: (Level A) Note: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.
  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.
Not applicable (interactive/dynamic)
[WCAG 2.0 2.2.2] Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A) Note 1: For requirements related to flickering or flashing content, refer to Guideline 2.3. Note 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Note 3: Content* that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so. Note 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
  • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
  • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content*, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Not applicable (interactive/dynamic)
[WCAG 2.0 2.3.1] Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A) Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Not applicable (interactive/dynamic)
[WCAG 2.0 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages*. (Level A) For ADOD this is taken to refer to navigation mechanisms for bypassing blocks of content in general, including providing a table of contents for documents with multiple headings.
[WCAG 2.0 2.4.2] Page Titled: Web pages* have titles that describe topic or purpose. (Level A) Especially relevant to presentation slide titles.
[WCAG 2.0 2.4.3] Focus Order: If a Web page* can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)  
[WCAG 2.0 2.4.4] Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)  
[WCAG 2.0 2.4.5] Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA) Not applicable (interactive/dynamic)
[WCAG 2.0 2.4.6] Headings and Labels: Headings and labels describe topic or purpose. (Level AA)  
[WCAG 2.0 2.4.7] Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) Not applicable (application responsibility)
[WCAG 2.0 3.1.1] Language of Page: The default human language of each Web page* can be programmatically determined. (Level A)  
[WCAG 2.0 3.1.2] Language of Parts: The human language of each passage or phrase in the content* can be programmatically determined except 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. (Level AA)  
[WCAG 2.0 3.2.1] On Focus: When any component receives focus, it does not initiate a change of context. (Level A) Not applicable (interactive/dynamic)
[WCAG 2.0 3.2.2] On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A) Not applicable (interactive/dynamic)
[WCAG 2.0 3.2.3] Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA) Not applicable (interactive/dynamic)
[WCAG 2.0 3.2.4] Consistent Identification: Components that have the same functionality within a set of Web pages* are identified consistently. (Level AA)  
[WCAG 2.0 3.3.1] Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A) Not applicable (interactive/dynamic)
[WCAG 2.0 3.3.2] Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A) Not applicable (interactive/dynamic)
[WCAG 2.0 3.3.3] Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA) Not applicable (interactive/dynamic)
[WCAG 2.0 3.3.4] Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
  • Reversible: Submissions are reversible.
  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
Not applicable (interactive/dynamic)
[WCAG 2.0 4.1.1] Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A) Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Not applicable (application responsibility)
[WCAG 2.0 4.1.2] Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A) Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Not applicable (interactive/dynamic)

Appendix B: Rationale for inclusion of success criteria in “Part 2: [ADOD-Office-Formats] Assessing the accessibility of office documents formats”

These success criteria relate to assessing the intrinsic accessibility features and supports provided by various office document formats, not the accessibility of actual office documents created by authors (for this, see Part 1: [ADOD-Office-Documents], above).

Essentially, each success criterion refers to the office formats ability to support any functionality pre-supposed by the [ADOD-Office-Documents] success criterion of the same number. Some success criteria numbers have been omitted removed because they apply at the content level rather than the format level (e.g. colour contrast requirements).

Note: In addition, the XML Accessibility Guidelines (XAG) Working Draft (3 October 2002) [http://www.w3.org/TR/xag] was consulted. This Working Draft had been intended to provide guidance on designing XML formats to better support accessibility. It did not become a full W3C Recommendation.

[ADOD-office-documents] success criteria ADOD Applicability and/or Modifications
[ADOD-Office-Documents 1.1.1] Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
i.e., what text alternative mechanisms does the format include (e.g., encapsulated in media file)?
From a format perspective, the exceptions are irrelevant, except to note that a format must be present to have the non-text content ignored by assistive technologies.
[ADOD-Office-Documents 1.3.1] Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. i.e., what programmatic information/structure/relationship mechanisms does the format include (e.g., default named styles)?
[ADOD-Office-Documents 1.3.2] Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. i.e., what reading sequence mechanisms does the format include?
[ADOD-Office-Documents 1.3.3] Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. Note: For requirements related to color, refer to Guideline 1.4. Not applicable (applies at content-level, not format-level)
[ADOD-Office-Documents 1.4.1] Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding. Not applicable (applies at content-level, not format-level)
[ADOD-Office-Documents 1.4.3] Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: 
  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
Not applicable (applies at content-level, not format-level)
[ADOD-Office-Documents 1.4.5] Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: Note: Logotypes (text that is part of a logo or brand name) are considered essential.
  • Customizable: The image of text can be visually customized to the user's requirements;
  • Essential: A particular presentation of text is essential to the information being conveyed.
Not applicable (applies at content-level, not format-level)
[ADOD-Office-Documents 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content [in office documents]. i.e., what navigation mechanisms does the format include that support bypassing blocks of content?
[ADOD-Office-Documents 2.4.2] Page Titled: [Office documents] have titles that describe topic or purpose. i.e., what titling mechanisms does the format include?
[ADOD-Office-Documents 2.4.3] Focus Order: If [an office document] can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. i.e., what focus navigation sequence mechanisms does the format support?
[ADOD-Office-Documents 2.4.4] Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. i.e., what mechanisms are provided for setting the link purpose (e.g., link text, title, etc.)?
[ADOD-Office-Documents 2.4.6] Headings and Labels: Headings and labels describe topic or purpose. i.e., what heading and labeling mechanisms does the format include?
[ADOD-Office-Documents 3.1.1] Language of Page: The default human language of each [office document] can be programmatically determined. i.e., can human language be set for the whole document?
[ADOD-Office-Documents 3.1.2] Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except 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. i.e., can human language be set for parts of a document?
[ADOD-Office-Documents 3.2.4] Consistent Identification: Components that have the same functionality within a set of [office documents] are identified consistently. Not applicable (applies at content-level, not format-level)


 

Appendix C: Rationale for inclusion of success criteria in “Part 3: [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces”

These guidelines relate to determining the accessibility of office applications to users with disabilities (see “Scope”).
ATAG 1.0 Guideline 7 (Priority 1 and 2 Checkpoints) has been used as a basis for [ADOD-Office-Applications-UI] (see “Relationship between ADOD and WCAG 2.0/ATAG 1.0”), with the following exceptions:

  • Some terminology and references need to be interpreted differently as follows:
    • * Web-specific terms. These should be interpreted in the context of office documents and office applications (see “Relationship between ADOD and WCAG 2.0/ATAG 2.0”)
      • “document markup” is to be interpreted as “office document”
ATAG 1.0 Guideline 7 Checkpoints (Priority 1 and 2) AADOD Applicability and/or Modifications
7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions that are essential to accessibility; Priority 2 for those that are important to accessibility; Priority 3 for those that are beneficial to accessibility). The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. The priority 3 clause is not applicable.
The Checkpoint is very general, and includes:
  • Supporting relevant accessibility API(s)
  • Web-based tools conforming to WCAG
  • Keyboard access
  • Providing keyboard shortcuts where recommended for a platform
  • Respecting platform settings (such as “high contrast” modes)
  • Providing documentation
7.2 Allow the author to change the presentation within editing views without affecting the document markup*. [Priority 1] This allows the author to edit the document according to personal requirements, without changing the way the document is rendered when published.  
7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1]  
7.4 Ensure that the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1]  
7.5 Enable editing of the structure of the document in an accessible fashion. [Priority 2]  
7.6 Allow the author to search within editing views. [Priority 2]  


 

Appendix D: Rationale for inclusion of success criteria in “Part 4: [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents”

These guidelines relate to determining the degree to which all users are supported by office applications in the production of accessible office documents.
ATAG 1.0 Guidelines 1-6 (Priority 1 and 2 Checkpoints) has been used as a basis for [ADOD-Office-Applications-Supports] (see “Relationship between ADOD and WCAG 2.0/ATAG 1.0”), with the following exceptions:

  • Some terminology and references need to be interpreted differently as follows:
    • * Web-specific terms. These should be interpreted in the context of office documents and office applications (see “Relationship between ADOD and WCAG 2.0/ATAG 2.0”)
      • “web page(s)” is to be interpreted as “office document(s)”
      •  “(web) content” is to be interpreted as “(office document) content”
      •  “markup languages” is to be interpreted as “office document formats”
      • “authoring tool” is to be interpreted as “office application”
    • † References to WCAG 1.0. These should be interpreted as references to [ADOD-Office-Documents] (Part 2).
    • ‡ References to ATAG 2.0 Part A. These should be interpreted as references to [ADOD-Office-Applications-UI] (Part 3).
    • Some success criteria are not applicable. The reasons for this include:
      • (office applications are typically also the viewers): The success criterion is not relevant because office applications are typically both the authoring and (pre)viewing applications for office documents.
    ATAG 1.0 Guideline 1-6 Checkpoints (Priority 1 and 2) ADOD Applicability and/or Modifications
    1.1 Ensure that the author can produce accessible content* in the markup language(s)* supported by the tool*. [Priority 1]  
    1.2 Ensure that the tool* preserves all accessibility information during authoring, transformations, and conversions. [Priority 1] e.g., when saving between office document formats
    1.3 Ensure that when the tool* automatically generates markup* it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]  
    1.4 Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]  
    2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]
    W3C specifications have undergone review specifically to ensure that they do not compromise accessibility, and where possible, they enhance it.
    Not applicable (Web-specific)
    2.2 Ensure that the tool* automatically generates valid markup*. [Priority 1]
    This is necessary for user agents to be able to render Web content in a manner appropriate to a particular user's needs.
     
    3.1 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority]
    Note: Some checkpoints in the Web Content Accessibility Guidelines 1.0 [WCAG10] may not apply.
     
    3.2 Help the author create structured content and separate information from its presentation. [Relative Priority]
    Note: Some checkpoints in Web Content Accessibility Guidelines 1.0 [WCAG10] may not apply.
     
    3.3 Ensure that prepackaged content* conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
    For example, include captions, an auditory description, and a collated text transcript with prepackaged movies.
     
    3.4 Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]
    For example, prompt the author for a text equivalent of an image. If the author has already provided a text equivalent for the same image used in another document, offer to reuse that text and prompt the author for confirmation. If the tool automatically generates a "Search" icon, it would be appropriate to automatically reuse the previously authored text equivalent for that icon. Refer also to checkpoint 3.3 and checkpoint 3.5.
    Note: Human-authored equivalent alternatives may be available for an object (for example, through checkpoint 3.5 and/or checkpoint 3.3). It is appropriate for the tool to offer these to the author as defaults.
    Additional support text is unnecessary and references a Checkpoint 3.5, which is Priority 3.
    4.1 Check for and inform the author of accessibility problems. [Relative Priority]
    Note: Accessibility problems should be detected automatically where possible. Where this is not possible, the tool* may need to prompt the author to make decisions or to manually check for certain types of problems.
     
    4.2 Assist authors in correcting accessibility problems. [Relative Priority]
    At a minimum, provide context-sensitive help with the accessibility checking required by checkpoint 4.1
     
    4.3 Allow the author to preserve markup not recognized by the tool. [Priority 2]
    Note: The author may have included or imported markup that enhances accessibility but is not recognized by the tool.
    Not applicable (Web specific).
    5.1 Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool*. [Priority 2]  
    5.2 Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the most obvious and easily initiated by the author. [Priority 2]  
    A Document all features that promote the production of accessible content*. [Priority 1]  
    B Ensure that creating accessible content* is a naturally integrated part of the documentation, including examples. [Priority 2]  


     

    Appendix E: Comparison between ADOD and Section 508 Regulations (2001)

    During the Public Review, the issue of harmonization with the U.S. Section 508 Regulations (Electronic and Information Technology) was raised. While the ADOD Assessment Framework is based on WCAG 2.0/ATAG 1.0, it is useful to consider how they compare with Section 508.

    Accessibility of Office Documents (Part 1 [ADOD-Office-Documents] Assessing the accessibility of office documents)

    This part of the ADOD Assessment Framework is based on WCAG 2.0 and is most similar to “1194.22 Web-based Intranet and Internet Information and Applications” of the Section 508 Regulations (2001).  The table below identifies how ADOD requirements compare with the Section 508 criteria. Note: The Section 508 Regulations are currently being updated and there are indications that the new regulations will be more closely harmonized with WCAG 2.0 and therefore with this Part of the ADOD Assessment Framework.

    Section 508 Criteria [ADOD-Office-Documents] Assessing the accessibility of office documents
    1194.22(a) A text equivalent for every non-text element shall be provided (for example via alt or longdesc attributes, or in element content) [ADOD-Office-Documents 1.1.1] Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
    • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
    • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
    • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
    1194.22(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. Not applicable (interactive/dynamic)
    1194.22(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. [ADOD-Office-Documents 1.4.1] Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
    [ADOD-Office-Documents 1.4.3] Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: 
    • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
    • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
    • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
    1194.22(d) Documents shall be organized so they are readable without requiring an associated style sheet. Not applicable (Web content specific)
    1194.22(e) Redundant text links shall be provided for each active region of a server-side image map. Not applicable (interactive/dynamic)
    1194.22(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. Not applicable (interactive/dynamic)
    1194.22(g) Row and column headers shall be identified for data tables. [ADOD-Office-Documents 1.3.1] Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
    1194.22(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. [ADOD-Office-Documents 1.3.1] Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
    1194.22(i) Frames shall be titled with text that facilitates frame identification and navigation. Not applicable (Web content specific)
    1194.22(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. Not applicable (interactive/dynamic)
    1194.22(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. Not applicable (interactive/dynamic)
    1194.22(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. Not applicable (interactive/dynamic)
    1194.22(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with paragraphs 1194.21(a) through (l). Not applicable (interactive/dynamic)
    1194.22(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. Not applicable (interactive/dynamic)
    1194.22(o) A method shall be provided that permits users to skip repetitive navigation links. [ADOD-Office-Documents 2.4.1] Bypass Blocks: A mechanism is available to bypass blocks of content [in office documents].
    1194.22(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. Not applicable (interactive/dynamic)

     Accessibility of Office Document Formats (Part 2 [ADOD-Office-Formats] Assessing the accessibility of office document formats)

    Not specifically addressed by the Section 508 Regulations (2001).

    Accessibility of Office Application User Interfaces (Part 3 [ADOD-Office-Applications-UI] Assessing the accessibility of office application user interfaces)

    This part of the ADOD Assessment Framework is based on ATAG 1.0 and is most similar to “1194.21 Software Applications and Operating Systems” of the Section 508 Regulations (2001). This part of ADOD begins with the general requirement to “[u]se all applicable operating system and accessibility standards and conventions that are important or essential to accessibility…”. This would seem to include 1194.21 (in the U.S. market).
    In addition, there are five other requirements that are specific to authoring interfaces that the Section 508 Regulations (2001) do not directly address.

    Support for Authoring Accessible Office Documents (Part 4 [ADOD-Office-Applications-Supports] Assessing the provision by office applications of support for authoring accessible office documents)

    Not specifically addressed by the Section 508 Regulations (2001).

    Acknowledgments

    This document was produced as part of the Accessible Digital Office Document (ADOD) Project (http://adod.idrc.ocad.ca/).

    This project has been developed by the Inclusive Design Research Centre, OCAD University as part of an EnAbling Change Partnership project with the Government of Ontario and UNESCO (United Nations Educational, Scientific and Cultural Organization).

    Partner logos: UNESCO-United Nations Educational, Scientific and Cultural Organization, the Government of Ontario and the Inclusive Design Research Centre (OCAD University)

    Copyright © 2010 Inclusive Design Research Centre, OCAD University
    This material may be reproduced and distributed in print or electronic format only as long as:
    (a) it is offered at no cost to the recipients; and
    (b) full credit is given to the Inclusive Design Research Centre, OCAD University; and
    (c) the copyright notice is preserved (e.g., "Copyright © Inclusive Design Research Centre, OCAD University”).