[Bug 27294] DOM needs a way to get element's computed ARIA role and computed label string

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

--- Comment #18 from Alice Boxhall <aboxhall@chromium.org> ---
(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.)

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

Received on Friday, 19 December 2014 00:12:52 UTC