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

Hi Ben

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

This is prohibited in the spec.
This was done so alt would not be shown as a tooltip as it was in IE

If it was done the only difference between alt and title on img would be that one shows a tooltip.

There is no differentiation between title and alt in how they are mapped to accessibility APIs when only 1 is present.

So the use of title would undermine the detailed usage rules of alt that provide end users with meaningful text alternatives. 

Even if the title were rendered like alt it does not solve the many other accessibility issues to do with title. 

Title content is meant to be available to all at any time, not only when images are disabled.

Currently it is not nor has it been and 2 vendors have indicated no plans to change this.

Sent from my iPhone

On 29 Apr 2011, at 09:10, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote:

> 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 09:05:06 UTC