W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2006

Homework for today's concall (from Greg P)

From: Jan Richards <jan.richards@utoronto.ca>
Date: Fri, 24 Mar 2006 09:38:37 -0500
Message-ID: <4424046D.5030001@utoronto.ca>
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:

In the Guidelines:


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

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

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