Thread Subject: Re: StartingdiscussionsontheAccessibilityAPIproposal

Note

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: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 9:45 AM

As far as tools go, I would think we would still need a well-defined API
or standard format for content types (e.g., SGML, XHTML, XML, ODF, RTF,
PDF, etc.) along with the proper versioning before we could begin
recommending tools.

The W3C validator itself can be used as one example. It is a piece of
software that tries to check the content against the appropriate HTML
standard. It is good but imperfect. But, as their is a well-defined
standard for HTML in their various incarnations, I would say that if a
someone created content that followed the standard (lets pick XHTML 1.0
as a specific example) then I could test the document with tools. Also,
when the test tools or even assistive technology failed to provide
access (as sometimes is the case) as long as the vendor followed the
standard the content should be judged compliant. This is to some readers
an obvious example as it has happened that some screen readers have had
problems reading properly tagged HTML tables. We have judged HTML
content as being Section 508 compliant when situations such as this
exist, as the screen reader itself is defective (and in our example it
is important to note the screen reader vendor fixed the issue in a later
release).

I think this would also drive us closer to having standards the
assistive technology vendors themselves can use as a baseline, rather
than us assuming testing with assistive technology is enough to verify
the proper use of a specific Accessibility API. As those of us who use
assistive technology know, the assistive technology vendors are really
good at providing software that may provide access in non-standard ways
(e.g., undocumented operating system features, injection into the video
driver chain) that may not help us when we are testing against any
standards based implementation.

So we need to base any of this on officially recognized standards
already existing in industry.

Regards,

Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Saturday, January 13, 2007 8:51 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re:
[teitac-websoftware]StartingdiscussionsontheAccessibilityAPIproposal


Alex, you raise some important points about automated tools.

I think we all agree that automated tools are good enough for
some purposes
but not good enough for others.

Can we use this in drafting and categorizing the revised
Standards? That is,
if we want to integrate guidance materials like "sufficient
techniques", we
could draft Standards that are susceptible of automated testing,
and Standards
that weren't, providing different guidance materials as
necessary. I believe
that this would clarify best practices for testing for both
developers/companies
and procurement testers/agencies.


Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University