RE: R: NEW: Issue #1544

Hi Bob,
I could agree with you but at now, if we talk about "web content
accessibility", this means not only in Windows + IE + Screen reader but
means also with other OS and with other browsers.
I can agree with you that the most accessible OS is Windows and that Windows
has developed first API for accessibility, but when we talk about web
content we need to evalutate them also with other OS and with other
browser/AT. You know best than me that some products lead the market but if
we want to grant "accessibility for all" we need to evalutate well what old
WCAG require. Otherwise, if you have an object that is accessible only with
Windows + IE + Jaws  and want to put a WCAG 1.0 conformance logo you should
put it and show it only if the browser is IE, if the OS is Windows and if
recognize use of JAWS.
But this become impossible, so impossible is to said that a web content is
accessible if rendered/usable by a single OS, a single Browser, two-three
AT.
 

-----Original Message-----
From: Bob Regan [mailto:bregan@macromedia.com] 
Sent: Saturday, August 13, 2005 8:05 PM
To: w3c-wai-gl@w3.org
Cc: Andrew Kirkpatrick; Roberto Scano - IWA/HWG
Subject: RE: R: NEW: Issue #1544


Roberto, 

Thanks for the list of links. I know these documents well. I am just not
interpreting them in the same way. 

We're in a bit of a circular conversation here. You raised the issue in an
earlier example when you pointed to Flash rendering in a variety of
browsers. However, the issue at hand is that screen reader users accessing
Flash content. I am not trying to reduce accessibility to screen reader
users. However, this is an important use case. 

While I do not have precise numbers but I think we can agree that the
overwhelming majority of screen reader users are today on Windows using IE.
While the good work we've seen recently at Apple, Sun and Mozilla will
change this over time, it remains the case today. 

I do not think we have reached a threshold where <embed> has created an
issue for people with other disabilities. Of course, accessibility should be
defined to support the broadest number of possibilities. There is no
inconsistency here. I fail to see your point there. 

The point again is one of discourse versus dictation. You are assuming that
all decisions to support are not support that are not made by you represent
'bad decisions'. 

Here is one real world scenario. If we look at the list of proposed projects
in front of a screen reader maker today, from new operating systems coming
soon, to support for new browsers, to support for javascript, to support for
CSS, to support for media players and plugins, to changing the way the
<object> and <embed> tags are handled. Whenever I get frustrated with an AT
vendor not adhering to my logic, I try to think of my friend Doug who runs
an AT company. He has this massive list of changes to make each release. He
has a small staff and limited budget to accomplish this. He has to make
choices in every release. Getting frustrated with Doug is a very hard thing
for me to do. I know for certain I could not do as well as he does with each
release. If it is hard for Doug, it is hard for everyone. 

There is an arrogance is dictating terms in these situations. As smart as
well all are, it is hard to know the day to day challenges of the folks who
build the AT, the authoring tools, and the browsers. I am not suggesting
tool makers always should get off the hook for standards. I am suggesting
that an approach that ignores the challenges of tools makers, especially
assistive technology makers is ill conceived and seriously risks
irrelevance. 

I think I have made my point. We can continue this off line if you wish.
Unfortunately, I have a release to get out the door. 

Cheers,
Bob


------------------------------------------------------------------------
-
bob regan | macromedia | 415.832.5305






-----Original Message-----
From: Roberto Scano - IWA/HWG [mailto:rscano@iwa-italy.org] 
Sent: Saturday, August 13, 2005 10:28 AM
To: Bob Regan; w3c-wai-gl@w3.org
Cc: Andrew Kirkpatrick
Subject: RE: R: NEW: Issue #1544



-----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 18:28:15 UTC