W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2011

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

From: Richards, Jan <jrichards@ocad.ca>
Date: Mon, 25 Apr 2011 12:11:12 -0400
To: UAWG list <w3c-wai-ua@w3.org>
Message-ID: <F2C77FB59A1A4840A01EF5F59B1826E20A3D00E7BB@ocadmail.ocad.ca>
Hi all,

Laura Carlson asked me to comment on a discussion they are having in the HTML group. It concerned @alt repairs in User Agents so I have forwarded my reply to this group.

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: Richards, Jan 
Sent: April 25, 2011 12:09 PM
To: Laura Carlson; 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 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

Received on Monday, 25 April 2011 16:11:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 April 2011 16:11:27 GMT