- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Fri, 24 Mar 2006 09:38:37 -0500
- To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>
Hi everyone, Greg sent this to the list prior to Monday's call but it did not get through. However, it did play a role in Monday's discussion so I am sending it now for archival purposes: -------- Original Message -------- Subject: My homwork for today's concall Date: Mon, 20 Mar 2006 11:55:01 -0800 From: Greg Pisocky <gpisocky@adobe.com> To: Jan Richards <jan.richards@utoronto.ca> On the last call I was assigned review of B.2.4 (see message: http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0032.html). In the Guidelines: http://www.w3.org/WAI/AU/2005/WD-ATAG20-20051216/WD-ATAG20-20051216.html #check-no-default-alt B.2.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1] 1) Wording: insert the words "providing a mechanism for author confirmation" between the words "without" and "author". The checkpoint would now read: B.2.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without providing a mechanism for author confirmation, except when the function is known with certainty. [Priority 1] . This checkpoint appears to be inspired by Checkpoint B.2.2, Check for and inform the author of accessibility problems. [Relative Priority] It's easy to automate a process that detects whether or not a required item is present, but even then,users may resent being constantly reminded figures are missing alternative text since at some stage in the workflow the author may not be ready to assign the missing value. Providing a mechanism which authors could activate at the appropriate moment in the workflow seems to be the answer. I advocate this change to our approach for verifying previously generated alternative items (whether through some automated process or as a result of previous assignment) to reduce similar annoyances. Checking as to whether or not previously assigned alternative is a appropriate is a more difficult process to automate than say detecting for the presence of a required item. Here the item may be present, but the value assigned to it may not be appropriate - requiring manual intervention to verify that indeed the alternative is proper and accurate. However, who is the author? Whose job is it to assign alternative equivalents. That's not always clear especially in collaborative workflows, so requiring the individual who may be responsible for generating code to be distracted by alerts asking to verify the appropriateness of alternative text equivalents made by the art director would be an intrusion and make the authoring tool undesireable for use in collaborative situations. How often will someone be required to verify a choice previously made? And how many times can you do that until it becomes annoying as well as intrusive? Automatically generated equivalent alternatives, especially if generated without the author's awareness, certainly merit human intervention, but even then, how many times does an author have to assure the software that, indeed he or she is satisfied with the choice made by the automated system? Previous indicates a moment in time, thus for a work in process, previously authored alternatives are those created yesterday for example. It would be an annoyance and a burden to constantly be asked to confirm decisions that were consciously made at a "previous" moment in time through a dialog box or alert that's always asking users to confirm satisfaction with automatically generated or previously authored alternatives. However, having a mechanism where the previously authored or automatically generated alternative can be readiliy determined and verified would seem to solve this problem. Authors should not be required to constantly confirm decisions that have been previously made and verified through an intrusive reminder.) Rationale: Improperly generated equivalent alternatives can create accessibility problems and interfere with accessibility checking. The rationale is fine. Techniques: Implementation Techniques for Checkpoint B.2.4 Success Criteria: 1.The tool must never use automatically generated equivalent alternatives for a non-text object (e.g. a short text label generated from the file name of the object). Like it or not, automatically generated items from databases and such are going to be employed in the real world as labor saving mechanisms. Image libraries with associated alternative text equivalents will be drawn upon to provide graphic content to web pages. I would not mandate against the use of such mechanisms. Rather I would change this success criteria to read 2. When a previously authored equivalent alternative is available (i.e. created by the author, pre-authored content developer, etc.), the tool must prompt the author to confirm insertion of the equivalent unless the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.) It strikes me that it shouldn't matter whether the alternative equivalent is automatically generated or previously authored in some manual fashion, the point of the exercise is to provide a mechanism that allows someone (not necessarily the "author") to verify the appropiateness of the alternative equivalent and change it if necessary. I don't think we should make it a feature of the authoring tool to determine at what point in the workflow such a review should take place. Therefore I propose the following: Revised Success Criteria: 1. The tool should provide a mechanism for users to examine and accept, change, or reject equivalent alternatives that have been assigned to non-text elements. 2. The tool should provide an alterntive equivalent review mode that would allow users to "step through" alternative equivalents in the content and accept, change, or reject equivalent alternatives that have been assigned to non-text elements. Greg Pisocky
Received on Friday, 24 March 2006 14:39:20 UTC