RE: Conformance Testing Proposal

Thanks, Doyle.

As far as I'm aware, none of the existing commercial screen readers
claims to support Netscape or Mozilla at all.  I queried Freedom
Scientific (JAWS), GW Micro (Window-Eyes), and Dolphin (HAL, SuperNOVA).
None of them supports Netscpa or Mozilla or Opera .  All explained that
they didn't have the resources to provide support for multiple browsers.

However, Netscape, Mozilla, and Opera do support client-side image maps
with alt text on the <area> elements, for whatever that may be worth to
people with low vision and others who prefer those particular user
agents. Internet Explorer also supports client-side iamge maps with alt
text on the <area> elements, and of course JAWS, Window-Eyes, and
HAL/SuperNOVA support IE.  IBM's Home Page Reader 3.02 (the current
version), which is built around IE, also supports client-side image maps
with alt text on the <area> elements.  I believe pwWebSpeak, now defunct
but still in lmited circulation, also supports client-side image maps
with alt text on the <area> elements.  

In my judgment, what I've said above makes the requirement for redundant
text links redundant.  But what I've said isn't the whole story: there
are other PC-based user agents, as well as user agents for handhelds,
etc. I don't have access to those.  Can anyone out there help us out?

And, while we're on the topic, does anyone know whether the Macintosh
implementations of any of these or other user agents support client-side
image maps with alt attributes on the <area> elements? This will become
an important issue if the spoken interface for OSX gets off the ground.

John
"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: Doyle Burnett [mailto:dburnett@sesa.org] 
Sent: Monday, April 05, 2004 11:24 am
To: John M Slatin; Chris Ridpath; W3C Web Content
Subject: Re: Conformance Testing Proposal


Hi John and the List:

I only want to respond to John's question #3.  Question follows -

3. Why is it still necessary to require redundant text links for
client-side image maps? Are there still user agents that don't support
client-side image maps that have valid alt attributes for <area>
elements? 

Response follows -

I did some testing with regard to client-side image maps on different
(okay, Netscape's newest browser) - David MacDonald did testing as well.
As I recall, David found client-side image maps not to work with
Netscape when using JAWS and I believe Home Page Reader.  I found
Netscape to be very unpredictable with regard to client-side image maps
when using JAWS.

For now, it seems leaving redundant links as a good technique is
probably a good thing.  Also, does anyone know how Apple's new operating
system with it's built-in speaking interface will handle client-side
image maps that have been properly tagged?

Just my thoughts.

Doyle

Doyle Burnett
Education and Training Specialist
Multiple Disabilities Program
Special Education Service Agency
dburnett@sesa.org
Www.sesa.org
-- 



3. Why is it still necessary to require redundant text links for
client-side image maps? Are there still user agents that don't support
client-side image maps that have valid alt attributes for <area>
elements?

On 4/5/04 8:09 AM, "John M Slatin" <john_slatin@austin.utexas.edu>
wrote:

> 
> Thanks, Chris. I agree that something like this will be helpful for 
> many developers who want to do the right thing.
> 
> Some questions:
> 1. Is this list intended as a preliminary proposal for a 
> technology-specific checklist? If not, what relationship does it have 
> to such a checklist? 2. Can this checklist be numbered consistently 
> with WCAG 2.0 to make it easier for developers to tell when they're 
> meeting WCAG success criteria?
> 3. Why is it still necessary to require redundant text links for
> client-side image maps? Are there still user agents that don't support
> client-side image maps that have valid alt attributes for <area>
> elements?
> 
> 
> Some comments about longdesc and d-links:
> 1. We should not *require* redundant use of longdesc *and* d-link for
> <img> elements that need additional description.   If support for
> longdesc isn't widespread enough to be reliable, we should require 
> that descriptions be provided either on-page or in a separate, linked 
> file/window. 2. On pages that display multiple images that require 
> description, link-text pointing to the descriptions should identify 
> the image to which the description refers.
> 
> Thanks!
> John
> 
> "Good design is accessible design."
> Please note our new name and URL!
> John Slatin, Ph.D.
> Director, Accessibility Institute
> University of Texas at Austin
> FAC 248C
> 1 University Station G9600
> Austin, TX 78712
> ph 512-495-4288, f 512-495-4524
> email jslatin@mail.utexas.edu
> web http://www.utexas.edu/research/accessibility/
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On 
> Behalf Of Chris Ridpath
> Sent: Monday, April 05, 2004 10:26 am
> To: WAI WCAG List
> Subject: Conformance Testing Proposal
> 
> 
> 
> Page authors need to know what they must do in order to conform to the

> WAI guidelines. We must spell out in clear terms what must be done to 
> achieve compliance.
> 
> The current situation is that nobody really knows if their site's 
> content complies or not. This is because the WCAG 1 was open to 
> interpretation. Interpreting the guidelines has been an impediment to 
> page authors performing the simple but necessary things that make 
> content accessible. Current research has been critical of the WCAG 1 
> because of the way that people must interpret the guidelines.
> 
> The current state of accessibility conformance "I can't define it, but

> I know it when I see it" must be changed.
> 
> My proposal is that we state, for each technology, the things that 
> must be done in order for a page to claim conformance. This is 
> possible and practical and is what page authors require.
> 
> For example we require that, in HTML, all IMG elements have an ALT 
> attribute. If any IMG element does not have an ALT attribute then the 
> page cannot claim conformance.
> 
> The list of requirements would be subject to periodic change by the 
> WAI. For example in 2004 we require a d-link for any IMG element that 
> has a LONGDESC attribute. In 2005 or 2006 as the LONGDESC is better 
> supported the d-link requirement would be dropped. As better tests for

> semantic content are developed they could be added as requirements.
> 
> The initial list of requirements would likely not cover 100% of 
> accessibility problems but it would improve over time and would be 
> much better than the current situation. Simply because we can not 
> define all accessibility requirements now is not a good reason for 
> being vague.
> 
> A clear list of requirements would ensure that page authors know 
> exactly what to put in their web pages. It would increase web 
> accessibility.
> 
> Clear requirements would mean that people, or machines, could actually

> test for compliance with the guidelines. Many authors want to do the 
> right thing but don't know how.
> 
> As a starting point, here's what I think the WCAG 2 requirements for 
> HTML
> are: 
> http://checker.atrc.utoronto.ca/servlet/ShowGuide?name=wcag-2-0-html-t
> ec
> hs.xml&lang=eng
> 
> I'm sure that this list has errors and omissions but it proves that we

> can do this.
> 
> We can, and must, clearly describe what the guidelines mean.
> 
> Cheers,
> Chris
> 
>

Received on Monday, 5 April 2004 12:36:54 UTC