- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Mon, 25 Jun 2012 00:34:52 -0500
- To: "Bailey, Bruce" <Bailey@Access-Board.gov>
- Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-id: <17A9AE23-2D9B-4E7F-99EE-14509BB4A6BB@trace.wisc.edu>
Hi Bruce See below. marked GV: Gregg -------------------------------------------------------- Gregg Vanderheiden Ph.D. On Jun 22, 2012, at 6:46 AM, Bailey, Bruce wrote: >> In the meantime one COULD argue that AT can be assumed to meet it [1.4.3 Contrast (minimum)]. > > This is why I characterized my argument as a reductio ad absurdum. IMHO it is the peak of hypocrisy for the WG to countenance such an assertion. If a site author put forth such an claim (with regard to their poor contrast site) they would be met with derision. GV: Bruce I think you are missing a key aspect of WCAG 1) The whole WCAG is based on outcome rather than process. This allows the WCAG to be able to stay relevant as technologies change. What may have to be done by authors today, may be automatically (or on user request) done by browsers or assistive technologies in the future. As a result assistive technologies (and access features in mainstream user agents) can be used to meet any of the success criteria. 2) Assistive technologies can only be used however when there is accessibility support. This means that whatever technique you are relying on is supported by the assistive technology(s) (and access features in mainstream user agents) that users have. If the users of your site will not reasonably have those technologies then that approach should not be used. You will find notes in our understanding document that discuss the fact that what you can rely on in a companies intranet may be different than what you can rely on users having in the open Web for example. If the users who need high contrast can not reasonably be assumed to have any assistive technology, then one should not rely on them having assistive technology in order to meet the success criterion. In creating WCAG we stated that accessibility support required that the technique being considered the supported by users AT. But we did not specify who the users were. This move beyond defining what constitutes accessibility and into the range of each how far-reaching the application should be. That is, it would reach into the regulatory realm. As noted above, the problem you have with 1.4.3 only exists if it was considered a valid assumption that everyone who needs high contrast would have assistive technology that could do this. Today I would not be a viable assumption. However, if that capability built into every browser, then it clearly would be. (This is of course a nontrivial problem for images and text but it should be solvable without too much effort.) When (and only when) this occurs, there should no longer be a requirement on authors to worry about this item. That is how it should be. That is how WCAG closely is designed to work. > > I will skip over the other stuff an just focus on the most obvious point: 1.4.3 Contrast (minimum) and 1.4.4 Resize text are structured the same and can be mitigated with the same type of assistive technology (screen magnification, which has been available for 20 years) but 1.4.4 has the explicit phrase "without assistive technology". I contend that this constraint is implicit with all the other SC, but, for the moment, please let us consider this just in the context of 1.4.3. GV: see above. > > If your position on this correct (that one can reasonably assume the presence of AT to meet 1.4.3 Contrast (minimum)), I have a couple questions for you that I don't think you can provide good answers for: > > Why did we include the contrast provisions? They were highly contentions and we spent a great of time of them. All of which would have been obviously moot with the observation that AT solved the problem. GV: I don't understand your question. The reason we included contrast is because it's very important. And as you can see from about it is not at all moot. > > If AT can be used to satisfy SC, why do we not have *any* sufficient technique examples of this? GV: We don't have any sufficient techniques involving AT listed for contrast because they would not always be sufficient. They would only be sufficient in certain circumstances. GV: We do have examples of sufficient techniques involving access features built into user agents. For example we list zoom feature in browsers as being sufficient for the success criterion related to text size. We don't list one for contrast because there is not an assistive technology or access feature in browsers that can handle this that one could assume that all users who needed it have. > As you note, 1.4.3 can be particularly constraining for authors, so why in particular do we not have an AT-oriented sufficient technique for this SC? GV: see just above > We have been developing sufficient techniques for a while, so what possible explanation is there for this rather obvious omission other than the WG does not think add-on AT can be relied upon? GV: see above Is this clearer now? Gregg > >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 25 June 2012 05:35:25 UTC