22220 2013-05-30 18:51:36 +0000 @role attribute, and ARIA global content attributes should be reflected DOM attributes. 2018-05-03 20:54:57 +0000 1 1 1 Unclassified ARIA General 1.1 PC All RESOLVED FIXED a11y, a11ytf, aria P2 normal --- 1 jcraig cooper dbolter eoconnor mark.sadecki+w3c mike public-html-admin public-html-bugzilla public-html-wg-issue-tracking redux robin surkov.alexander w3cbugzilla oldest_to_newest 88461 0 jcraig 2013-05-30 18:51:36 +0000 @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. 88463 1 faulkner.steve 2013-05-30 19:03:53 +0000 (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? 88465 2 dbolter 2013-05-30 19:25:33 +0000 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. 88466 3 jcraig 2013-05-30 20:26:56 +0000 (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. 88467 4 jcraig 2013-05-30 20:30:08 +0000 (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. 88752 5 dbolter 2013-06-05 17:25:28 +0000 (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? 88754 6 jcraig 2013-06-05 17:40:31 +0000 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>' 88755 7 dbolter 2013-06-05 17:41:16 +0000 Aha dot accessors. OK. 88766 8 eoconnor 2013-06-05 21:09:12 +0000 Shouldn't this be on the ARIA spec, not the HTML spec? 88786 9 jcraig 2013-06-05 23:37:04 +0000 Robin, should this remain in ARIA or in HTML? 89072 10 robin 2013-06-11 11:54:10 +0000 (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. 89875 11 redux 2013-06-26 09:43:50 +0000 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? 89913 12 jcraig 2013-06-26 18:21:31 +0000 (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>. 89914 13 jcraig 2013-06-26 18:26:29 +0000 (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 89915 14 redux 2013-06-26 19:01:11 +0000 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) 89918 15 jcraig 2013-06-26 19:36:21 +0000 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. 89919 16 jcraig 2013-06-26 19:40:55 +0000 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 105748 17 jcraig 2014-05-12 19:26:12 +0000 Reassigning component since this will be speced in ARIA, not any specific host language. 129180 18 w3cbugzilla 2018-05-03 20:54:57 +0000 AOM