- From: mark novak <menovak@facstaff.wisc.edu>
- Date: Mon, 16 Apr 2001 13:52:40 -0500
- To: Ian Jacobs <ij@w3.org>, Denis Anson <danson@miseri.edu>
- Cc: w3c-wai-ua@w3.org
hi Ian, Denis and all: At 10:12 AM 4/14/01, Ian Jacobs wrote: >Denis Anson wrote: >> >> Ian, >> >> The only weakness of this checkpoint that I see is the law of unintended >> consequences: You don't always know how a change affects accessibility. >> Certainly, we want to know how you have improved accessibility, but would >> any developer deliberately decrease access? Changes in that direction would >> be inadvertant, and probably not known. >> >> I'm pretty sure, for example, that when IE 4.0 was released, it wasn't >> deliberate that it broke access. >> >> So, if a developer did something that changed access accidentally, would the >> developer lose conformance when a user contested this? > >I don't think so. I would apply the concept of "recognize" to >humans here: if you know that if affects accessibility, you document >it. If you don't, then you don't. > >Of course, people can lie, but I don't think any document we write >can protect us against that. > >I agree that this checkpoint is hard to verify (as many others >are in our document) and impossible to automate. for this an "other reasons", is there a chance that you could enhance the current defintion of "documentation", such that it might even include a bullet list (e.g., like AT does), and then Guideline 12 could be simplified to perhaps "one" priority one checkpoint? mark > > _ Ian > > >> Denis >> >> -----Original Message----- >> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On >> Behalf Of Ian Jacobs >> Sent: Friday, April 13, 2001 8:21 PM >> To: w3c-wai-ua@w3.org >> Subject: [Editorial] Proposed clarification to checkpoint 12.5 >> (documentation of changes that affect accessibility) >> >> Hello, >> >> In the 9 April draft [1], checkpoint 12.5 reads: >> >> "12.5 In each software release, document all changes that >> affect accessibility." >> >> I think this checkpoint is could be interpreted as making >> a requirement that spans more than one release of a user >> agent. This would make conformance for a specific release >> of a user agent impossible. >> >> Instead, I propose the following language, which I consider >> an editorial clarification: >> >> "12.5 Document all changes from the previous version >> of the user agent that affect accessibility." >> >> Comments: >> >> - The term "release" has been replaced by "version", which >> is the term used in the section on conformance. >> >> _ Ian >> >> [1] http://www.w3.org/TR/2001/WD-UAAG10-20010409/ >> -- >> Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >> Tel: +1 831 457-2842 >> Cell: +1 917 450-8783 > >-- >Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >Tel: +1 831 457-2842 >Cell: +1 917 450-8783
Received on Monday, 16 April 2001 14:48:34 UTC