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