- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 30 May 2000 19:05:24 -0400 (EDT)
- To: pjenkins@us.ibm.com
- cc: w3c-wai-gl@w3.org
I think Phill identifies the issues here fairly clearly, although I would note that hte question of what is a reasonable approach for the US might not work so well in other countries, where the markeyt for and range of assitive technologies is much more limited. We should bear this in mind if we are writing guidelines for a world wide web consortium. Charles McCN On Tue, 30 May 2000 pjenkins@us.ibm.com wrote: A similar discussion on JavaScript is occurring on the [Webwatch] list. I am interested in this GL thread because of the way the US Federal Government is using part of WCAG in section 508. Before I post this response to the [WEBWATCH] list, I will be following the feedback on this w3c-wai-gl thread.: From: webwatch@telelists.com Kelly wrote: > But if you > go the yes route, then you open up web pages to full blown Java applets, > Shockwave and a host of other technologies that haven't a chance of being > accessible any day soon. So how should legal standards of web > accessibility address this issue? Phill proposed response: I believe technologies such as JavaScript, Java, Shockwave, Flash, and/or formats such as .html, .mov, .pdf, .doc, etc. should have defined "accessibility standards" for each technology or format that will clearly delineate where the author responsibility lies and where the assistive technology responsibility lies. I believe there *are* industry recognized standards for HTML accessibility (see W3C WAI Web Content Accessibility Guidelines [1]), for browsers [read html players], (see W3C WAI User Agent Accessibility Guidelines [2]), and for Java applets (see IBM Java Accessibility Guidelines [3]). There are clear guidelines on how to add captions and descriptions to .mov's and the players that support them. What's missing. I do not know of any industry recognized accessibility standard for some technologies and formats, such as pdf, flash, and shockwave. I may be wrong about pdf - in that there may be some guidelines published on an Adobe site on how to make pdf accessible. To make the advancement of new technologies and formats viable - we should be supporting "legal standards" that request that "accessibility standards" be established for the new technology/format - as opposed to prohibiting the technology/format or as opposed to requiring a duplicate alternative format. Let me explain this last statement with JavaScript as an example. JavaScript is simply a scripting language that allows the page content to have some smarts and interactivity. For example, the running total in the ACB order form. Newer level screen readers working with newer level browsers provide good access to pages with JavaScript. Even self-voicing browser *should* be able to provide access to interactive content by supporting JavaScript. The Home Page Reader development team is working on this very problem. In my opinion it would be counter productive to "legally require" all pages that use JavaScript to also provide a non-JavaScript alternative. That would be like requiring all GUI applications to also provide a non-gui version because old DOS screen readers couldn't handle them. I am sure we may have all felt that way a decade ago, but we have made great strides in providing access to GUI applications. So why would we require all web sites to provide a non-JavaScript alternative when it would be less expensive and better to require assistive technologies to support JavaScript. JavaScript was invented to solve some real problems that could not be handled in HTML alone, just as GUI's were invented to solve problems in old DOS command line interfaces. In some cases it may be impossible to provide the same level of functionality using HTML without JavaScript - hence what we really want is "accessible JavaScript". [The thread on Webwatch was asking that since we do have "accessible JavaScript" on the Windows platform with certain versions of screen readers - then why should we encourage legislation like 508 that requires a duplicate alternative? ] So what do we do? I believe we should "label" technologies/formats as accessible or not depending on whether or not there are published industry standards for accessibility for that particular technology/format. In my opinion there is a problem with the current 508 standards and the W3C Web Content Accessibility Guidelines because they heavily burden the users of JavaScript by requiring a duplicate text/html alternative when there are clear standards for making HTML/JavaScript accessible. The expense of upgrading to the new "accessible technology" and the expense of upgrading my assistive technology to handle the new "accessible format" is a related, but really a separate issue, and more related to can I afford the computer, phone line, ISP, etc. to get connected to the Internet in the first place. There are plenty of older screen readers and computers that can't handle GUI's but we don't have legislation requiring duplicate text command line alternatives. So with civil rights and affordability aside for a moment, the industry/advocacy groups should establish whether the technology/format is fundamentally accessible or not. The WAI has done a good job with HTML, CSS, and SMIL. SUN and IBM have done a good job with Java, and Microsoft has a done a good job defining Windows application accessibility. We should demand "more good jobs" on technologies such as pdf, shockwave, flash, WAP, and VoiceXML etc. Perhaps we should be lobbying for more "legal" spending to establish accessible standards for newer technologies and advances in assistive technologies. Regards, Phill Jenkins, IBM Accessibility Center - Special Needs Systems 11501 Burnet Rd, Austin TX 78758 http://www.ibm.com/able [1] http://www.w3.org/TR/WAI-WEBCONTENT/ [2] http://www.w3.org/TR/UAAG/ [3] http://www.ibm.com/able/snsjavag.html -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053 Postal: GPO Box 2476V, Melbourne 3001, Australia
Received on Tuesday, 30 May 2000 19:05:25 UTC