Thread Subject: Re: StartingdiscussionsontheAccessibilityAPIproposal
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Li, Alex
Date: Fri, Jan 12 2007 11:40 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Jim Tobias: "Re: StartingdiscussionsontheAccessibilityAPIproposal"
- Previous message in thread: None
- Messages sorted by: Author | Thread | Date
Regarding Don's comment: there are some fundamental issues if we rely on
First, test tools fall short of testing guidelines/requirements that
requires human judgements and human judgement is necessary in part of
all known acessibility standards and guidelines. We have to make the
decision to eliminate all subjectivities from 508 requirements if we
want to attempt any test tool specification.
Second, test tools always make certain assumptions about technology
used. In many cases, we see the assumption of html and css only or
other combinations of technologies. These assumptions must be made in
order to design test tools. Unfortunately, such assumptions do not
necessarily hold up in real world situations where developers have to
use a wider range of technologies to meet functional requirements. In
some cases, the technology may be proprietary where generally available
test tools cannot accommodate. Furthermore, some test tools also assume
the use of certain AT products. This would not necessarily be
Third, demanding automated test tools in 508 guideline set up
expectations for "passing" the automated test regardless of the level of
accessibility when the applicability of test tools to technologies in
use. Thus, products that meet the assumptions of the test tools in used
would have an unfair advantage regardless of actual fulfillment of 508
Fourth, it is impossible to assure quality of test tools via 508 unless
we also specify performance requirements for test tools as well. I'm
sure that is not where we want to go.
Fifth, pointing to specific testing tools would cause unfair market
advantage to specfic tool vendors. That is not an option for 508.
There are cases where test tools would be of help and that they are used
as part of the QA and/or development cycle. But I don't think we can
explicitly rely on test tools.
>Can the standards require that tools, if they exist, such as the Ferret
>and the Monkey and Inspect Objects, etc. be utilized to show adherence
>to a given set of specifications? I would love to see it if possible.
>Greg is right that it is in the testing that the rubber really meets
>road, and anything we can do to build some level of testability or
>accountability into the standards will move us further in that
- Next message in Thread: Jim Tobias: "Re: StartingdiscussionsontheAccessibilityAPIproposal"
- Previous message in Thread: None