[Bug 22220] @role attribute, and ARIA global content attributes should be reflected DOM attributes.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22220

--- Comment #12 from James Craig <jcraig@apple.com> ---
(In reply to comment #11)
> Ah, excellent...I've been ranting recently about how default role is exposed
> via accessibility APIs, but not reflected in normal JS.

I think that is a separate issue. We've talked about adding
Element.computedRole() in ARIA, which would allow an element like <foo
role="switch checkbox"> to return "switch" in browsers that supported the new
ARIA 1.1 "switch" role, and "checkbox" in all other browsers. The element.role
property should just reflect the raw string value ("switch checkbox") so I
would expect that it should not return any implicit value for host language
elements.

var h1 = document.createElement("h1");
h1.getAttribute("role"); // empty string ""
h1.role; // empty string ""
h1.computedRole(); // "heading"

> This would make
> writing extensions that do things like "skip to main/navigation/etc" easier,
> as then they wouldn't have to go through both any arbitrary element with a
> particular role, AND  a list of known elements that traditionally get these
> default roles - a simple iteration over any elements with specific role will
> suffice. Would this also enable CSS styling based solely on attribute
> selectors? (e.g. * [role=main] { ... } ) or does that need to be filed
> against CSS spec?

Attribute selectors already work in modern browsers, but they would not (and
should not) get any special behavior from implicit roles. e.g. [role="heading"]
would select <h1 role="heading" and <div role="heading"> but not <h1>.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.

Received on Wednesday, 26 June 2013 18:21:32 UTC