IBM has been honored to serve on the Telecommunications and Electronic Information Technology Advisory Committee (TEITAC), chartered by the Access Board beginning in September 2006. This committee brought together all stakeholders that are affected by Section 508. Such broad representation created quite a challenge in coming to consensus on recommended changes to Section 508 and 255 standards but it was an appropriate approach that allowed all views to be heard. We all learned a lot from each other through the process and new long lasting working relationships were formed as a result.
One of the challenges we faced was to create recommendations that are technology neutral so that the resulting standards will not go out of date quickly. Even though this is challenging and may make the recommendations a bit difficult to understand by non-technical people, IBM strongly supports this approach. As a technology innovator who serves the government market, IBM needs globally harmonized standards that remain viable as new technologies are invented.
Even with such challenges, the committee did reach consensus on a large number of recommendations. As is apparent in the report¹, however, there were some areas where we were not able to achieve common ground. IBM’s positions on these unfinished provisions are documented along with other committee members in section 7 of the report.
It should be noted that consensus, as used in the TEITAC process, means that all stakeholders “accept” the provision, but it may not be the approach they “prefer” and they may have lingering concerns about it.
IBM brings to this report a balanced view from the extensive roles we play, not just that of a mainstream Information Technology (IT) vendor and service provider. IBM is a recruiter and employer of persons with disabilities, has nearly a century of innovations of technology specifically designed to benefit persons with disabilities, is an assistive technology (AT) vendor to persons with disabilities, and a leader in global standards and harmonization.
IBM would therefore like to comment on a few areas where we have remaining concerns:
Our first area of concern relates to the following note at the end of Subpart B Functional Performance Criteria:
The Committee was unable to come to an agreement on whether items #1 and #2 above are required (“must”) or an option (“can”). The Access Board is requested to make this determination.
The report omits any rationale or considerations that would be useful to the Access Board in making this decision.
IT-AT interoperability is a shared responsibility between IT and AT products. The issue of IT-AT interoperability is biased by past experience where precise application programming interfaces (APIs) did not exist or were inadequate to achieve actual interoperability with AT (such as screen readers) without customization of the AT by either the consumer or the AT vendor. And from a Section 508 perspective, the requirements in the initial technical standards are weak on interoperability. So in the past, the responsibility for supporting AT interoperability was unclear among the consumer, government agencies, AT vendor and IT vendor and often not sufficient to achieve interoperability for all product functions.
But Subpart C of the TEITAC report contains AT interoperability technical requirements, specifically provision 3-U, that are significantly strengthened and more precise over what was in the initial standard; so we have improved technical requirements and they were developed collaboratively between IT and AT vendors. 3-U is listed in Section 7 of the report as it did not reach consensus, however, it was extremely close to consensus as evidenced by the comments in support of it.
New AT interoperability APIs that either have been or are being developed are much more robust than those used in the past, and use of them has been shown to reduce or eliminate altogether the need for custom solutions. IT products using these newer APIs properly will pass the new requirements with a significantly increased degree of IT-AT interoperability without the need for custom solutions as long as the IT and the AT both support the same API. And since more IT will support the new and robust APIs, the AT investment will be reused and leveraged by AT vendors, improving the business case for better accessibility for consumers. Looking forward, there is a higher probability that IT and AT will actually work together based on mutual support of the API, without further customization investments.
IBM recommends that bullets #1 and #2 at the beginning of subpart B use “can” and not “must” so that IT vendors may identify on their VPATs which APIs they have implemented to support ATs.
Using “can” in this way, IT vendors can achieve a level of 508 conformance without a requirement to test with all types of AT, and agencies will be able to give preference in procurement to conforming products that can be expected to work with ATs. If an agency knows they need to use a particular AT, they would look to purchase 508 conforming IT products that support the APIs that are also supported by the AT or request the AT vendor to support the API. Conversely, when purchasing AT, they would look for AT products that support the APIs implemented in the IT products they use.
When new technology or features are invented and new APIs are needed, the 508 procurement process will create a new market and business justification for AT and IT vendors to invest in support for APIs to achieve interoperability and successful operation for the individual users with disabilities
IBM is very happy that the TEITAC achieved a degree of harmonization with W3C WCAG 2.0 work in process. The TEITAC recommended provisions seem well aligned with WCAG 2.0 technical provisions and will eliminate conflict for developers. We encourage the Access Board to avoid fragmentation by staying in contact with the W3C WAI as they complete their work on WCAG 2.0 and collect implementation evidence before WCAG 2.0 becomes final.
IBM does have one area of concern: Section 508 does not distinguish between Web applications (run in a browser) and traditional desktop applications (run in an operating system) and does not assign priorities as does WCAG 2.0. IBM’s experience shows there are some concerns when applying all of the provisions universally to all software and content. In WCAG 2.0, provisions are assigned to level A that are universally applicable to all websites and do not impose constraints on the design where there are user agent features (i.e. browsers) or assistive technologies that can provide the needed user function. The WCAG 2.0 level AA provisions impose constraints on design to a level which may not be universally appropriate and the user need can otherwise be met with user agent features and/or assistive technologies.
Implementation experience gathered by W3C/WAI will be publicly available to the Access Board staff and should be used as input in formulating the final refreshed technical standards and supporting information and tools.
Each recommended provision is followed by a set of Additional Information. As is stated in section 5.1 of the report, the thorough process of discussion, iterative modification, and final consensus used by the committee on the wording of each provision was not utilized in the formulation of this Additional Information. In most cases, the information is a simple statement of facts: the committee that submitted it, the original source in the current Section 508 or 255 standards, the international standard it is harmonized with, and the disabilities that are supported by the provision.
Two of the categories of additional information, however, are subjective in nature: Impact and Testability. While some discussion of Impact did take place in subcommittees, there was no discussion, either in subcommittees or in the committee, related to the issue of a test method for each provision. This information has been in drafts of the report for some time and was therefore subject to review and comment by committee members. It was not, however, discussed in committee or brought forward for consensus.
Of particular concern is the Testability information as it seems to be recommending a specific test method that is appropriate for the provision. Testing methods will vary based on the application and technology context and tools available. Opinions and research vary as to the most appropriate method to use for a particular provision.
IBM therefore urges the Access Board not to consider the Impact and Testability information to be reflective of the committee’s views as a whole in the same way that the provision text itself is. The Additional Information may be used as input to the Access Board staff in creating supporting information and tools.
IBM would like to compliment the committee co-chairs, members of the Editorial Working Group, and staff of the Access-Board on a job well done bringing this work to a successful conclusion. We look forward to continued dialog with the Access Board, staff, and related government agencies as they consider the committee recommendations and formulate the refreshed Section 508/255 standards and supporting information and tools.
¹ TEITAC report entitled “Refreshed Accessibility Standards and Guidelines in Telecommunications and Electronic and Information Technology”