W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Fwd: Objection to generator decision (Re: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey)

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Mon, 25 Apr 2011 12:10:52 -0500
Message-ID: <BANLkTimNgZ3z4eORhsyr9TEhvQAnR_EcOg@mail.gmail.com>
To: HTML WG <public-html@w3.org>, Jan Richards <jan.richards@utoronto.ca>
Thank you very much for your comments, Jan.

I am forwarding your message to public-html as it hasn't appeared there yet.

Best Regards,
Laura

---------- Forwarded message ----------
From: "Richards, Jan" <jrichards@ocad.ca>
Date: Mon, 25 Apr 2011 12:09:18 -0400
Subject: RE: Objection to generator decision (Re: Working Group
Decision on ISSUE-31 / ISSUE-80 validation survey)
To: Laura Carlson <laura.lee.carlson@gmail.com>, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com>, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no>, Jan Richards
<jan.richards@utoronto.ca>
Cc: HTMLWG WG <public-html@w3.org>

Hi Laura, Leif, (I will separately forward to UAWG and AUWG to avoid
automatic cross-posting)

Here are some thoughts:

First, thanks for the proposal. It's great to see so much thought
going into dealing with this.

My general comment is to be more clear about the distinction between
User Agents and Authoring Tools. You say "Validators are authoring
tools.", but then you include: "Clarification of how UAs should repair
the lack of @alt".

Of course, this is a bit tricky because validators float in between,
helping authors check and repair their work (as part of an authoring
tool), but they do this by performing many of the parsing actions of
user agents.

So, for the record, here are the (differing) requirements around
"repair" for User Agents vs. Authoring Tools. The differences make
sense because Authoring Tool "repairs" permanently affect every
end-user, while User Agent "repairs" only temporarily affect end-users
one at a time, according to their user settings.

(DRAFT) User Agent Accessibility Guidelines 2.0 [1] includes these relevant SCs:

3.4.1 Repair Missing Alternatives: The user has the option of
receiving generated repair text when the user agent recognizes that
the author has not provided alternative content required by the
technology specification (e.g., short text alternative for an image).
(Level A)
3.4.2 Repair Empty Alternatives: The user has the option of receiving
generated repair text when the user agent recognizes that the author
has provided empty alternative content. (Level AA)

UPSHOT: UAs must provide repair *options* (that end-users may or may
not enable) for empty or missing @alt.


(DRAFT) Authoring Tool Accessibility Guidelines 2.0 [2] include:

B.2.3.2 Conditions on Automated Suggestions: During the authoring
session, the authoring tool may only automatically suggest
programmatically associated text alternatives for non-text content
under the following conditions: (Level A)
  (a) Author Control: Authors have the opportunity to accept, modify,
or reject the suggested text alternatives prior to insertion; and
  (b) Relevant Sources: The suggested text alternatives are only
derived from sources designed to fulfill the same purpose (e.g.
suggesting the value of an image's "description" metadata field as a
long description).
B.2.3.3 Let User Agents Repair: The authoring tool avoids repairing
programmatically associated text alternatives for non-text content
using any text value that would also be available to user agents (e.g.
do not use the image filename). (Level A)

UPSHOT: Authoring tools can (but don't have to) make @alt suggestions
to authors. Tools must never clog up @alt with text values that UAs
already have easy access to (e.g. file names), because this can trick
accessibility checkers and UAs that may have optimized repair
features. More thoughtful repairs (e.g. using the authoring context,
image processing, etc.) are still allowed [3].


Also:

> The repair text should be: alt="Image."
> The repair text should be localized.
> ...

IF you meant this to be for User Agents:
I'm not sure about being so prescriptive (see the UAAG 2.0 text
above). What if a UA added some OCR capability such that it could
produce reasonable guesses when images contain text? I could imagine
it producing repair text such as: alt="Alt repair attempt foo-bar".

IF you meant this to be for Authoring Tools:
I would encourage the most reliable token possible ("image" - not
localized), because of the need to reliably communicate the message of
the token (more or less: "alt text was not provided and it might be
needed") to Accessibility Checkers, User Agents and ATs who would then
be free to take their own corrective action.

[1] http://www.w3.org/TR/2010/WD-UAAG20-20100617/
[2] http://www.w3.org/WAI/AU/2011/ED-ATAG20-20110308/#gl_b23 (this is
an Editors Draft but publication as a public draft has been approved)
[3] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5#case2

Cheers,
Jan


-- 
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University


> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
> Sent: April 24, 2011 5:10 PM
> To: Benjamin Hawkes-Lewis; Leif Halvard Silli; Jan Richards
> Cc: HTMLWG WG
> Subject: Re: Objection to generator decision (Re: Working Group Decision on
> ISSUE-31 / ISSUE-80 validation survey)
>
> Hi Benjamin, Leif, and Jan,
>
> Benjamin wrote:
>
> > I recommend collaborating with the UAAG authors to ensure that HTML5
> > and UAAG2 are consistent:
>
> Jan Richards, UAWG Chair was instrumental in the original WAI-CG alt
> consunsus agreement which said that WAI would not object to a missing
> mechanism. That document said:
> "We have reached the following consensus concerning 'automatically
> generated" alternative text: In order to address both the validity and
> human generation concerns, we do not oppose the creation of
> 'autogenerated' and 'missing' attributes where either one of these
> could be used to make an image that does not have any human-generated
> text alternatives valid. (Note: It is important that this marker is
> not included in the alternative text string itself.)' " [1].
>
> Jan explained how it could work in a use case [2] and in an August
> 2009 email to this group. [3]
>
> Jan, how could Leif's proposal be improved?
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0480.html
>
> Thanks.
>
> Best Regards,
> Laura
>
> [1] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
> [2] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5#case2
> [3] http://lists.w3.org/Archives/Public/public-html/2009Aug/1009.html



-- 
Laura L. Carlson
Received on Monday, 25 April 2011 17:11:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC