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

Re: [text] updated draft, 20110430, of clarification on alt validation

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sun, 1 May 2011 10:50:06 +0100
Message-ID: <BANLkTi=3Yfs9vApW9qFT937W2BN2xHFdkg@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sun, May 1, 2011 at 8:19 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 22:53:08 +0100:

[snip]

>> Note doing this is explicitly prohibited by ATAG 2 WD B.2.3.3:
>>
>> http://www.w3.org/TR/2011/WD-ATAG20-20110426/#gl_b23
>
> I suppose you specifically refer to this:
>
> ]]
> 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) [Implementing B.2.3.3]
> [[
>
> However, if I use TextEdit as an authoring tool, and adapt myself to
> how it works, creating file names such as 'My mom and dad in the
> sofa.jpeg', which results in code like
>
> <img src="My mom and dad in the sofa.jpeg" alt="My mom and dad in the
> sofa">
>
> Then I don't see that the term 'repair' applies.

I agree this could result in more accessible content than missing @alt;
I disagree it would not be a violation of ATAG 2.

> Note, as well, that in
> the above example - which is literally what TextEdit does, then the img
> element does not use the file name as @alt text, since the @alt text is
> different from the file name.

A UA could do perform the same alteration on the filename.

> Also, we have the priority of constituencies: tool vendors should
> comply to ATAG2, while authors should comply to CGAG2 and HTML5.

Not sure what you mean.

>>> After all, there are many much more important HTML features to
>>> implement in HTML e-mail before the generator string?
>>
>> This seems weak.
>
> May be. How? Most HTML e-mail messages do not use a valid DOCTYPE etc.

I think it's a bit like arguing that most webpages do not validate, so surely
there are more important features they should implement before "figure", so we
shouldn't spec "figure".

>>> [4] One (so far hypothetical) problem is that the
>>> generator exception could cause vendors to treat images differently
>>> when they operate with the generator flag present.
>>
>> IIRC past Decisions have been fairly dismissive of purely hypothetical
>> problems.
>
> I'm sorry, but in your previous reply you wrote:
>
> ]]
>> For example, a WYSIWYG authoring tool could allow a user to drag and
>> drop an image onto a webpage then popup a dialog asking for an @alt.
>> The user could tick a checkbox on the dialog indicating that they do not
>> want to provide an @alt and do not want to ever be asked for an @alt
>> again. Such an authoring tool would conform to ATAG2 as it stands.
>>
>> The generator exemption would allow the authoring tool to insert no @alt
>> in this situation instead of a bogus value.
> [[
>
> Clearly, if a tool stops asking about alt text when the generator
> string is present, then it treats the images differently because of the
> generator string. So it sounds from that letter as if you believe I
> have described a probably scenario.
>
>> I'd advise sticking to at least *likely* problems, giving some reason
>> why the problem is likely to occur.
>
> Given what I quoted from you above, perhaps you can explain better than
> I why the scenario is probable?

Okay, I thought "vendors" was referring to browsers. Based on what you say
above, you seem to be describing the intended effect of the exemption
(authoring tools insert no @alt instead of bogus @alt when the author does not
provide an @alt) as a "hypothetical problem".  This is confusing.

--
Benjamin Hawkes-Lewis
Received on Sunday, 1 May 2011 09:50:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:37 GMT