(In reply to comment #0)
> @role attribute, and ARIA global content attributes should be reflected DOM
> attributes.
> 
> Was talking to Robin Berjon at the recent HTML F2F meeting, and he requested
> I file this bug. Since @role and the ARIA global attributes are allowed
> everywhere, making them reflected content attributes would be very useful to
> web developers. 
> 
> The only challenge I can predict for this would be specifying the bits that
> ARIA refers to as the "Implicit Value for Role:"
> 
> For example, when role="alert"
>  • Default for aria-live is assertive.
>  • Default for aria-atomic is true.
> 
> So these two are functionally identical:
> <div role="alert"></div>
> <div role="alert" aria-live="assertive"></div>
> 
> This may pose a problem for making *all* the global attrs reflected, but
> should not pose a problem for @role.

OK so this is filed against the API spec is this the right place for it? I thought it would be better in HTML spec no?

Hmmm. This is interesting. I'm curious if there are particular here-and-now reasons for requesting this or is it considered speculatively useful? I may have concerns but need to think about it more.

(In reply to comment #1)
> OK so this is filed against the API spec is this the right place for it? I
> thought it would be better in HTML spec no?

Yes, you're right. Redirecting.

(In reply to comment #2)
> Hmmm. This is interesting. I'm curious if there are particular here-and-now
> reasons for requesting this or is it considered speculatively useful? 

Mainly for the accessor convenience. Robin was specifically asking about accessibility convenience features at the F2F and this one came up. He may have additional ideas for its usefulness.

(In reply to comment #4)
> (In reply to comment #2)
> > Hmmm. This is interesting. I'm curious if there are particular here-and-now
> > reasons for requesting this or is it considered speculatively useful? 
> 
> Mainly for the accessor convenience. Robin was specifically asking about
> accessibility convenience features at the F2F and this one came up. He may
> have additional ideas for its usefulness.

OK thanks. Just for clarification, do you mean existing DOM accessors or new API?

New API. For example:

// role DOM attr reflects the role content attr.

var el = document.createElement('div');
el.setAttribute('role', 'group');
el.role
> 'group'
el.role = 'main'
el.getAttribute('role');
> 'main'
el.role = 'banner'
e.outerHTML
> '<div role="banner"></div>'

Aha dot accessors. OK.

Shouldn't this be on the ARIA spec, not the HTML spec?

Robin, should this remain in ARIA or in HTML?

(In reply to comment #9)
> Robin, should this remain in ARIA or in HTML?

I can't say that I have a preference either way. It depends on how ARIA is planning to evolve over time. If you consider it mostly stable, then integrating this from the HTML spec can make sense; but if you are planning evolution then it will be simpler to handle this in ARIA (it avoids needing to sync up).

If you go with ARIA, we can help you with how to specify this.

Ah, excellent...I've been ranting recently about how default role is exposed via accessibility APIs, but not reflected in normal JS. 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?

(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>.

(In reply to comment #12)
> We've talked about adding Element.computedRole() in ARIA

By the way, this is PFWG-ISSUE-427.
https://www.w3.org/WAI/PF/Group/track/issues/427

Ah, sorry James, I got the wrong end of that particular stick. computedRole() does sound along the lines of what I'm ideally after (though I can't access/track the PFWG issue, but from your example this seems to fit my specific use case - though it would mean iterating over each node and checking computedRole() rather than using a CSS-style selector I guess)

There's probably room in CSS4 for a selector like *:role('heading'), but I imagine it'd be blocked until we got Element.computedRole() standardized and implemented.

PFWG-ISSUE-589: Propose CSS selector like *:role('heading') once we have Element.computedRole() in a draft
https://www.w3.org/WAI/PF/Group/track/issues/589

Reassigning component since this will be speced in ARIA, not any specific host language.

AOM