Version: Dec. 2010
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/.
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.
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
The ADOD Assessment Framework applies specifically to office documents, which are defined as computer documents that are:
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
Accessibility of Office Document Formats
Accessibility of Office Application User Interfaces
Support for Authoring Accessible Office Documents
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.
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:
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:
* At the time of writing, ATAG 1.0 is the current Recommendation of W3C; ATAG 2.0 is under development.
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.
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).
[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.
[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:
[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.
[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.
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.).
[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.
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).
[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.
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).
[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.
Terms specific to WCAG 2.0 and ATAG 1.0 are defined in those Recommendations.
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.
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:
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)
|
The following exceptions are not applicable (interactive/dynamic):
|
[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)
|
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)
|
|
[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.
|
|
[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.
|
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.
|
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)
|
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) |
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.
|
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:
|
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.
|
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) |
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:
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:
|
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] |
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:
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] |
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.
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.
|
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:
|
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) |
Not specifically addressed by the Section 508 Regulations (2001).
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.
Not specifically addressed by the Section 508 Regulations (2001).
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).
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”).