Bug 138196 – Implement :role pseudo selector

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Accessibility

[Dean Jackson]

At TPAC 2014, the CSS WG agreed to add a :role(foo) pseudo-selector to match against the active ARIA role.

e.g. :role(button) would match
<button>
<input type="button">
<input type="submit">
<div role="button">
<div role="something-not-supported button">
etc

http://www.w3.org/TR/wai-aria/roles#button

[Radar WebKit Bug Importer]

<rdar://problem/18818174>

[Dean Jackson]

This should go into the spec soon:
http://dev.w3.org/csswg/mediaqueries-4/

[Dean Jackson]

This should go into the spec soon:
http://dev.w3.org/csswg/mediaqueries-4/

[Dean Jackson]

http://lists.w3.org/Archives/Public/www-style/2013Jul/0104.html

[Dean Jackson]

Turns out the Web Inspector already has some code for this.

[Dean Jackson]

Copying some info from Ben into here:

Implementing this would involve: extending the CSS Parser to parse :role(), extend CSSSelector to store the information about :role(), extend Element to expose the active role, match the CSSSelector with the active role, ensure the correct style invalidation when the role changes.
Since this is a new feature, this also involves writing *a lot* of tests.

[Dean Jackson]

I think the entry point is AccessibilityObject::computedRoleString()

which, given an element/node, you get to via something like:

if (AXObjectCache* axObjectCache = node->document().axObjectCache()) {
  AccessibilityObject* axObject = axObjectCache->getOrCreate(node);
  ...

[James Craig]

Will need to discuss how to move the relevant portions (role/label) out of the accessibility-only code. We don't want to enable all the accessibility logic for everyone.

[chris fleizach]

(In reply to comment #8)
> Will need to discuss how to move the relevant portions (role/label) out of
> the accessibility-only code. We don't want to enable all the accessibility
> logic for everyone.

So is this meant to apply to the resolved role, or the developer role?

I can imagine it might be confusing if the resolved role is different from what the user writes down

[James Craig]

(In reply to comment #9)
> So is this meant to apply to the resolved role, or the developer role?

Computed role, not the content attribute. This may also be accessed as Element.computedRole() if a related change goes into DOM.

> I can imagine it might be confusing if the resolved role is different from
> what the user writes down

There are already attribute selectors, so if the dev needed the content attribute value, they already could already match on [role="whatever"]:

<button role="foo">test<button>

Would be matched by either:

*[role="foo"]
*:role(button)

[Sukolsak Sakshuwong]

Created attachment 240844 [details]
Patch

[Sukolsak Sakshuwong]

Sorry, I meant to submit this as a separate patch.

[James Craig]

IIRC, we decided this was un-implementable in its current state, and would require an exhaustive rewrite of WebCore. Closing.

[James Craig]

> IIRC, we decided this was un-implementable in its current state, and would require an exhaustive rewrite of WebCore.

A more complete version of that is captured in these comments:
- https://github.com/w3c/csswg-drafts/issues/3596#issuecomment-460135566
- https://github.com/w3c/csswg-drafts/issues/3596#issuecomment-1763539455