W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2005

RE: R: NEW: Issue #1544

From: Roberto Scano - IWA/HWG <rscano@iwa-italy.org>
Date: Sat, 13 Aug 2005 19:28:29 +0200
To: "'Bob Regan'" <bregan@macromedia.com>, <w3c-wai-gl@w3.org>
Cc: "'Andrew Kirkpatrick'" <akirkpatrick@macromedia.com>
Message-ID: <002701c5a02c$6d4bda60$0200a8c0@rsnbiwa>



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Bob Regan
Sent: Saturday, August 13, 2005 6:59 PM
To: w3c-wai-gl@w3.org
Cc: Andrew Kirkpatrick; Roberto Scano (IWA/HWG)
Subject: RE: R: NEW: Issue #1544

I know this is going to get me more nasty emails privately...

So to be clear, in order to meet WCAG and Italian law, content needs to be
screen reader accessible in other browsers and other platforms? This would
be a particularly prescient move on the part of the Italian government given
the fact that most of the configurations beyond Windows / IE have been
released in the last few months. 


Roberto Scano:
You are referring accessibility to the only access by screen readers. I
suggest to read something about WAI:
http://www.w3.org/WAI/intro/accessibility.php
And this:
http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/#diff

We have:
- Visual disabilities 
- Hearing Impairments 
- Physical disabilities 
- Speech disabilities 
- Cognitive and neurological disabilities
- Multiple Disabilities
- Aging-Related Conditions

This is also inside some ISO documents, not only inside WAI.

Also I wanna remember about WCAG 1.0. You said: "So to be clear, in order to
meet WCAG and Italian law, content needs to be screen reader accessible in
other browsers and other platforms?"
Please note that italian Law is inspired to WCAG 1.0 and to this area of
WAI: http://www.w3.org/WAI/eval/.
WCAG 1.0 has a normative appendix regarding the metodology for valutation:
http://www.w3.org/TR/WCAG10/#validation

2. Use a graphical user interface (GUI) browser(such as Internet Explorer,
Netscape Navigator, or Opera) and examine the selection of pages while
adjusting the browser settings as follows [...]

If you also read the WCAG 1.0 Checkpoint 8.1: "Make programmatic elements
such as scripts and applets directly accessible or compatible with assistive
technologies [Priority 1 if functionality is important and not presented
elsewhere, otherwise Priority 2.]" is clear that having an object that
respect these specification only in a browser and only in an OS - this
object don't conform to WCAG 1.0 (and, if important, also without reach
level A).



Bob Regan:
This does not alter the fundamental question. In a situation like this one
where code validity creates a problem for the overwhelming majority of
screen reader users, what do we consider more important? The overwhelming
majority of end users today are trying to access content using Windows / IE
/ JAWS. Dropping the <embed> object will cause a significant use case to
experience serious problems. At the same time, keeping it does not disrupt
any of the existing use cases.

The choice then for the group is validity versus accessibility.

Roberto Scano:
Sorry, but the choice now is: wanna we create a precedent (so also other
vendor should in future made pressure in the name of "accessibility" for not
change their products for conform with last century specifications) or wanna
ask to these companies (and you are a big representative of Macromedia) to
start developing following web standards?
I suggest to take the same position of who develops for MathML:
http://www.dessci.com/en/products/mathplayer/tech/accessibility.htm
"If math accessibility is important to you, contact your screen reader
vendor so that they will consider supporting some of the planned
accessibility enhancements to MathPlayer.  Without your input, vendors may
not make math accessibility a priority." 

I think that WCAG Working group should work for the web (all) and not for
preserve market position and preistoric position of AT developers. Yes, I
can agree that the AT producers are strong and they monopolize the market,
but we should work for "accessibility for all" and not only for
"accessiblity for blind": otherwise we need to change our charter.


Bob Regan:
I think this is the best example of a case where validity breaks
accessibility. We can also talk about a much longer list of cases where
validity does not result in accessibility. In all cases, the reasons are
complex and require cooperation among standards groups, AT vendors,
authoring tool makers and browser makers. How do we sustain this dialog? How
do we realize the potential in valid code? 

Roberto Scano:
If all these companies emulate "Hearing Impairments", i think that the end
user should start to press: we need simply to create a baseline for let all
the part involved to work for develop:
- web contents that are accessible and that respect reccomandations
- authoring tools that develop accessible and valid content
- user agents that are able to handle valid code and invalid code
- OS developers that are able to create API for let AT to work with
application GUI
- AT developers that are able to integrate their solutions using OS
Accessibility features and APIs.


Bob Regan:
I do not pretend to know the answer. However I suspect it will require, at a
minimum, a sober look at the cause and consequences of the individual
decisions underlying the issue. 

Roberto Scano:
Yes, but our decision should not be influenced by previous bad decision...

Cheers
Roberto Scano
Received on Saturday, 13 August 2005 17:28:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:39 GMT