This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Change <pre> to <pre role="presentation" > in the section's figure example, to prevent AT from reading it: <figure role="img" aria-labeledby="fish-caption"> <pre> o .'`/ ' / ( O .-'` ` `'-._ .') _/ (o) '. .' / ) ))) >< < `\ |_\ _.' '. \ '-._ _ .-' '.) jgs `\__\ </pre> <figcaption id="fish-caption"> Joan G. Stark, "<cite>fish</cite>". October 1997. ASCII on electrons. 28×8. </figcaption> </figure>
According to bug 10483, it should not be necessary to use aria-labelledby on the <figure> in this example. (But of course using aria-labelledby like you did, should be both permitted and best practise to do so.) The spec should make it clear that aria-labelledby is a best practice measure. In a summary, I suggest to make the example like this, to make it clear that HTML5 supporting user agents do not need more than this : <figure role="img" > <pre role="presentation" > o .'`/ ' / ( O .-'` ` `'-._ .') _/ (o) '. .' / ) ))) >< < `\ |_\ _.' '. \ '-._ _ .-' '.) jgs `\__\ </pre> <figcaption> Joan G. Stark, "<cite>fish</cite>". October 1997. ASCII on electrons. 28×8. </figcaption> </figure> The <figcaption> will automatically get role="heading", and will be considered heading of the <figure>. Eventually, you could use the occasation to show how simple it can be done when using <figure>, and how much more work one must do when using <div> as the contianer. E.g .when using <div>; then it is a greater need to use aria-labelledby, since a <div> element does not have any default heading/caption element.
Doesn't the role="img" mean that: A) The contents of the element represents an image and thus AT shouldn't read it? B) That the element, at least from an AT perspective, no longer semantically is a figure but rather an image, thus the rules for how it's captioned by <figcaption> no longer applies? I'm admittedly very unsure about B. It's never been very clear to me how it's intended that ARIA should change semantics. Pointers more than welcome.
Hej från Oslo! :-) (In reply to comment #2) > Doesn't the role="img" mean that: > > A) The contents of the element represents an image and thus AT shouldn't read it? role="img" and <img> are different things. An element with role="img" contains (or links to, for eample in the form of an aria-describedby link) some kind of description of the image (be it a <img> image, an <object> image, or -- as in this case -- an ASCII image). The textual content of the element with role="img", must be presented to the reader by the AT. > B) That the element, at least from an AT perspective, no longer semantically is > a figure but rather an image, thus the rules for how it's captioned by > <figcaption> no longer applies? Please read about the landmark role "img" in ARIA 1.0 http://www.w3.org/TR/wai-aria/roles#img Again you must keep your tongue in balanse: what do you mean by "is a figure"? What does it mean to be a figure? There are many kinds of figures (now I am threading Shelley's subject...). Images in a book can be considered figures, if they have captions. HTML5 of course has a very broad intepreation of figure. However, there is for instance no ARIA role known as "figure". If it has no default role, then it cannot stop being a figure ... -- from AT's point of view. Here we are indeed touching one of the problems with <figure>: it provides a little bit less than what I think many think that it provides. At least from an accessibility angle. Have a look at bug 10484, which tries to make sure that <figure> is as simple to use as possible when it comes to accessibility. If <figure> had a default role, _then_ we could talk abotu "no longer semantically be a figure", perhaps. I don't know what that role eventually should be: 'group', 'note', 'region'? Possible roles: http://www.w3.org/TR/wai-aria/roles#section Think we must live with a broad/loose figure element. > I'm admittedly very unsure about B. It's never been very clear to me how it's > intended that ARIA should change semantics. Pointers more than welcome. There were some pointers above - don't know if they help. ARIA, in my view, never changes semantics. Well, except from AT user's point of view. The point with ARIA is to make the existing semantics clear. ARIA clearly uses a broad definition of image (or role="img"). However, that to me makes sense. But it is going to be a problem to get authors to keep the different meaning of e.g. role="img", <img> and image. ;-)
(In reply to comment #3) > Hej fr�n Oslo! :-) > > (In reply to comment #2) > > Doesn't the role="img" mean that: > > > > A) The contents of the element represents an image and thus AT shouldn't read it? > > role="img" and <img> are different things. An element with role="img" contains > (or links to, for eample in the form of an aria-describedby link) some kind of > description of the image (be it a <img> image, an <object> image, or -- as in > this case -- an ASCII image). The textual content of the element with > role="img", must be presented to the reader by the AT. 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? > 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. > 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 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?
(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.
Jonas, also see bug 10495
(In reply to comment #5) > (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. Filed Bug 10497 based on the above discussion.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Based on my (re)reading of the ARIA spec, role=img is more appropriate here than role=presentation, so I've left it as is.
(In reply to comment #8) > Rationale: Based on my (re)reading of the ARIA spec, role=img is more > appropriate here than role=presentation, so I've left it as is. Even a correct resolution should have correct justification! Your justification leaves it unclear whether you understood the request. Thus I reopen it for your (re-)verification Clarification of my request: -------------------- a) The ASCII fish image is located inside the <pre> element. b) My request was thus that <pre> should have role="presentation". An acceptable justification for a WONTFIX: ------------------------------- Per what Jonas said in Comment #4 and per section 5.2.8 of ARIA 1.0, then: [1] ]] The DOM descendants are presentational. User agents SHOULD NOT expose tdescendants of this element through the platform accessibility API. If user agents do not hide the descendant nodes, some information may be read twice.[[ This effectively means that the <pre> in your example automatically gets some sort of role="presentation". [1] http://www.w3.org/TR/wai-aria/complete#childrenArePresentational
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There's nothing presentational here. There's an image, with a label. I really don't understand why you would want role=presentational here, it doesn't match what ARIA says at all as far as I can see.
The bug-triage sub-team doesn't think this bug is task force priority. If Leif disagrees with the editor's decision he can either reopen or escalate the bug.