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

Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 22:53:08 +0100:
> On Sat, Apr 30, 2011 at 9:20 PM, Judy Brewer <jbrewer@w3.org> wrote:
>> == On the Co-Chairs' decision on meta name=generator ==
> 
> [snip]
> 
>> 4. EVIDENCE: "A demonstrated trend towards more authoring tools fully
>> supporting ATAG2, including the requirement to prompt for textual
>> equivalents for images."
> 
> [snip]
> 
>>   Interestingly, even plain text editors have started to help authors
>> offering @alt text: if you drop an image into a HTML file edited with
>> the mode sensitive TextMate.app for Mac OS X, it will auto-create an
>> img element for you where it uses the file name (minus suffix) as @alt
>> text. The @alt text selected and highlighted so you can change it
>> immediately if you see need to.
>>  To use file names as @alt text is a common pattern of conversion
>> tools such as hypermail 2.2.0+W3C-0.50 [30] and  TextEdit.app word
>> processor bundled with Mac OS X (whenever it saves a page as a
>> webarchive file). TextEdit.app uses the 'Cocoa HTML Writer' generator.
>>  Thus prompting is not the only important thing, it is also important
>> to simply make the author aware of how the program operates.
>>  We would turn the evidence asked for on the head: where is the trend
>> that shows that pages with the generator string have especially low alt
>> text quality?
> 
> This text makes it sounds like we're saying it's good for generators
> automatically to insert filenames in @alt.

While I agree that it is possible that some weak soul could read it 
like that, it doesn't say that.

> 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. 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.

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

>> 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.
 
>> (3) At the same, @alt text is so important in e-mail that it is
>> pointless to even create the impression that it isn't.
> 
> This seems unsupported by the evidence presented: the needs of
> advertisers communicating to a mass audience on a variety of clients
> are not the same as the needs of an individual communicating to a
> known other individual using known clients.

There are many similarities. In you previous reply you spoke about a 
popup dialog which let the user select to not ever be asked to provide 
@alt text again. Should an e-mail author be allowed to say that 'From 
now on, I only write private e-mail'? Or should (s)he be allowed to get 
the same pop-up and and answer that (s)he never wants to be asked 
again? (Not realizing the consequences this will have when (s)he start 
to send out advertisement letters.)

Meanwhile, the chairs placed the private exception under the generator 
exception. I do not therefore need to get the private exception 
reopened - I agree that it should be closed. I only need to attack the 
generator exception from an e-mail perspective.

Btw, I did provide the Thunderbird example: if you send HTML-mail, then 
Thunderbird defaults to also producing a parallel text version of the 
letter that those which do not like HTML-mail will get to read. The 
author probably do not want the text only user to loose the image 
content. 

>> A. A VERSIONING ELEMENT IS AN ELEMENT OF UNCERTAINTY
>>   The meta@name=generator exception has a direct parallel in the
>> generator exception for WYSIWYG editors present in HTML5 in the January
>> 2008 draft, [1] and which Karl Dubost described as a form of
>> versioning. [2][3] 'Real' versioning, in form of strict/transitional
>> modes etc, is banned from HTML5 - at the latest in a Decision in
>> December 2010.
> 
> I think it's inaccurate to say this. The Decision simply reviewed two
> proposals, a doctype version proposal and a null change proposal, and
> accepted the later. It didn't "ban" versioning per se. In particular,
> doctype versioning was rejected because it is unneeded right now but
> could be added later if required,

OK. Good point.

> whereas the swap of bogus @alt values is a problem right now.

From our discussion, I can't see that I get convinced that this is not 
a sort of subversioning - a kind of 'transitional' that is restricted 
to @alt.

>> [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?

From those tool vendors which *do* prompt, we have only heard (from 
Daniel G.) that they will only provide two options: empty and non-empty 
@alt. 

I don't feel I have heard a credible usage scenario for the generator 
string: I can see that a tool which doesn't provide any prompt at all 
could use the generator exception - it would be a way to become 
"valid".   But I have problems understanding how a ATAG2-compliant tool 
can fit the generator exception into its workflow.
-- 
leif halvard sillli

Received on Sunday, 1 May 2011 07:20:08 UTC