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

On Fri, Apr 29, 2011 at 7:20 AM, Judy Brewer <jbrewer@w3.org> wrote:
> == On the Co-Chairs' decision on role=presentation ==
>
>> * The presence of role=presentation does not make missing alt conforming.
>
> The default semantics for and image with alt="" is role="presentation". The
> accessibility API mapping is such that, when alt="", the <img> element is
> removed from the accessibility API tree to improve assistive technology
> performance as well as browser performance in that the browser is not
> maintaining accessible objects for these presentational elements.
> Applications, such as those from IBM, have used role="presentation" to
> remove these objects from the accessibility tree as HTML4 does not have the
> same mapping as we have specified for HTML 5. So, not allowing alt="" and
> role="presentation" to be used interchangeably violates consistency with the
> default HTML 5 semantics and is inconsistent with the ARIA specification.

There would only be inconsistency if simply mapping HTML to ARIA roles
and properties were a sufficient description of all HTML's semantics and
behavior, which it clearly is not. Yes, img alt="" can be mapped to
role="presentation" and removed from the accessibility tree, but that
is not a sufficient description of the full semantics and behavior
of that markup.

I think this response fails to address the impact that alt="" has, and
role="presentation" does not, beyond the accessibility API tree. For
example: alt="" can change what happens visually when the user has
images turned off in a visual browser, or the image fails to load,
or the user is viewing the content in a text browser such as Lynx.
This was treated as a "moderately strong objection" in the Decision.

In any case, this response should cite the relevant bits of the specs
it's talking about so that it's not making claims about specs without
evidence.

> == On the Co-Chairs' decision on meta name=generator ==

[snip]

> 3. EVIDENCE: LACK OF ALT CHECKING IS HARMING
>   Additionally, since the HTML5 validators does not currently perform
> any validation of whether alt is present at all or of how it is used,

This is incorrect. See the "Show image report" feature at http://validator.nu/.

> it makes sense to try to evaluate if HTML5 pages currently use less or
> more @alt than HTML4 pages do.

I think this analysis isn't very persuasive.

According to the MAMA survey, about one fifth of "img" elements
are missing "alt".

http://dev.opera.com/articles/view/mama-images-elements-and-formats/

According to this survey of HTML5 pages, one fifth of them omit at least
one "alt". These seem like failures of a similar order of magnitude.

The selection of HTML5 pages is so different in character from the web
in general that it's hard to extrapolate from one to the other.

> A generator exception for img elements remains a form of
> versioning.

I find this argument sophistic.

Document versioning was dumped from HTML because having versions trigger
multiple code paths in user agents did not solve any problems the WG
agreed were worth solving.

The generator exception does not require multiple code paths even in a
conformance checker, it's just yet another rule in its ruleset, and it
does *try* to solve a important problem (specifically, the generation of
bogus "alt" text).

> Authoring tools vendors are not going to be willing to stamp their own
> code as substandard, let alone use their own product names as a
> sub-quality marks.

The generator flag doesn't establish two tiers of document quality beyond the
obvious - generating good text alternatives requires human input.

> C: GENERATOR IS ALREADY IN USE FOR OTHER PURPOSES
>   Authoring tools use the generator string as a kind of signal to
> those who view source - to identify pages made by their product.

How many any authoring tools that do not have any features for automatically
generating markup insert the generator flag? If they generate markup,
then the generator flag is appropriate.

> D: DROPS ALL REQUIREMENTS ON THE FLOOR
>   The generator exception drops all authoring requirements for @alt
> text on the floor, even those which are machine checkable. For example
> the requirement that an img element that is the sole content of a link
> must have alt text that is suitable as link text. [7] HTML5 explains
> how a generator (!) can pick link text from the title of the target
> page and similar to get link text, thus there is a doable task
> description. [8]

I think this a good argument for removing the exemption in the case
of images where the alt text is required for links. However, I think
a better solution would be for the validator to complain when buttons
or links are missing labels, since this would catch this case and also
catch the increasingly common scenario where the "content" of a textless
button or link is expressed through a CSS background image only.

> == On the Co-Chairs' decision on the presence of title making missing alt
> conforming ==

[snip]

> Title has a completely different function from alt in HTML. Title is used to
> generate a tooltip, and is invisible when images are turned off. Alt does
> not generate a tooltip, and is visible when images are turned off.

> If title is allowed as alternative text over alt it will break applications
> such as Yahoo! mail; it will also break a commonly-used feature, in less
> powerful mobile phones, where images are turned off to improve performance.
> If title were to be used in place of alt then when images are turned off in
> the browser, nothing meaningful will be shown in the browser.

It would be interesting to know what would happen if UAs simply rendered
@title when @alt is absent.

> having title take precedence over alt will result in tooltips
> being generated on decorative images and spacers

I don't understand this claim. Why would this happen?

> It should be noted that title is used as a last resort when other measures
> cannot be employed to compute the label or "name" of an object in the
> accessibility API mapping for browsers.

It's not clear why this is an argument against the Decision.

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

[snip]

> *Replacement of alt by figcaption breaks existing assistive technology
> support
>
> No screen reader in use today supports figcaption. Popular screen readers
> today do support the reading of the alt attribute and, in some cases, the
> longdesc attribute.  Users are accustomed to locating image descriptions and
> identifiers via these two methods. If alt is omitted because a figcaption
> exists, how will a screen reader notify the user that a description exists
> in figcaption rather than alt? Supplying image descriptions via figcaption
> may confuse screen-reader users who are already used to finding descriptions
> via the alt or longdesc attributes.  A single Web page that contains four
> images with descriptions provided via alt or longdesc, and two images with
> descriptions provided via figcaption, presents a confusing situation for a
> screen reader user, and increased problems for assistive technology support.

I wonder if this might be fixable by improving the mapping of
figcaption into the accessibility tree.

> making missing alt conforming in the presence of figcaption breaks a
> successful accessibility feature of HTML

I think saying it breaks a feature is erroneous.

--
Benjamin Hawkes-Lewis

Received on Friday, 29 April 2011 08:10:40 UTC