- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 24 Aug 1999 19:45:23 -0400 (EDT)
- To: Marja-Riitta Koivunen <marja@w3.org>
- cc: WAI AU Guidelines <w3c-wai-au@w3.org>
Marja, thanks for the comments. I have noted my replies with CMN, and your original comments with MRK Note that I will send the proposals arising from these comments as separate messages to the authoring tools list for easier threading of further responses. Charles McCN On Tue, 24 Aug 1999, Marja-Riitta Koivunen wrote: 1. A seperate document, entitled Techniques for Authoring Tool ... - A separate ... CMN Aaargh! I'll check this word carefully throughout - I seem to have a very personal style for spelling it. MRK Guideline 1 - what is a compressed view of a document? An outline of headers? List of images, tables or links? Visual image of the whole doc shrinked to fit a window. A view which simplifies the structure for easy navigation. I think we should work out different wording. MRK 1.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions which are essential to accessibility, Priority 2 for those that are important to accessibility, Priority 3 for those that are beneficial to accessibility). - This is really vague. What are applicable? What if the standards or conventions conflict? What are essential etc? Are these going to be defined somewhere? Some that are listed in techniques are more usability than accessibility related guidelines like the Apple HIN guidelines. CMN The checkpoint leaves it to the authoring tool developer to know what standards are applicable to them - that is their job. In the techniques document we provide some standard references which are clearly applicable to certain platforms or situations, to help a developer who does not have any idea where to begin. The line between usability and accessibility is blurred - most usability features are not essential for accessibilty, but many of them are beneficial. The Apple guidelines cover issues which are clearly important or essential to accessibility for people with disabilities as well as ones which are only marginally beneficial to accessibility per se. MRK 1.3 Render an accessible equivalent of each element property. [Priority 1] - when user requests it (?) So I guess users should be able to turn on and off some properties such as images, audio etc. and render something else instead. CMN It is not required by this checkpoint that the accessible rendering can be turned on or off, just that it is available. Other checkpoints, such as 1.1 which requires following the User Agent guidelines for User Agent functionality of a tool, and 1.2, which requires that the editing view is not determined by the presentation suggested for a rendered view through markup, style sheets, etc, will mean that most effective implentations are likely to allow this type of control. MRK 1.5 Ensure the editing view allows navigation via the structure of the document. - techniques talk about element to element navigation as a minumum demand. Should we ask a little bit more? Go from header to header or link to link. What about search? CMN Further techniques are welcome, and your suggestions will be incorporated into the techniques document. The working group felt that this was a minimum requirement. Perhaps there is a lower priority requirement for further types of structural navigation, but it is difficult to express it in general terms. Remember that this document has a very broad scope. MRK 2.2 Ensure that content is created in accordance with a published standard - which standard/standards? W3C? I guess it is written in the document? CMN Any standard which is published is a published standard. The checkpoint before this one requires (but as a P2 rather than a P1) the use of applicable W3C standards in particular, but there are cases where there is no applicable W3C standard, and there is an accessibility benefit to using a standard which is published over one whose specification is unpublished, since in the latter case an assitive technology developer may not be able to develop appropriate ways to handle such content. MRK 2.3 Ensure that document markup language used enables accessibility of content. - 2.3 Ensure that the used document markup language enables ... CMN That is an unusual word order. MRK - would it be possible to use WAI schema enabling this if not otherwise possible? CMN If it is possible to use a schema to enable accessibility in the language, then the language can enable accessibility... MRK 3.1 Implement all accessible authoring practices that have been defined for the markup language(s) supported by the tool - Give support to all accessible authoring practices ... (?) CMN I propose: Support all accessible authoring practices... MRK 4. Including professionally written descriptions for all multimedia files (e.g., clip-art) packaged with the tool will: - This starts too soon. A little bit more context is needed e.g. Provide textual equivalents for all material provided by the tool. For instance, including ... CMN This phrase does not appear in the current (18 August) draft of the guidelines. The group agreed with you before you even asked *grin*. MRK 4.1 Prompt the author to provide alternative content (e.g., captions, expanded versions of acronyms, long descriptions of graphics). - it is important to do this so that the user is in control when annd how the prompts come and that they will not disturb the users work flow (similar to being prompted about the spelling errors while trying to write about ideas - better to let user start error checking or say it discreetly e.g. underline errors with red and whatever else is accessible but discreet). Maybe this can be said in the techniques, but it needs to be stated somewhere. CMN This is currently required in checkpoint 6.3, although that checkpoint is the last known issue (as of today) to be resolved, and is on the agenda for tomorrow. It is certainly mentioned in the techniques. I suggest that this checkpoiont (4.1) and checkpoint 6.1 be cross-linked, since they are related. MRK 4.2 Do not insert automatically generated (e.g., the filename) or place-holder (e.g., "image") equivalent text, except in cases where human-authored text has been written for an object whose function is known with certainty. - actually it could even support the use of the same text for the same icons or same navigation bar with the current selected item changing. That would add consistency to user. CMN This is provided for by checkpoints 4.3 and 4.4 MRK 5.2 Ensure that the highest-priority accessible authoring practices are among the most obvious and easily initiated by the author. - Ensure that the highest-priority accessible authoring practices are supported as the most obvious and easiest choice. CMN The group has considered both forms, and has settled on the latter. Do you wish to raise it as an issue? MRK 6.1 Check for and alert the author to accessibility problems. - ... about accessibility problems. - is this similar to 4.1? Do we need two places for this? CMN alert to is common usage as well. This is similar but not the same as 4.1, but I think we should cross reference them as noted above. MRK 6.4 Allow the author to override any removal of unrecognized markup. - the tool might even remember which parts have been accepted by the user aand which not CMN This would be a good technique. MRK 6.5 Provide the author with a summary of the document accessibility status on a configurable schedule. - don't understand the schedule part - is this like a work list that the author can easily go through at any point by clicking the items and solve the problems one at a time? CMN The schedule part is giving the author control over when the summary is provided. And yes, this is some kind of work list (although exactly what kind is left as an implementation decision. Note that this is a P3 requirement - it is not important to accessibility, but is beneficial. There is probably therefore less need to precisely specfy how it should be done). MRK 6.6 Allow the author to perform element transformations - does this mean that the original element disappears or these remain alternatives? CMN This would depend on the tool - some transformations are reversible, some are not. Checkpoint 3.4 already requires that in either case accessibility content is not lost. MRK 7.1 Integrate accessible authoring practices in all applicable help topics. - should there be a list of at least some topics that are expected to be there? CMN Some suggestions of the sort of things that are appropriate would be good for the techniques document MRK User Configurable Schedule - User Accessibility Preferences? Schedule sounds a bit funny to my ear. CMN Whatever phrase we use is going to sound a little funny and require definition MRK --- - at some points a would have hoped a clearer statement that this applies to the tool and this to its output - but mostly it was OK CMN In general, checkpoints in guideline 1 apply to the accessibility of the tool, and checkpoints in other sections apply to the accessibility of the content generated. There is a small degree of crossover in a couple of checkpoints - we have attempted to ensure that the requirements are met in both aspects, without trying to artificially restrict the language of the checkpoint. MRK - at least the navigation and orientation points would be good to check with the UA guidelines - they should be alike CMN In cases where the authoring tool is also a user agent the user agent guidelines are applicable - see checkpoint 1.1 In other cases the requirements for navigation are not necessarily the same, and guideline 1 needs to cover those (and only those) requirements which are particular to an authoring tool irrespective of whether or not it is a user agent. --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 Tuesday, 24 August 1999 19:45:24 UTC