see discussion threads here
http://lists.w3.org/Archives/Public/public-pfwg/2014Oct/thread.html#msg120
http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/thread.html#msg105

I'm slightly unconvinced about the name 'computedLabel' as to me it sounds like it might return an HTMLLabelElement. Would 'computedName' work?

If you want a change to DOM, filing a bug at https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=DOM is more likely to get the attention of the editor, Anne van Kesteren.

Why do we put these on Element? Why are they methods? And why can't computedRole just be role?

I found this bug via the blink-dev thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/WToTEn4lveY

While it's not included in the Intent to Implement, Element.role reflecting the content attribute by the same name has been suggested, presumably as a DOMTokenList. In that case another name is needed.

They almost certainly should be on HTMLElement, not Element.

They also probably should be getters, not methods.

As for name, I think it'd be confusing if `el.role` doesn't match `el.getAttribute("role")`.

(As to whether you need an `el.role` at all, I don't care: I personally think reflected attributes are useless and `getAttribute`/`setAttribute` work fine, but hey, we've reflected so many attributes already, what's one more?)

I agree about HTMLElement. It turns out that Simon has already cloned this into bug 27297, I'd suggest making the case there.

(In reply to Domenic Denicola from comment #6)
> They almost certainly should be on HTMLElement, not Element.
> 
> They also probably should be getters, not methods.
> 
> As for name, I think it'd be confusing if `el.role` doesn't match
> `el.getAttribute("role")`.
> 
> (As to whether you need an `el.role` at all, I don't care: I personally
> think reflected attributes are useless and `getAttribute`/`setAttribute`
> work fine, but hey, we've reflected so many attributes already, what's one
> more?)

My understanding is that this isn't a reflected attribute but returns the effective role (the first non-abstract role that is understood in the list).

Of course it's still nicer to call it role and have it be a getter. I don't see this as an HTML feature so I don't understand why it was cloned there. This is usable by SVG for instance. I reckon it could go into the DOM, or in its own spec extending the DOM (depending on who does the work).

(In reply to Anne from comment #4)
> Why do we put these on Element? 

Because roles and labels are not specific to HTML. Unless every display language inherits from HTMLElement, these should be on Element.

> Why are they methods? 

Callable methods might be better for implementation performance (lazy getters) since this would have to spin up additional accessibility code in most UAs. If properties can be lazy getters, too, that's fine.

> And why can't computedRole just be role?

role should be a the read/write reflected attribute. computedRole is the readonly calculated value of the matched role. For example:

var el = document.createElement("h1");

console.log(el.getAttribute("role")); // ""
console.log(el.role); // ""
console.log(el.computedRole); // "heading" (no other way to get this via the DOM)

// reset the value
el.setAttribute("role", "foo link");
console.log(el.role); // "foo link"

// computed role is ~ first recognized/implemented role, or default for tagName.
console.log(el.computedRole); // "link"

el.removeAttribute("role");
console.log(el.computedRole); // "heading" (back to the default)

(In reply to Alice Boxhall from comment #2)
> I'm slightly unconvinced about the name 'computedLabel' as to me it sounds
> like it might return an HTMLLabelElement. Would 'computedName' work?

"name" is ambiguous because it means different things across different accessibility APIs and even in host languages. For example, in HTML @name is like a non-unique @id. 

ARIA uses the term "label" consistently, so I'm not convinced this would be a point of confusion for authors. It's consistent with the meaning used in <label>, @aria-label, @aria-labelledby, and other API uses.

What should computedRole do that would require spinning up additional accessibility code? Isn't it simply the first recognized token in the role attribute, or the default role of the element failing that?

Is falling back to the default role of the element important? That detail increases the amount of testing required by a lot, as it brings in https://html.spec.whatwg.org/#wai-aria and any other vocabulary-specific mapping tables.

(In reply to James Craig from comment #9)
> Because roles and labels are not specific to HTML. Unless every display
> language inherits from HTMLElement, these should be on Element.

With "display language" you mean SVG and HTML? Unless role="" is supported regardless of namespace, putting them on Element might not be a good idea. (We are trying to see if this can work for class="" and id="" but nobody has implemented that so I'm not sure why we would go there for role...)


> > And why can't computedRole just be role?
> 
> role should be a the read/write reflected attribute. computedRole is the
> readonly calculated value of the matched role.

I think it would be fine for role to serve both those purposes. That's what e.g. <input>.type does too. If you want the actual value you can just use getAttribute("role").

(In reply to Anne from comment #12)
> (We are trying to see if this can work for class="" and id="" but nobody has
> implemented that so I'm not sure why we would go there for role...)

I tested this just now, className and id have moved to Element in Blink, Gecko and WebKit. Only IE is left.

(In reply to Philip Jägenstedt from comment #11)
> What should computedRole do that would require spinning up additional
> accessibility code? Isn't it simply the first recognized token in the role
> attribute, or the default role of the element failing that?
> 
> Is falling back to the default role of the element important? That detail
> increases the amount of testing required by a lot, as it brings in
> https://html.spec.whatwg.org/#wai-aria and any other vocabulary-specific
> mapping tables.

wondering whether getComputedrole will return ARIA abstract of elements accessibility API mapping? If so what is done in cases where there is no ARIA equivalent (of which there are many).

Also currently role mappings are only represented in acc APIs as ARIA role values , when the ARIA role value is used by the APIs because their is not an acc API equivalent, most landmark roles, for example.

Note https://html.spec.whatwg.org/#wai-aria is not used as an implementation reference by any implementers as far as I know (blink/Firefox/IE/webkit), because it is stale and does not match actual implementations in some cases and only provides a limited subset of implementation information which has to be then mapped back to the ARIA spec

For HTML acc layer implementation this is the spec that is used http://rawgit.com/w3c/aria/master/html-aam/html-aam.html

Mapping to Existing WAI-ARIA Role Semantics
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#mapping-to-existing-wai-aria-role-semantics

HTML Element Role Mappings
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#html-element-role-mappings

for conformance checker stuff the requirements are being defined here:
https://specs.webplatform.org/html-aria/webspecs/master/

(In reply to steve faulkner from comment #14)
> (In reply to Philip Jägenstedt from comment #11)
> > What should computedRole do that would require spinning up additional
> > accessibility code? Isn't it simply the first recognized token in the role
> > attribute, or the default role of the element failing that?
> > 
> > Is falling back to the default role of the element important? That detail
> > increases the amount of testing required by a lot, as it brings in
> > https://html.spec.whatwg.org/#wai-aria and any other vocabulary-specific
> > mapping tables.
> 
> wondering whether getComputedrole will return ARIA abstract of elements
> accessibility API mapping?

I don't know the correct terminology, but yes, I'm wondering if this API will expose the default role of every known element type, requiring a mapping table.

Some use cases and examples of how to use the API could help clarify, I don't know the core issue and https://www.w3.org/WAI/PF/Group/track/issues/427 is not public.

The main use-case I have in mind is feature/capability detection. As new ARIA roles are added, and more generally as the ARIA spec improves, web authors need a way to determine whether a particular user agent supports those features, and provide a polyfill if not.

In the case of ARIA roles, a computedRole() interface would allow a web app to determine whether a particular role is recognized, and if not provide an appropriate substitute. While there's existing support for listing multiple roles, the interaction between ARIA roles in the DOM hierarchy is pretty important and web authors might want more control over them.

As for computedLabel(), one of the possible future enhancements proposed for ARIA is the ability to specify elements that don't have an id, for ARIA attributes that currently require an IDREF. For example, instead of aria-labelledby="foo", two proposed ideas would allow you to use a querySelector string in place of the IDREF, or to use JavaScript to associate a specific DOM element with another element's ariaLabelledBy reflected attribute.

If either of these ideas makes it into the ARIA standard, authors might be wary of taking advantage of them when they're not supported in all browsers. Having computedLabel() provides a convenient alternative: use it to test for the presence of the new feature, and provide a polyfill if not.

(In reply to Dominic Mazzoni from comment #16)
> The main use-case I have in mind is feature/capability detection. As new
> ARIA roles are added, and more generally as the ARIA spec improves, web
> authors need a way to determine whether a particular user agent supports
> those features, and provide a polyfill if not.
> 
> In the case of ARIA roles, a computedRole() interface would allow a web app
> to determine whether a particular role is recognized, and if not provide an
> appropriate substitute. While there's existing support for listing multiple
> roles, the interaction between ARIA roles in the DOM hierarchy is pretty
> important and web authors might want more control over them.

Would a static boolean isRoleSupported(DOMString role) suffice for this purpose? That seems like the simplest possible API for detecting support for a role, and seems trivial to implement.

(In reply to Philip Jägenstedt from comment #17)
> (In reply to Dominic Mazzoni from comment #16)
> > The main use-case I have in mind is feature/capability detection. As new
> > ARIA roles are added, and more generally as the ARIA spec improves, web
> > authors need a way to determine whether a particular user agent supports
> > those features, and provide a polyfill if not.
> > 
> > In the case of ARIA roles, a computedRole() interface would allow a web app
> > to determine whether a particular role is recognized, and if not provide an
> > appropriate substitute. While there's existing support for listing multiple
> > roles, the interaction between ARIA roles in the DOM hierarchy is pretty
> > important and web authors might want more control over them.
> 
> Would a static boolean isRoleSupported(DOMString role) suffice for this
> purpose? That seems like the simplest possible API for detecting support for
> a role, and seems trivial to implement.

This (In reply to James Craig from comment #9)
> (In reply to Anne from comment #4)
> > Why do we put these on Element? 
> 
> Because roles and labels are not specific to HTML. Unless every display
> language inherits from HTMLElement, these should be on Element.
> 
> > Why are they methods? 
> 
> Callable methods might be better for implementation performance (lazy
> getters) since this would have to spin up additional accessibility code in
> most UAs. If properties can be lazy getters, too, that's fine.

+1 for read-only lazy properties (this is how I've been implementing it, in fact.)

(In reply to James Craig from comment #10)
> (In reply to Alice Boxhall from comment #2)
> > I'm slightly unconvinced about the name 'computedLabel' as to me it sounds
> > like it might return an HTMLLabelElement. Would 'computedName' work?
> 
> "name" is ambiguous because it means different things across different
> accessibility APIs and even in host languages. For example, in HTML @name is
> like a non-unique @id. 
> 
> ARIA uses the term "label" consistently, so I'm not convinced this would be
> a point of confusion for authors. It's consistent with the meaning used in
> <label>, @aria-label, @aria-labelledby, and other API uses.

The algorithm to compute the string which would be returned from this method is called the "Accessible Name Calculation" algorithm (http://www.w3.org/TR/wai-aria/roles#namecalculation) so I don't think it's really all that consistent.

Both "name" and "label" are fairly overloaded at this point, and I think "name" better represents this concept - see also the general accessibility concept of Name (in the context of Name, Role, State and Value), e.g. http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

(In reply to Alice Boxhall from comment #19)
> (In reply to James Craig from comment #10)
> > (In reply to Alice Boxhall from comment #2)
> > > I'm slightly unconvinced about the name 'computedLabel' as to me it sounds
> > > like it might return an HTMLLabelElement. Would 'computedName' work?
> > 
> > "name" is ambiguous because it means different things across different
> > accessibility APIs and even in host languages. For example, in HTML @name is
> > like a non-unique @id. 
> > 
> > ARIA uses the term "label" consistently, so I'm not convinced this would be
> > a point of confusion for authors. It's consistent with the meaning used in
> > <label>, @aria-label, @aria-labelledby, and other API uses.
> 
> The algorithm to compute the string which would be returned from this method
> is called the "Accessible Name Calculation" algorithm
> (http://www.w3.org/TR/wai-aria/roles#namecalculation) so I don't think it's
> really all that consistent.
> 
> Both "name" and "label" are fairly overloaded at this point, and I think
> "name" better represents this concept - see also the general accessibility
> concept of Name (in the context of Name, Role, State and Value), e.g.
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

Also, the "nameFrom" property in the ARIA spec.

(In reply to steve faulkner from comment #14)
> (In reply to Philip Jägenstedt from comment #11)
> > What should computedRole do that would require spinning up additional
> > accessibility code? Isn't it simply the first recognized token in the role
> > attribute, or the default role of the element failing that?
> > 
> > Is falling back to the default role of the element important? That detail
> > increases the amount of testing required by a lot, as it brings in
> > https://html.spec.whatwg.org/#wai-aria and any other vocabulary-specific
> > mapping tables.
> 
> wondering whether getComputedrole will return ARIA abstract of elements
> accessibility API mapping? If so what is done in cases where there is no
> ARIA equivalent (of which there are many).

I think it should, yes. In the case where there is no ARIA equivalent, I think it makes sense to return null.

> Also currently role mappings are only represented in acc APIs as ARIA role
> values , when the ARIA role value is used by the APIs because their is not
> an acc API equivalent, most landmark roles, for example.

True, but knowing the computed ARIA role in other cases means that we can reason about what native accessibility API role will be chosen, if necessary, as there is a standard mapping. The ARIA role set gives us a consistent cross-platform API.

I think we just need to add ARIA roles for all of the mappings that don't have them yet. It's pretty ridiculous that the only way I can get IA2_ROLE_PARAGRAPH is with a <p> element, and I can't do it with the `role` attribute. In general we don't want browsers reserving such capabilities for their own list of privileged elements.

(In reply to Domenic Denicola from comment #22)
> I think we just need to add ARIA roles for all of the mappings that don't
> have them yet. It's pretty ridiculous that the only way I can get
> IA2_ROLE_PARAGRAPH is with a <p> element, and I can't do it with the `role`
> attribute. In general we don't want browsers reserving such capabilities for
> their own list of privileged elements.

I agree, but I don't see how that affects this proposal.

(In reply to Philip Jägenstedt from comment #13)
> I tested this just now, className and id have moved to Element in Blink,
> Gecko and WebKit. Only IE is left.

Yes, the properties have, but what about class="" and id=""? Fairly certain they are not universally supported.

(In reply to Alice Boxhall from comment #23)
> I agree, but I don't see how that affects this proposal.

It does if we want to make .role return the mapping that ends up being used, but accept a sequence of mappings as input. It would be weird for it to return something you cannot set. And I think that's the only API that makes sense for .role, similar to <input>.type.

(In reply to Alice Boxhall from comment #18)
> (In reply to Philip Jägenstedt from comment #17)
> > (In reply to Dominic Mazzoni from comment #16)
> > > The main use-case I have in mind is feature/capability detection. As new
> > > ARIA roles are added, and more generally as the ARIA spec improves, web
> > > authors need a way to determine whether a particular user agent supports
> > > those features, and provide a polyfill if not.
> > > 
> > > In the case of ARIA roles, a computedRole() interface would allow a web app
> > > to determine whether a particular role is recognized, and if not provide an
> > > appropriate substitute. While there's existing support for listing multiple
> > > roles, the interaction between ARIA roles in the DOM hierarchy is pretty
> > > important and web authors might want more control over them.
> > 
> > Would a static boolean isRoleSupported(DOMString role) suffice for this
> > purpose? That seems like the simplest possible API for detecting support for
> > a role, and seems trivial to implement.
> 
> This

Not sure if this was copypasta or if your reply was truncated :)

(In reply to Philip Jägenstedt from comment #26)
> (In reply to Alice Boxhall from comment #18)
> > (In reply to Philip Jägenstedt from comment #17)
> > > (In reply to Dominic Mazzoni from comment #16)
> > > > The main use-case I have in mind is feature/capability detection. As new
> > > > ARIA roles are added, and more generally as the ARIA spec improves, web
> > > > authors need a way to determine whether a particular user agent supports
> > > > those features, and provide a polyfill if not.
> > > > 
> > > > In the case of ARIA roles, a computedRole() interface would allow a web app
> > > > to determine whether a particular role is recognized, and if not provide an
> > > > appropriate substitute. While there's existing support for listing multiple
> > > > roles, the interaction between ARIA roles in the DOM hierarchy is pretty
> > > > important and web authors might want more control over them.
> > > 
> > > Would a static boolean isRoleSupported(DOMString role) suffice for this
> > > purpose? That seems like the simplest possible API for detecting support for
> > > a role, and seems trivial to implement.
> > 
> > This
> 
> Not sure if this was copypasta or if your reply was truncated :)

It was a reply I didn't mean to send; I was blindsided by Bugzilla!

(In reply to Anne from comment #25)
> (In reply to Alice Boxhall from comment #23)
> > I agree, but I don't see how that affects this proposal.
> 
> It does if we want to make .role return the mapping that ends up being used,
> but accept a sequence of mappings as input. It would be weird for it to
> return something you cannot set. And I think that's the only API that makes
> sense for .role, similar to <input>.type.

I see. I think `role` would be best simply reflecting the string "role" attribute verbatim, regardless of what is applied - this is why we need `computedRole` as, as you point out, this may be quite different to `role` or even return a value if `role` is not set.

Regarding reflecting ARIA attributes: there have been proposals kicking around for this on the PFWG bug tracker (https://www.w3.org/WAI/PF/Group/track/issues/438) for some time - if this is something we'd like to discuss here, I can file a separate bug for it as I think these distinct (albeit related) issues (since, as Dominic points out, we can always use getAttribute to get the verbatim string attribute).

(In reply to Alice Boxhall from comment #28)
> I see. I think `role` would be best simply reflecting the string "role"
> attribute verbatim, regardless of what is applied - this is why we need
> `computedRole` as, as you point out, this may be quite different to `role`
> or even return a value if `role` is not set.

That seems like a bogus design. Why have .role do that? That seems perfectly serviced through getAttribute()/setAttribute(). When possible we make IDL attributes useful and it seems we can make this one perfectly useful, just need to fix the design of role="" a bit.

HTML5.1 Bugzilla Bug Triage: 

This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).