Re: feedback requested on WAI CG Consensus Resolutions on Text

Hi Steven,

Steven Faulkner On 09-08-17 14.30:

>> Summary: The Consensus Document (hereafter referred to as CD) fails to
>> discuss <object role="img">
> 
> the scope of the discussions was the img element and provision of text
> alternatives for it.


I think OBJECT provides perspective. But OK.

 
>> (1) CD talks about an obligatory short text alternative that will be
>> automatically presented to users (e.g. via @aria-labelledby) and an optional
>> long alternative which users must actively ask for (e.g. via
>> aria-describedby).
> The assertion that describedby is something  "which users must actively ask
> for" is not correct.


CD talks about the "ideal" situation, when a element has both a 
short and a long text alternative - I paraphrased it for context.

> The mechanism is not prescribed to my knowledge. in the
> abscence of a short text alternative, the longer text may be announced, or
> the presence of the longer text may be announced, which can then be
> announced when the user activates a key(s).


I can see that I perhaps made some exaggerated points about 
long/short w.r.t. OBJECT. But do you disagree with CD on this 
point? It says:

	"Short descriptions are read automatically when the item is 
encountered. Long descriptions are read only on user request."

The CD also says that an <img role="img"> without a short text 
alternative in any form, is not valid. (The same issue has also 
been debated, I remember, in this HTMLwg w.r.t. @longdesc: could a 
<img> be valid without an @alt text if only it has a @longdesc? )

It makes sense if UAs read the long text if a short one is 
failing. But that, then, must according to CD, be a "backup 
solution". A fallback for the fallback, so to say.

>> Q5: Does alt="" without role="presentation" change the role to
>> "presentation"?
> 
> not currently as role="presentation" is an indication to browsers to not
> expose the element via an accessibility API. alt="" does not do this.

 From one perspective: if it doesn't change the role, then it is 
illogical of a validator to ask authors to add 
role="presentation". Or what basis does it have for assuming that 
the author hasn't correctly identified the role of the IMG of the 
image in the markup?

OTOH, I see that you perceive @role as only an accessibility 
thing, something that only affects "accessibility API".

Am I wrong it perceiving @role as something that tells *everyone*, 
not least authors, what kind of role a certain, semantically 
ambiguous element play in a particular document?

Didn't ARIA take @role from XHTML 2, and not the other way around?

If @role is only and solely an accessibility thing, then I agree 
with you, somewhat. From that perspective, @role="presentation" 
becomes something extra that we do for those that needs it (and 
not very much of an author help).

>> Q6: Should <img role="img" alt=""> validate? (I think no.)


Would be nice if you could answer to Q6.

>>   Q7: Is it supposed to be permitted to literally write <img role="img">,
>> even if role="img" is the default? (Otherwise it would be impossible to
>> specify, with any certainty, that some IMG element is obliged to have a text
>> alternative.)
> 
> i think not, same as <img role="img"> should not, its redundant, the ,<img>
> element is already mapped to accessibility api's by the browser.

That something is redundant does not need to mean that it makes 
sense to make it invalid. What about this scenario:

	Several authors work on a document. One of them adds images that 
should have alt text. Then later, another one validates the 
document and notes that there are some errors with IMG elements - 
the validator ask for alt text to be added. To get rid of the 
problem, he adds alt="" to all those images, only to discover that 
he is advised to add role="presentation" as well, which he may or 
may not do.

	Conversely, if the images had role="img", then adding alt="" 
would not make the site validate with a non-critical warning. Or 
would it? Is that what you are saying that it would?

In the latter case, then an empty alt="" would become a signal for 
authors to follow up by adding role="presentation". Effectively, 
from authors point of view, an empty alt="" would then be come 
something that changes the @role from "img" to "presentation". 
Authors could simply dig up their Find/Replace tool and add 
role="presentation" next to all instances of alt="". Would that be 
an accessibility improvement that was well worth the effort?

I would gladly do so if it would. But I think it sends the message 
"be reluctant to make IMG elements available to AT tools". But if 
that is the right message, then OK.

I wish, however, that the name of the attribute was "aria-role" 
and not "role", if it is to be considered a functional attribute, 
rather than a semantic attribute.

If it is a functional attribute, then I also understand when 
Maciej and others ask why empty alt="" isn't enough.

>   (6) The document suggests that alt="" WITHOUT role="presentation" triggers
> a non-critical warning, '(even if @alt="" remains technically valid)'.
>        Q8: Would lack of role="presentation" in this case be WCAG 2.0
> compliant?
> 
> i would think so as the warning is meant to encourage developers to use
> role="presentation" not to indicate alt="" is invalid.


So CD in this case asks authors to go further than WCAG ...

 
> Q9: Who would the non-critical warning help? [...]


> see anser to Q8 .above


So, couldn't <img> also have the role "button"?  Why such an 
automatic message about adding role='presentation'?
-- 
leif halvard silli

Received on Monday, 17 August 2009 23:59:11 UTC