- From: <gian@stanleymilford.com.au>
- Date: Fri, 8 Feb 2002 09:48:01 +1100
- TO: cyns@microsoft.com, mcmay@bestkungfu.com, w3c-wai-gl@w3.org
- Message-Id: <H00000e00037bf71.1013122081.tux.sofcom.com.au@MHS>
Yes I agree with your analogy, however I believe that a person who is paraplegic is expected to get a wheelchair if they want to move around, just like someone who is blind is expected to get a screen-reader if they want to browse online. There are some real accessibility reasons as to why some people cannot access the technology described below. Not because they can't be bothered, or even because they don't have the money, but real disability-specific reasons. Gian -----Original Message----- From: cyns [mailto:cyns@microsoft.com] Sent: Friday, 8 February 2002 8:15 AM To: Gian Sampson-Wild; mcmay; w3c-wai-gl Subject: RE: Checkpoint 4.4 Review Users still have some responsibility for their own tools. Allow me to draw a physical-world analogy... Existing physical-world regulations require that a mobility-impaired user be able to get into my building in a wheelchair. They do not require that he be able to get in *without* one. Should every person who needs a wheelchair have one? Absolutely. Does every person who needs a wheelchair have one? Probably not. Does that suck? You bet. Is it the responsibility of every building owner to fix it? I don't think so. It would be inefficient and ineffective for every building-owner to address this issue. The user (and various agencies that represent him) has the responsibility to supply the wheelchair, find funding for it, and maintain it. The building owner's responsibility ends at adding a ramp, so that once a user has a wheelchair he can access the building. It is our job to decide what is the wheelchair and what is the ramp. I would like to see this on the agenda for a call (or even the f2f?) once we have finished with the success criteria. I will be happy to write up a proposal to start with. -----Original Message----- From: gian@stanleymilford.com.au [mailto:gian@stanleymilford.com.au] Sent: Wednesday, February 06, 2002 3:32 PM To: mcmay@bestkungfu.com; w3c-wai-gl@w3.org Subject: RE: Checkpoint 4.4 Review Inflexibility is one thing, but while playing the political game we can't forget why we are doing this in the first place. In the long run, if these things are a problem for people with disabilities then we need to deal with them in the guidelines, otherwise WCAG will turn into just one more irrelevant document that pays lip service to the real problems people with disabilities face. -----Original Message----- From: mcmay [mailto:mcmay@bestkungfu.com] Sent: Thursday, 7 February 2002 10:27 AM To: w3c-wai-gl Subject: Re: Checkpoint 4.4 Review Someone correct me if I'm wrong, but wasn't the appearance of inflexibility with respect to technology one of the major complaints about WCAG 1? A definition this harsh makes WCAG irrelevant, because no one will take it seriously. A checkpoint already exists to require that sites be usable when technologies aren't available. We don't need to resort to requiring content providers to write on stone tablets. ----- Original Message ----- From: <gian@stanleymilford.com.au> To: <charles@w3.org>; <w3c-wai-gl@w3.org> Sent: Wednesday, February 06, 2002 3:04 PM Subject: RE: Checkpoint 4.4 Review My perspective on all of this has been that the content and functionality of the site must remain in a baseline browser- HTML only. No images, no CSS, no plugins, no PDFs, no java, no Flash. Regardless of how 'widely available' these addins are there will always be some people not using them (except maybe in 20 years time when ALL browsers come packaged with Adobe Acrobat and have been for the previous five years). People who are blind cannot see images People who use screen-readers often cannot navigate a flash screen People without Acrobat cannot read PDFs (I do not believe the PDF converter is of sufficient capability to render a document readable) People without Word cannot read doc files People using Lynx cannot use java People with vision impairments do not use CSS The people we aim to serve have trouble with all these addins. We can't assume anything is available to them. But I do believe we need to close the issue on baseline capabilities. And whatever conclusion we come to as a group needs to be very clearly stated in the guidelines. My feeling is baseline is pure HTML. Gian -----Original Message----- From: charles [mailto:charles@w3.org] Sent: Wednesday, 6 February 2002 10:26 PM To: GV Cc: w3c-wai-gl Subject: Re: Checkpoint 4.4 Review comments on Gregg's analysis: 1. We need to determine (close the issue about) what are the expected baseline capabilities of a browser. HTML? Images? SVG? CSS? ... This never seems like it will be easy. But until we have done it, I think we are not going to be able to finish the guidelines. I also still believe that the ideal goal would be to agree on how to decide when a technology (HTML / PDF / Flash / .doc format / whatever) is sufficiently widely available, and then to use those criteria to decide what things we expect of a browser today. 2. If we had a way of saying "the information presented by a document" which was clearly different from "all the things in a document" it would be helpful. cheers chaals On Wed, 6 Feb 2002, Gregg Vanderheiden wrote: 1 - I think the checkpoint could be worded more straightforwardly. Perhaps Checkpoint 4.4 -- Ensure that content is usable with default user agent settings and no plug-ins. 2 - I don't know how an author can do this since we don't specify which user agent. Any user agent? All user agents? 3 - default for some user agents includes many 'plug in' like properties. Also style sheets are usually turned on. (See related comment in checkpoint text below). 4 - the success criteria is pretty good, but should say that all the function is preserved. The word "content" is ambiguous to some. Maybe the phrase "all content and function" would work. 5 - the success criteria is not the same as the checkpoint. It suggests that the checkpoint should be Checkpoint 4.4 Ensure that all content is readable and all function (other than artistic) is preserved when stylistic and scripting technologies are not supported or are turned off. [The success criteria would then be pretty much the same as the checkpoint. But that isn't bad.] 6 - Example 2 needs to have some words at the end like: "while preserving all content and functionality of the pages". Example 3 - the last sentence should be deleted or changed to: "This benefits those with older browsers and new and old assistive technologies" ================================================== Checkpoint 4.4 Ensure that content remains usable when technologies that modify default user agent processing or behavior are turned off or not supported. Issue: define "default" for purposes of this checkpoint. If "default" were taken to mean "a user agent's default rendering", then this would defeat the purpose of the checkpoint, because (for many user agents) the default is to apply style sheets, invoke scripts and programmatic objects, etc. Success criteria You will have successfully ensured that content remains usable when technologies that modify default user agent processing or behavior are turned off or not supported if: * for technologies that associate presentation with structure, the content is still usable and readable by the user even if stylistic or scripting technologies are not supported or turned off. Examples (informative) * Example 1: Metadata. A scalable image of the layout of a network uses metadata to label each piece of the network and how they connect to each other. The metadata can be used to create a text description of the network. * Example 2: A transformation filter. A Web site provides a transformation filter that allows users to design how they will interact with the layout of the content on the site - with or without images, with or without tables, etc. * Example 3: Human resources intranet site. The human resources department for a large company provides multiple versions of the same content to ensure backwards compatibility with older browsers. The IT department is not large enough to update everyone's browsers and assistive technologies so many people make do with older technologies. Benefits (informative) In determining the extent to which older technologies should be supported, keep in mind that * assistive hardware and software are often slow to adapt to technical advances. * for significant groups of users, it may not be possible to obtain the latest software or the hardware required to operate it. -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Human Factors Dept of Ind. Engr. - U of Wis. Director - Trace R & D Center Gv@trace.wisc.edu < <mailto:Gv@trace.wisc.edu> mailto:Gv@trace.wisc.edu>, < <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848 For a list of our listserves send "lists" to listproc@trace.wisc.edu < <mailto:listproc@trace.wisc.edu> mailto:listproc@trace.wisc.edu> -- Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Thursday, 7 February 2002 17:50:12 UTC