Adobe Systems Minority Report
Refreshed Accessibility Standards and Guidelines in Telecommunications and Electronic and Information Technology
April 2008
| |
Adobe Systems Minority ReportRefreshed Accessibility Standards and Guidelines in Telecommunications and Electronic and Information TechnologyApril 2008 |
Adobe Systems is grateful for the opportunity to submit brief comments on the final report from the Telecommunications and Electronic and Information Technology Advisory (TEITAC) Committee in the form of this Minority Report to the United States Access Board.
The work of the TEITAC committee produced a very much improved set of standards, accomplishing many goals defined at the onset of the work. There are a small number of specific issues that are important to Adobe that this minority report seeks to comment on and to provide suggestions for the Access Board to consider as it begins its process of defining the final standards. These issues have been discussed with the committee as a whole as well as in subcommittees, but are sufficiently concerning as to merit mention in this report.
Captions – The current versions of the definition of captions are very similar to each other. Adobe prefers version 2 in order to be harmonized with WCAG 2.0.
Programmatically determinable – For purposes of harmonization, Adobe supports version 3 of this definition.
The Functional Performance Criteria (FPC) provide a valuable means to determine the accessibility of products. Related to the advisory note at the conclusion of the FPC section in the TEITAC report:
The Committee was unable to come to an agreement on whether the first two roles for the Functional Performance Criteria, as described in the introduction to the recommendations in Subpart B are requirements (“must”) or options (“can”). The Access Board is requested to make this determination.
Adobe feels that it is important for conformance with the technical provisions to be able to satisfy conformance with Section 508 overall, and that the FPC be used as a means to assess conformance at times when the specific technical provisions cannot be met or do not apply. As such, procurement officers would not be required to undergo extra steps evaluating products against the FPC. Adobe recommends that the language in roles #1 and #2 in Subpart B: Functional Performance Criteria use “can” instead of “must” language in recognition of the intent of the technical provisions to address accessibility for the users defined in the FPC and in recognition of the additional costs associated with each technical evaluation conducted under Section 508 if the “can” language is not selected.
Harmonization to international accessibility standards was a stated requirement for the work of the TEITAC committee, and an important goal for Adobe Systems and other IT companies due to the proliferation of worldwide accessibility standards with which Adobe needs to comply.
Of particular importance is harmonization with the W3C’s Web Content Accessibility Guidelines 2.0 (WCAG 2.0). The WCAG 2.0 Working Group is making final minor refinements to the language in their document, and it is important for the Access Board to maintain contact with the working group and update the Section 508 requirements accordingly to ensure that harmonization is maintained.
Adobe also recommends that the Access Board carefully consider the effect of setting WCAG 2.0 level AA provisions as in force for all software, especially since the focus of the WCAG document is web sites and web applications. In some cases, the provisions in WCAG 2.0 level AA may present additional challenges or design limitations on non-web-based software, whereas the Level A provisions in WCAG 2.0 are more broadly applicable and should form the basis of the required items in the Section 508 rules. It is highly desirable for web-based products that comply with Section 508 to be able to also claim compliance with WCAG 2.0 Level A.
1-G Text Size – Adobe believes that this issue is potentially incompatible with User Preferences provision 3-D and should be evaluated carefully for such issues.
3-SS Visual Indication of Keyboard Shortcuts – Adobe indicated significant concerns regarding the feasibility of this provision in the TEITAC report.
3-U AT Interoperability – Adobe indicated significant concerns regarding sub-provision (g) in 3-U, but agrees with all other portions of this provision.
5-C Interactive Elements – Adobe does not regard 5-C as necessary, since it is redundant to other technical provisions. In fact, all that 5-C serves to do is provide a reminder that other technical provisions must be addressed. Clarity in the application of other technical standards is preferable to the inclusion of this one.
7-C Prompts – The prompting provision, as written, is poorly defined and as a result untestable. The committee has not been able to define what prompts would be required for compliance with known and familiar formats such as HTML – it will be very unclear to evaluators of Section 508 compliance what constitutes success for less-familiar formats and a topic of debate for better-known formats. Prompting is helpful to authors in some, but not all circumstances, and as such Adobe recommends that 7-C be a recommendation but not a requirement.
7-D Accessible Templates – As noted in the comments from W3C/WAI in the full report, this provision needs improvements in clarity before being incorporated into the technical provisions. This provision is not required for authors to create content that meets Section 508, but is certainly a good recommendation for authoring tools to provide models as a learning aid for authors and developers. This provision is less clear when applied to complex application authoring tools, where the end-product created from the tool is rarely based on a template. Adobe recommends that this provision be established as a recommendation.
1.1-B Keyboard Shortcuts – Adobe supports version 9 of the Keyboard shortcut provision.