- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Tue, 16 Sep 2003 16:13:37 -0400
- To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>
================================================================== ACTION ITEM: Look into removing "likely" from success criteria. ================================================================== Only used in success criteria for 4.1, as follows: WAS: 1. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them must be available to the author at all times during authoring and, at most, one level down in the user interface (e.g. in the first level of a drop-down menu). 2. The configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functions must be designed so that typical authors searching for the configuration mechanism will be LIKELY to find it and that typical authors performing general configuration tasks will be LIKELY to notice the configuration mechanism. 3. When these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), the y must be designed so that typical authors searching for the function will be LIKELY to find it and that typical authors performing other general purpose tasks will be LIKELY to notice the function. PROPOSAL: 1. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them must be available to the author at all times during authoring and, at most, one level down in the user interface (e.g. in the first level of a drop-down menu). 2. The configuration controls for these accessibility-related functions must be a full part of a general configuration area, if one exists. 3. If no general configuration area exists, the configuration controls for these accessibility-related functions must be handled in the same manner as configuration controls for other functions. 4. When these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), the resulting design must include the accessibility-related controls in the highest level of the combined user interface. ================================================================== ACTION ITEM: Look into a "usability over-ride" for success criteria (for checkpoints in Guideline 4) ================================================================== PROPOSAL: 4.1 Usability Study Alternative to Success Criteria: When prompted to find them, typical authors are able to locate accessibility-related prompting, checking, repair functions and documentation from several representative states of the tool. 4.2 Usability Study Alternative to Success Criteria: When prompted to perform an authoring task, typical authors tend to locate the more accessible means, provided by the tool, for accomplishing that task. 4.3 Usability Study Alternative to Success Criteria: When prompted to guess which features in a tool are designed by a "third party developer", typical authors do not tend to identify accessibility-related prompting, checking, repair functions and documentation any more frequently than other features of the tool. -- Jan Richards, User Interface Design Specialist Adaptive Technology Resource Centre (ATRC), University of Toronto Email: jan.richards@utoronto.ca Web: http://ultrajuan.ic.utoronto.ca/jan/richards.html Phone: 416-946-7060 Fax: 416-971-2896
Received on Tuesday, 16 September 2003 16:13:30 UTC