- From: Cynthia Shelly <cyns@exchange.microsoft.com>
- Date: Thu, 14 Sep 2006 12:09:03 -0700
- To: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
- Message-ID: <EC00246575819245B066C20F77051F2919688E3698@df-whippet-msg.exchange.corp.microso>
Before I launch into criteria for acceptable baseline technologies, I'd like to step back and discuss the goals of the baseline concept. WCAG 1.0 was based on an assumed baseline of HTML and CSS, which was common when the standard was released. This baseline was outdated quite quickly, and it became difficult to create advanced, innovative web products which also conformed to WCAG 1.0, even when those products were designed to be accessible and proven to be accessible in practice. So, the goal of baseline is to separate the requirements from the technology. Why is this important? * It allow sites to make use of new technologies quickly, as long as those technologies can be used in an accessible manner * It encourages developers of new technologies to support accessibility features * It creates an environment where accessibility can be a competitive advantage * It encourages innovation in the space of accessible web content creation * It gets around the argument, that we've all heard so many times, that accessibility hinders creativity and technological advancement. So, I propose replacing the requirement that policy makers set baseline with rules for development organizations that wish to create their own. This does not mean that all authors should set their own, or that we shouldn't provide some common ones for people to work with. It does, however, mean that those who are pushing technological limits and trying to innovate while maintaining accessibility have a way to do that. <proposal> Only accessibility-enabled technologies should be included in a baseline. Accessibility-enabled technologies meet the following criteria: 1. The technology is supported by Assistive Technology (AT). One or more of the following is true: a. The technology implements Accessibility APIs that are supported by a wide range of Assistive Technology. b. The technology has been tested for interoperability with market-leading Assistive Technology in the natural language or languages of the content. 2. The technology is available to the intended audience. One or more of the following is true: a. The technology is part of a recognized industry standard. [I think we need an implementation test here too] b. The technology supported natively in widely distributed user agents. Examples: HTML, frames, CSS, JavaScript c. The technology available in a widely distributed plug-in. Examples: PDF, Flash [need some non-Adobe examples] d. You're working in a closed environment, such as a university or corporate network, where you know that the software required by the technology is installed on all the machines. e. You make the technology available for download or purchase in a way that does not disadvantage people with disabilities. * * NOTE: using a technology in your baseline that isn't widely distributed isn't necessarily an accessibility issue, as long as the process for getting the technology does not disadvantage users with disabilities. For example, if you require users to download your plug-in in order to view content, as long as the download can be completed with Assistive Technology, and the plug-in interoperates with Assistive Technology, the technology can be part of your baseline. </proposal> What happens if the technology is not available to a particular user? This is covered under 4.2.2 (level 1) and 4.2.4 (level 3). Perhaps we should add a situation to 4.2.2 that covers making the download mechanism accessible? As content on the page, it would be required to conform anyway, but I think it might be useful to call it out specifically.
Received on Thursday, 14 September 2006 19:10:00 UTC