[Bug 10480] add role="presentation" on the ASCII fish image

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10480





--- Comment #5 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-08-29 13:58:57 ---
(In reply to comment #4)

> http://www.w3.org/TR/wai-aria/roles#img says
> 
> Children Presentational:    True
> 
> How is that different from making the children presentational using
> role=presentational on all of them?

If by "it" you meant the "contents of the element" and not the element (figure)
itself (in which I include <figcaption> also), then you are on to a very real
problem - a problem which we have not solved: If <img alt="" src="*">, then it
is a no-brainer, the <img> is presentational. But what if we have an <img> with
a non-empty @alt? Does the <img> loose its native default to role="img"
whenever it is placed inside a <figure role="img">?

My thinking is, yes, the <img> then looses its native default to role="img". if
an <figure role="img"> contains an <img> with a non-empty @alt, then that <img>
will be treated by AT as simply a text container for the <figure role="img">
element.

(I believe that I and Steve are not on the same page on this issue.)

> > There were some pointers above - don't know if they help.
> 
> None of the links you provided unfortunately defines how ARIA role interacts
> with the built-in semantics of elements.

I have filed one bug which - in a practical way - possibly relates to your
question, bug 10482.

> > ARIA, in my view, never changes semantics. Well, except from AT user's point
> > of view.
> 
> But I'm specifically talking about the semantics as seen by an AT user. Also,
> Richard Schwerdtfeger claims in [1] that non-AT users should see a different
> context menu based on what the role-attribute says. This means that at least to
> some extent semantics are changed by the role attribute even for non-AT users.
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2010Jun/0435.html

Ah, the "godsend" discussion ... 

> In any case seems like you are saying that the role attribute never changes
> semantics, only adds to them? At least when the original semantics can't be
> described by aria? Does this mean that an element can have two separate set of
> semantics at the same time? This seems to be hard to handle in general, for
> example if such elements have conflicting semantics. Can you point to a place
> in the aria spec that prescribes this?

I did not get what you meant by "prescribe".  Whether @role changes the actual
role, or just expresses it, are two sides of the same coin, in my view. HTML5
currently forbids - and prescribes - many element/role combinations. The basis
for the forbidding/prescribing is related to an evalutation of what kind of
roles that are within the semantics of the elemen - and possibly also how it is
common to use certain elements.

It seems to me that in the debate between Ian and Richard, then Ian drew a more
direct line between element semantics and @role semantics than Richard did.
Their disagreement also, in my view reflects that Ian sees the Validator as a
developement tool (errors can help you do it correctly) whereas Richard sees
the validator as a approval machine - accessibilty experts etc should not be
"punished" by getting a "not valid" message for having trying to make a code
accessible. Within the box that Ian is thinking, @role can be a "godsend"
because it can help evaluating the code better - and thus the validator become
a better developement tool.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 29 August 2010 13:58:59 UTC