1. Introduction

W3C/WAI appreciated the opportunity to participate in the TEITAC process, and commends the hard work by TEITAC committee members, especially the Co-Chairs, Committee Chairs, and Editorial Working Group. This minority report provides additional information in three areas: progress towards harmonization goals; authoring tool support for production of accessible content; and visual indication and documentation of keyboard interactions.

2. Extent of harmonization with WCAG 2.0, and remaining work to be done

W3C/WAI appreciates the extent to which W3C/WAI’s Web Content Accessibility Guidelines (WCAG 2.0) was taken up by TEITAC, both with regard to individual Web-related technical provisions, and with regard to the application of Web accessibility principles to a broader range of information and communications technologies. However, we would like to caution against overly broad claims at this time regarding the extent of harmonization achieved in the TEITAC report.

While there was extensive and commendable dialog between the WCAG Working Group and TEITAC participants during the development of the TEITAC report, the outcome was not complete harmonization of individual technical requirements, nor of conformance levels. In addition, because there was an extremely short time between availability of the final report and the deadline for minority positions (less than a day and a half), and because provisions were changing till nearly the end of the process, there was insufficient time to do a final detailed comparison of harmonization on a provision-by-provision basis. Furthermore, WCAG 2.0 is still in development, and the next stage will be a collection of implementation experience, which may be useful in informing the Access Board of potential feasibility concerns on various provisions.

W3C/WAI therefore recommends that the Access Board consider several follow-up steps to maintain the extent of harmonization already achieved, and to enhance progress towards one of the Committee’s initial charges which was to seek harmonization with international standards. Otherwise we believe that there is the possibility of repeating the fragmentation problems arising between the first version of the Sec. 508 standard and WCAG 1.0. W3C/WAI would like to offer its continued help in these areas, which include:

coordinating with W3C/WAI on a precise assessment of harmonization achived between the final version of the TEITAC report and the latest version of WCAG 2.0;

maintaining communication with W3C/WAI regarding implementation experience during WCAG 2.0 Candidate Recommendation which may relate to TEITAC provisions, and monitoring any resulting changes in WCAG 2.0;

considering an option whereby, for Web content, it could be noted that by conforming to WCAG 2.0 AA, agencies would meet their obligations under Sec. 508.

3. Consider how authoring tools can facilitate production of more accessible content

The TEITAC Committee considered a number of provisions, regarding support for production of accessible content, which were drawn from W3C/WAI’s Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0). Of these, two provisions were taken up by the committee as consensus items, and two provisions approached but did not achieve consensus in the time available.

The two provisions on which consensus was achieved were 7.A: “Accessible Output,” and 7.B: “Preserve Accessibility Information.” These provisions could be characterized as “first do no harm” authoring provisions, as they address the need to allow production of accessible content, and to not inadvertently strip out accessibility information once it has been added. As “first do no harm” authoring provisions, W3C/WAI believes that these provisions are valuable to maintain in the Section 508 and 255 work as it goes forward.

The two remaining provisions, 7.C: “Prompts” and 7.D: “Accessible Templates” received significant interest and support from committee members; and, based on responses from committee members, would have reached consensus if they had been more precisely and appropriately scoped. W3C/WAI believes that these two remaining provisions would contribute significantly to reducing the effort required by federal agencies to produce accessible content. We also agree with the need to better scope the provisions, considering both feasibility, and testability. Since W3C/WAI is continuing to develop related provisions through the Authoring Tool Accessibility Guidelines Working Group (AUWG), we would like to offer our assistance in further exploring language for consideration. Viewpoint opinions with additional detail on these provisions were provided by W3C/WAI on both 7-C Prompts and 7-D Accessible Templates, and are included in the final report.

4. Visibility and documentation of keyboard interactions

Several issues arose towards the end of the TEITAC process when it became clear that certain user needs may have been overlooked in multiple standards processes, including in the TEITAC discussions up to that time. This resulted in a series of proposed provisions on keyboard shortcuts, none of which reached consensus within the available time. It appears however that one of these proposed provisions was within a few minutes of reaching consensus, had discussion on the final TEITAC call not been terminated ahead of schedule at the last meeting. This provision was D.1.1.B, [Documentation of] Keyboard Shortcuts. Version 9 in the final report reflects this language which apparently was near consensus. W3C/WAI encourages the Access Board to consider this language.

The other provision which was proposed but did not reach consensus was 3-SS Visual Indication of Keyboard Shortcuts. Based on a number of discussions with developers and users, we believe that additional time is needed to explore the feasibility of different approaches to address this user need on different platforms. W3C/WAI is pursuing similar clarification of this need, and approaches to addressing the need, in the User Agent Accessibility Guidelines Working Group (UAWG), and has invited interested parties to the discussion. Should we be successful in arriving at a cross-platform approach on this, we would like to offer that language to the Access Board for their consideration.