W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 1999

Comments to AU guidelines

From: Marja-Riitta Koivunen <marja@w3.org>
Date: Tue, 24 Aug 1999 18:26:09 -0400
Message-Id: <3.0.5.32.19990824182609.00a13580@localhost>
To: charles@w3.org, w3t-wai@w3.org, w3c-wai-au@w3.org
Great work!

Here are some comments.

Marja

------------
1.

A seperate document, entitled Techniques for Authoring Tool ...

- A separate ...

2.

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.

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.

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.

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?

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?

2.3 Ensure that document markup language used enables accessibility of
content. 

- 2.3 Ensure that the used document markup language enables ...
- would it be possible to use WAI schema enabling this if not otherwise
possible?

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 ... (?)

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 ...

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.

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.

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.

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?

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

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?

6.6 Allow the author to perform element transformations

- does this mean that the original element disappears or these remain
alternatives?

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?

User Configurable Schedule

- User Accessibility Preferences? Schedule sounds a bit funny to my ear.

---
- 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

- at least the navigation and orientation points would be good to check
with the UA guidelines - they should be alike
Received on Tuesday, 24 August 1999 18:28:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC