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:05:06 UTC