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

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.

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

> After all, there are many much more important HTML features to
> implement in HTML e-mail before the generator string?

This seems weak.

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

> 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, whereas the swap of bogus @alt values
is a problem right now.

> [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'd advise sticking to at least *likely* problems, giving some reason
why the problem is likely to occur.

> == On the Co-Chair's decision on the presence of figcaption ==

[snip]

> ** MANY ASSISTIVE TECHNOLOGY USERS WOULD BE UNABLE TO ACCESS FIGCAPTION AS
> AN ALT SUBSTITUTE

The argument from backwards compatibility in the case of <figcaption>
risks appears to contradict the argument from wide implementation of
ARIA in *recent* browsers and supporting AT in the case of
@aria-labelledby and @role="presentation".

--
Benjamin Hawkes-Lewis

Received on Saturday, 30 April 2011 21:53:36 UTC