- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 29 Mar 1999 13:00:25 -0500 (EST)
- To: Lauren Wood <lauren@sqwest.bc.ca>
- cc: w3c-wai-au@w3.org
Lauren's comments marked LW: Mine marked CMN: On Fri, 26 Mar 1999, Lauren Wood wrote: I will start by admitting that I haven't been following the mailing list for some time, which means I'm reading this from a fresh perspective of someone who has implemented some accessibility features in an authoring tool already. I think the present draft has come a long way from a previous version that I read some time ago. I still have a few comments though. Definition of Technique: the DOM is not a language; perhaps this could be written as "an implementation ... in a given way" or "using particular methods". CMN: I suggest an editorial amendment clarifying the scope of a technique along the lines proposed. LW: Spell-checking! I noticed "seperate", "accessibile", and others. CMN: Woops. I had not spellchecked the final pass document, but it did get done later. LW: checkpoint 2.1.2: does "extensions" here apply to company-proprietary extensions, or extensions made by other W3C WGs, or what? Please specify better. CMN: Applies to non-W3C extensions - many authoring tools produce markup based on a proprietary DTD. I suggest we clarify text as follows: Ensure that extensions made to W3C specifications (eg in a proprietary DTD) do not reduce accessibility. In addition, explanation should be added in the techniques. LW: checkpoint 2.2.3: define what you mean by "templates" here - there are so many meanings. CMN: Agree. Any suggestions anyone? LW: 2.3.5: I think there's a "not" missing before the "known with certainty". CMN: This checkpoint clearly needs to be worded more carefully LW: Techniques in 2.3: what does "Default to an accessibility error such as no 'alt' attribute for images" mean???? CMN: It means that where no alt text is provided, and a null option is not explicitly selected, the defualt should be to leave out ALT text - this will be flagged as an accessibility error. Should be made clearer in the document. LW: 2.7.4 is graded as priority 3 - I think explaining universal benefits is going to be the best way of getting people to actually write accessible pages. Otherwise the temptation is to simply turn off those pesky dialog boxes and not bother. So maybe a priority 2? Chapter 3: I always thought that authoring tools were encompassed under the phrase "user agent". Is that not true? If not, what is the actual definition of a user agent, and which bits of it exclude authoring tools? CMN: As used within WAI, User Agent is a reading/browsing tool. An Authoring Tool is a reading (and often browsing) tool, but which provides further funtionality. And in some cases the reading/browsing functionality is extremely limited. LW: I would also suggest something else that can be added to this section: an authoring tool that works with 3rd-party tools that make the authoring tool accessible. For example, an authoring tool that can be used with a speech reader, or an authoring tool that supports scripting so that add-ons to help accessibility of the tool can be written. This is more applicable to section 3.3 and 3.4 than 3.1 or 3.2, of course. CMN: Providing programmatic interfaces so that Screen Readers, special purpose scripts, etc can be used to enhance accessibility is meant to be covered by 3.1 Should we make it more explicit? LW: Guideline 3.2: the first sentence doesn't make sense to me. It helps if I delete the word "it" after "wish", but it's still unclear. 3.2.1: should the first "of" be "is"? CMN: Yes and yes. A bit of editorial cleaning will be done. LW: 3.3: This is where APIs such as the DOM come in. When used internally to an authoring tool, the DOM can enable the writing of separate applications that use that DOM interface to get the information from the document and pass it to the author. Then the author can pass information back about what they want to do to the authoring tool via the DOM. 3.4: Similarly here, an authoring tool that supports the DOM can represent elements graphically and still give an author a way of translating the content to Braille etc. So for 3.3 and 3.4 it's important that the authoring tool make this possible, but the authoring tool doesn't need to implement everything itself, if it supports some way of adding the necessary functionality. I admit this means that people needing the accessibility features will then often need to do some programming, or find 3rd-party add-ons that work, but this system would also be more flexible to particular needs of different groups. CMN: This is meant to be covered by 3.1 - implementing DOM and an interface to it is a standard way to provide access to documents. Perhaps we should make it more explicit. The question of native implementation vs requirements for interfaces hasn't been addressed yet. LW: 3.4.1: define "properties" better CMN: I'll link it to the definition LW: 3.4.2: site maps? What site maps? Shouldn't this say "if extra information, such as site maps, is available, there must be a way to get this in text form"? (Or similar; again, the authoring tool doesn't have to do the text representation itself if it can make that information available, IMO). CMN: This could do with clarification. LW: I hope this helps and isn't rehashing old issues. If so, I'll understand if you ignore every word I've written (apart from fixing those spelling mistakes....) regards, Lauren CMN: Lauren, thanks for the comments - lots of food for thought. The editorial issues will all be worked through preparing the public draft. I hope the working group can address the other issues in time for that draft as well - we'll give them our best shot. Charles --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://www.w3.org/People/Charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Monday, 29 March 1999 13:00:32 UTC