Thread Subject:

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: Peter Korn
Date: Sun, Jan 21 2007 11:30 PM

Hi Norman,

Note: I've changed the topic/subject line to reflect the shift of this
thread.

> 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.

Looking at document content, I think the first issue is whether all of
the information needed for accessibility can be encoded in the format
(e.g. HTML defining the existence of ALT tags for images -> if there
isn't such a definition, then you can't encode it even if you want to).
Second to that is the question of whether document authors are encoding
the information that they should. This will likely give rise to some
judgment calls -> if a particular document element can have both a name
and a description, it may not always be necessary for obvious/simple
elements to have a description in addition to the name. The third (and
perhaps final) issue is ensuring that the applications that
read/write/display this content are accessible, support AT on the
platform(s) they run on, etc.

I think this has less to do with any specific standard format, as it
does that each any every document format in question must address the
first issue (and document authors address the second, and document
related software address the third).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
> 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
>
>
>
> ------------------------------------------------------------------------
> *From:* Li, Alex [mailto: = EMAIL ADDRESS REMOVED = ]
> *Sent:* Friday, January 12, 2007 1:29 PM
> *To:* = EMAIL ADDRESS REMOVED =
> *Subject:* Re: [teitac-websoftware]
> StartingdiscussionsontheAccessibilityAPIproposal
>
> Regarding Don's comment: there are some fundamental issues if we
> rely on test tools.
>
> 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 appropriate
> assumptions.
>
> 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 requirements.
>
> 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 the
> >road, and anything we can do to build some level of testability or
> >accountability into the standards will move us further in that
> >direction.
>
>
>
> ------------------------------------------------------------------------
>
>

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