# TEITAC Minority Report Submission from IBM

**April 1, 2008**

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[^1], 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:

-   Functional performance criteria and assistive technology

-   Harmonization with WCAG 2.0

-   Additional Information following each Provision

## Functional performance criteria and assistive technology

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.

1.  If any of the technical provisions are not met, the Functional
    Performance Criteria *can* be used to see if access is provided in
    another way (i.e., through equivalent facilitation.)

2.  If the technical provisions are met, the Functional Performance
    Criteria *can* be used to see if the technical provisions cover all
    aspects needed to provide access to the product. (i.e overall
    evaluation.)

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

## Harmonization with WCAG 2.0 

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.

## Additional Information following each Provision

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.

## Conclusion 

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.

[^1]: TEITAC report entitled "Refreshed Accessibility Standards and
    Guidelines in Telecommunications and Electronic and Information
    Technology"