- From: Greg Lowney <greglo@microsoft.com>
- Date: Tue, 23 Nov 1999 23:00:44 -0800
- To: w3c-wai-au@w3.org
Hello All, Overall I want to say that I am extremely impressed with the current state of the guidelines document. I consider the background and explanations very clear, especially for their brevity, and the guidelines themselves very reasonable even though they represent a high standard for mainstream tools. I did want to give you my thoughts of five issues. None of these comments are show stoppers, just suggestions. Please forgive me if you've already discussed these issues at length or if it's too late to address them effectively. (1) 1.3, "Ensure that the tool generates..." This and similar phrases are used similar in several places. I don't feel it is made clear whether the authoring tool is required to support these in its default configuration, or whether this can be a non-default option available on demand. For example, if the user *can* generate content that conforms to the WAI-WEBCONTENT Priority 1 guidelines, but it does not happen by default, does that mean the authoring tool conforms to guideline 1.3? If it was extremely difficult, involving manually editing the HTML, does that still count, or is there some objective or subjective limit on the inconvenience? This same issue applies to several other guidelines, such as 1.2, 2.2, 4.3, etc. (2) 4.3, "Allow the author to preserve markup not recognized by the tool", This is currently priority 2 but I might rate it as priority 1 given that we don't clearly define the minimum set of elements and attributes that we expect any conforming tool to recognize. This means, in theory, that a tool could strip out all ALT attributes and all LABEL elements and still qualify for A-Level conformance. In effect the current priority rating seems to contradict the rating on other guidelines such as 1.2 that say the tool must preserve all accessibility information. (3) 7.3, "Allow the author to edit all properties of each element and object in accessible fashion." This seems out of place to me not because it's unimportant, but because it is merely one example of what I see as a very general rule. Authors should be able to do this, and they should also be able to do other tasks that we might take for granted, such as being able to insert a new element. If the need to let authors do that in an accessible fashion is self-evident or implied by 7.1, then it seems that 7.3 is unnecessary. Conversely, if 7.3 is not implied then I expect we really should have a number of additional, similiar requirements. (4) 7.4, "Ensure the editing view allows navigation via the structure" is currently priority 1 but I consider it to be more of a priority 2 or 3. Some word processors don't provide structured navigation, and I consider that to reduce their usability and accessibility but not to make them inaccessible. In our guidelines for Windows-based applications, I would list this as something that is beneficial to meeting accessibility goals but is not critical; in other words, a recommendation rather than a requirement. (5) 7.1, "Use all applicable operating system and accessibility standards and conventions". I know there has been a lot of discussion of this, so I won't comment at length, but I'm curious whether the reference to operating system standards means, for example, that an authoring tool running on Windows needs to be usable with the keyboard but the same tool running on Macintosh does not. Or, on the other hand, does the reference to accessibility standards mean that a tool running on the Macintosh needs to provide better keyboard access than is commonly found on that platform? I also looked over the Techniques document briefly, but it does not seem nearly as polished as the Guidelines themselves. I felt it could benefit from clearer prioritization, pros and cons, or recommendations to help developers choose between the various techniques listed for each checkpoint. It might would also help to distinguish the bullets that suggest individual techniques vs. bullets that list resources vs. bullets that offer critiques of what specific products do today (e.g. Guideline 1.1 bullets 1-3, 4-6, and 7-10 respectively). Thanks, Greg Lowney
Received on Wednesday, 24 November 1999 02:01:19 UTC