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

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 2 May 2011 23:50:20 +0200
To: Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <Cyns@microsoft.com>
Cc: Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html-a11y-request@w3.org
Message-ID: <20110502235020885592.9ed18ec0@xn--mlform-iua.no>
Richard Schwerdtfeger, Sun, 1 May 2011 20:07:50 -0500:

Quick summary of my reply: You continue look at the issue purely from 
an ARIA point of view. The gist is that you suggest to replace @alt 
with @aria-label.

> I thing that is new regarding role="presentation" and the use of 
> alt="" on an image is that the HTML 5 Accessibility API 
> implementation guide now clearly states that providing alt="" has the 
> same default semantics and implementation as alt="".

I doubt that e.g. Ian would see it as new info that alt="" and 
role=presentation are equal. But should AT really see them 100% equal? 
Some VoiceOver examples:

VoiceOver will use @title as link text here:
<a href="../" > <img alt="" title="LoremIpsum" src=image></a>

VoiceOver will NOT read @alt as link text here:
<a href="../" ><img role=presentation alt="LoremIpsum." src=image ></a>

Especially when IMG elemens are used as links, including in AREA 
elements for image maps, then IMG elements with a non-empty @title, but 
where @alt is omitted or is empty @alt, is not difficult to find on the 
web. 

When role=presentation is added, then AT has to go look elsewhere for 
alternative text. And if @alt is treated as 100% identical to 
role=presentation, then it creates the same issue.

> [...] Forcing an alt text with "" will 
> confuse the author when they think their job is done.
> 
> Authors must be allowed to use either markup. This is new evidence, 
> pertaining to user agent accessibility API support, was not brought 
> forth in the survey responses. Had I taken the survey I would have 
> provided this information for the chairs to review. The chairs should 
> treat this as new information not yet considered. 

Again, doesn't sound new to me.

> To address Leif's comment:
> http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0330.html
> 
> ARIA is now part of HTML 5. We are producing a specification for HTML 
> 5. Either a user agent or AT is HTML 5 conforming or it is not.

For the following markup, it is against HTML5 to hide the @alt string 
for a GUI browser:
<img role=presenation alt="LoremIpsum." src=i >

Regarding my question about  "how permission to add @role=presentation 
without simultaneously adding @alt 'violates consistency with the 
default HTML 5 semantics'", then you replied the following, which only 
talks about AT:

> To 
> address the last paragraph that Leif refers to I refer to the first 
> paragraph above. The default native semantics for alt="" is that of 
> role="presentation" and the HTML 5 accessibility API mapping 
> specification will produce the exact same API mapping as 
> role="presentation". This document is normative. Where this violates 
> ARIA semantics is that ARIA semantics, when applied to HTML, define 
> the API mapping when role="presentation" is applied to an img in 
> HTML.

What about non-AT? When will you file a bug asking that non-AT treat 
role=presentation like @alt?=

Thereafter you write:

> If we require alt="" in order for an image to be deemed 
> presentational then we are saying that alt="" default semantics is 
> now inconsistent with role="presentation" as now we have to set both 
> attributes to achieve the intent of role="presentation". That is not 
> the case for ARIA today.

You use the wording "to be deemed presentational". "Deem" is about 
semantics. I agree that AT should be able to rely 100% on 
role=presentation. There is no need, for ARIA supporting AT, to add an 
empty @alt. 

What is it that makes you think I think otherwise? 

For example the example I pasted above, is presentational to AT - and 
for that matter, it might also be presentational to non-AT - e.g the 
@alt attribute could contain some form of ASCII art. For example, if 
the image contains a nice decoration, then the @alt could be used to an 
ASCII decoration.

<img role=presenation alt="LoremIpsum." src=i >

> ARIA is now integrated into HTML 5 and we 
> must not be adding additional work for the author when alt="" or 
> role="presentation" map exactly the same and have the same host 
> language semantics and therefore accessibility API mapping. 

Then I expect that you will soon file a bug against HTML5 were you 
require that, *even in visual user agents*, the string "LoremIpsum", 
should be hidden from visual users.
 
> Frankly, alt="" was a hack to begin with as we did not have a concept 
> of a presentational attribute in HTML 4 and would not be intuitive to 
> a first time HTML author.

I don't understand how alt="" was a hack. In contrast, it would be 
consistent with how role=img works to permit that IMG contains text 
inside @alt, which AT doesn't see because the image has 
role=presentation.

It is only a continuation of the hacking if we require that an img 
element with role=presentation do not need to have @alt or cannot have 
a non-empty @alt.

> The working group has taken steps to be 
> able to use them interchangeably 

This is only true from AT's point of view.

> and to have alt="" benefit from the 
> improvements made by role="presentational".

This I don't understand.

> Going forward I would 
> hope that authors would use role="presentation", and alt="" be 
> deprecated, as it will be consistent with it's use elsewhere in HTML 
> and other host languages where WAI-ARIA is applied, much the same way 
> we can use aria-describedby or aria-labelledby consistently 
> throughout HTML and other host language specifications. Authors would 
> not need to remember all the special case attributes for each HTML 
> element like: alt, summary, etc.

This is pure value for the money. But I don't think that the HTML5 
editor agrees with you that HTML5 has taken such a step. Neither do I. 
Hence I voted for the current solution on @role=presentation in the 
poll. And would do it again.

Why don't you take a stance that is more in line with the one you took 
on <table role=presentation>? If a table has role=presentation, then 
the Web author has to make sure that even sighted perceive it as a 
non-table. This is the stance we should take on <img role=presentation> 
too. Namely, we should require that the @alt and the image of <img 
role=presentation> reflects the fact that the image is presentational.
-- 
Leif Halvard Silli
Received on Monday, 2 May 2011 21:50:55 GMT

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