This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9656 - ISSUE-383: what if aria-labeledby points to element with role="presentation"
Summary: ISSUE-383: what if aria-labeledby points to element with role="presentation"
Status: RESOLVED WONTFIX
Alias: None
Product: ARIA
Classification: Unclassified
Component: Core AAM (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P1 normal
Target Milestone: ---
Assignee: David Bolter
QA Contact: ARIA UA Implementors
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-04 18:55 UTC by Andi Snow-Weaver
Modified: 2011-12-09 18:10 UTC (History)
1 user (show)

See Also:


Attachments

Description Andi Snow-Weaver 2010-05-04 18:55:35 UTC
UA must provide pointer to accessible object in IA2 and ATK. 

But current wording requires that UA's NOT create an accessible object if role="presentation", even if referenced by aria-labeledby. (See bullets in section 4.1 General Rules for Exposing WAI-ARIA semantics.)

So it is an author error if aria-labeledby references an element with role="presentation".

But what should UA's do?

Cynthia thinks in MSAA and UIA, they should get the text from the element referenced by aria-labeledby and use it for the name.
Comment 1 David Bolter 2010-05-04 20:22:39 UTC
I think we decided to override the role="presentation" and consider the relation important. I'm pretty sure we include this as an object in the a11y tree.
Comment 2 Andi Snow-Weaver 2010-07-01 20:25:35 UTC
From section 4.1 in the UAIG:

The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessible tree:

    * elements with role="presentation" that are not focusable or that do not have global states or properties other than aria-hidden.

This is in agreement with the ARIA spec.

But if an element with role="presentation" is referenced by an aria-labelledby property on another element, the contents of that element would still be a text node which would be in the a11y tree. So which of the following is Firefox doing:

1. actually putting the element pointed to by the aria-labelledby property in the a11y tree, or
2. putting the text node that contains the actual label in the accessibility tree

???? 

If option 1, it's not in compliance with either the UAIG or the ARIA spec. 

If option 2, it's fine as long as the ID of the text node is used for IA2_RELATION_LABELLED_BY (IA2) and LabeledBy (ATK).

Cynthia thinks IE just uses it as the name which is in line with the name computation rules.
Comment 3 David Bolter 2010-07-26 14:06:22 UTC
Firefox strips out the element, and leaves the child text node. As I understand it, text nodes can not have attributes (like id, for example). So the labelledby relationship is lost.

I think this issue might be mitigated, depending on what we decide about aria-hidden.
Comment 4 David Bolter 2011-03-10 16:29:18 UTC
I think the relation should be ignore, and ARIA role always should take precedence over these conflicts.

role="presentation" should only be used on stuff that is purely visual asthetic, not on anything that could be semantically meaningful to a screen reader. It should be used as a hack.
Comment 5 David Bolter 2011-04-28 14:49:13 UTC
I need to read the new aria spec text on role="presentation"
Comment 6 David Bolter 2011-07-22 19:36:03 UTC
FF won't expose the relationship and I can't see us prioritizing any change here.
Comment 7 Andi Snow-Weaver 2011-07-28 12:08:46 UTC
So does this mean that the text of the element with role="presentation" will not be used in the name calculation? The name calculation section doesn't say anything about role="presentation"

http://www.w3.org/WAI/PF/aria/roles#namecalculation
Comment 8 Andi Snow-Weaver 2011-07-28 15:40:52 UTC
David,

I discussed this with Rich. It is NOT an authoring error. role="presentation" just strips the semantics. It doesn't hide the text. That's what aria-hidden is for and we have rules for that in the name calculation rules. It's the same as if the aria-labelledby pointed to text. Does FF not support that?

ACTION: File a FF bug, record the number here, and then close this bug.
Comment 9 David Bolter 2011-07-28 18:38:53 UTC
OK good news and clarification:

Regarding name calc: FF *does* pick up the text for name calculation as per IE.

Regarding IA2 relations: FF can not guarantee exposing the IA2 relations as per comment 6.
Comment 10 Andi Snow-Weaver 2011-10-18 20:35:55 UTC
Are there other cases where FF does not expose the relation if the referenced object has role="presentation"?

I think this is covered by the following general rule for including something in the accessibility tree:

* has a role attribute but does not contain the presentation role before any other mappable role (see Role Mapping below) and does not inherit a role of presentation from an owning element. If the presentation role is used or inherited, the element must still be exposed if it has a WAI-ARIA global attribute other than aria-hidden or is focusable, so that FOCUS events can be fired (focus must never be lost).

If the element referenced by aria-labelledby has role="presentation", it won't be in the accessibility tree and therefore you can't expose the relations. I hope this is sufficient as I don't want to put in special cases everywhere for role="presentation" and certain relations.
Comment 11 David Bolter 2011-12-09 16:52:04 UTC
(In reply to comment #10)
> Are there other cases where FF does not expose the relation if the referenced
> object has role="presentation"?
> 
> I think this is covered by the following general rule for including something
> in the accessibility tree:
> 
> * has a role attribute but does not contain the presentation role before any
> other mappable role (see Role Mapping below) and does not inherit a role of
> presentation from an owning element. If the presentation role is used or
> inherited, the element must still be exposed if it has a WAI-ARIA global
> attribute other than aria-hidden or is focusable, so that FOCUS events can be
> fired (focus must never be lost).
> 
> If the element referenced by aria-labelledby has role="presentation", it won't
> be in the accessibility tree and therefore you can't expose the relations. I
> hope this is sufficient as I don't want to put in special cases everywhere for
> role="presentation" and certain relations.

I would remove "and does not inherit a role of presentation from an owning element", "or inherited". (role=presentation is not inherited)

With that, I think your text is sufficient.
Comment 12 David Bolter 2011-12-09 17:57:10 UTC
Andi, scratch what I just said, I didn't realize you were talking about the special cases where presentation *is* inherited, like with table and its sub elements.

I think your text is good to go.
Comment 13 Andi Snow-Weaver 2011-12-09 18:10:08 UTC
Presentation role is inherited. Per the ARIA spec [1], "However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation."

So I'm not changing the text and I think we're good on the aria-labeledby pointing to an element with role="presentation". If there aren't any other ARIA attributes on the element, it won't be in the accessibility tree. The text will be used in the name calculation but the relationship won't be exposed in the AAPI.