WICG
What are the use cases for changing an accessible node's role?
It seems plausible to me that they exist, but I can't think of any...
This informs a number of the existing design choices, e.g. how certain properties only work when the role is set in a certain way.
Changing a static element (heading, cell, etc.) to an editable node (textfield, etc). The ideal way would be to use a new node, but many web authors just add a contenteditable attr on the element. We need to be able to support what authors currently do.
Changing an accessible node's role is no different than adding the "role" attribute to the HTML, so the use cases are the same as the use cases for doing so in ARIA, right?
I think the key here is that we're not trying to reinvent the semantics.
A typical use case is that you made your own toggle control and want to make it accessible, so you add ARIA:
<div role="checkbox" tabindex=0 aria-checked="false">...</div>
You're not allowed to use aria-checked if the role isn't one of the allowed roles, like "checkbox" or "radio".
The AOM simply gives you a programmatic way to do this without decorating the DOM with attributes. For some checkboxes there's no difference. When the checkbox is a web component or when it's a lightweight object in a canvas without a backing DOM object, the AOM provides a clear improvement.
Feel free to reopen if this isn't clear or if I misunderstood!
Changing an accessible node's role is no different than adding the "role" attribute to the HTML, so the use cases are the same as the use cases for doing so in ARIA, right?
That might be the case, but it's not clear whether such use cases exist, or whether this just fell out of the fact that all HTML attributes are mutable and ARIA was stuck with HTML attributes as a technology. @cookiecrook gave an example of an actual use case which was helpful, and it would be ideal to have more than just that one use case.
Your example seems to be omitted (maybe you didn't escape the HTML?) so I can't tell what point it was trying to make, but does it illustrate transitioning from one role to another, or just transitioning from an initial no-role state to having a role?
Escaped my HTML.
The entire purpose of ARIA is to add missing semantics to HTML, and modifying the "role" is the central way to do this.
This is not unique to the web, most accessibility APIs on other platforms have a concept of "role" that behaves exactly this way. The others have multiple attributes or traits that together determine the role.
Some common use cases:
- Adding semantics that don't have corresponding HTML elements at all, like "feed" or "toolbar".
- Creating a custom control like a custom button, checkbox, listbox
- Filling in the missing semantics when an already existing element is extended with extra behavior - for example an may pop up a drop-down list of suggestions so we give it a role of "combobox"
- Adding structure like lists or tables, when the author didn't use the native element, sometimes for performance or layout reasons
- Fixing an existing site where the author didn't use semantics tags where they could have - i.e. they could have used tags like article, aside, header, footer, main, h2, h3, etc. and now they want to improve accessibility without breaking their site, because their CSS or JS assumes certain tags. Not a "great" use case but realistically a common one.
Your example seems to be omitted (maybe you didn't escape the HTML?) so I can't tell what point it was trying to make, but does it illustrate transitioning from one role to another, or just transitioning from an initial no-role state to having a role?
Fixed, but both are common. Lots of HTML elements like DIV have essentially no role, and need one. Sometimes HTML elements have an appropriate role like has a role of "textbox" by default, but there are often more specific roles like "searchbox" or "combobox" that are more useful for users.
ARIA disallows using accessibility attributes to obscure or break native semantics. For example you can't use aria-checked to make a native INPUT type=checkbox appear checked when it's not or vice-versa. However, you can use aria-checked to add the missing semantics to a custom control that behaves like a checkbox but isn't implemented using an INPUT.
If I may, I think Domenic (@domenic) is asking for use cases to reassign an element's role once it's already been explicitly set. Dominic (@minorninth) is responding with use cases to initially set the role, or change it from the element's default role.
Yes, that's exactly the disconnect, thanks @cookiecrook :). I think I understand roles in general and the purpose of allowing us to assign them to native elements. But in discussions with @slightlyoff, he was unsure on the value of reassigning an element's role, and noted that if this was not allowed, a very different API could be used, e.g. one in which there's a class hierarchy of different AccessibleNode types for each role, instead of a generic AccessibleNode with a role that can change over time.
I think @cookiecrook's example (of contenteditable-like behavior) is probably enough to argue for the spec's current design of mutable roles, but it would be good to have more.
It also seems like having a hierarchy of types further entrenches us into having a sealed-shut vocabulary of roles vs. having role as a string.
It depends on whether authors are allowed to extend the hierarchy. It's somewhat easier to imagine extensibility via subclassing than via some kind of way of adding to a global registry of strings.
@domenic wrote:
But in discussions with @slightlyoff, he was unsure on the value of reassigning an element's role, and noted that if this was not allowed, a very different API could be used, e.g. one in which there's a class hierarchy of different AccessibleNode types for each role, instead of a generic AccessibleNode with a role that can change over time.
ARIA disallows (or at least discourages) changing the role, but I am not certain any browsers enforce this restriction. It is possible this could cause implementation problems on some platform, and if so, we should change the spec to disallow role mutability.
The only browser problem I know of is that WebKit (and probably Blink) doesn't allow a table element's role to be reassigned once the AccessibilityTable has been instantiated. This issue hasn't been problematic enough to warrant deeper diagnosis yet. IOW, I'm not sure whether this is correct behavior, a bug, or a more fundamental limitation.
Oh, that's a good point. I remember from some testing a while ago that I was able to change the ARIA role using setAttribute before inserting something into the DOM, but once the node was in the DOM, updating the role attribute did not seem to change the accessibility tree as present in chrome://accessibility. It does sound like this deserves some further investigation.
Hmmm, you're right wrt changing the role not getting reflected immediately in Chrome's accessibility tree. I filed http://crbug.com/642469, but that's not the intended behavior. I'd say that changing the role once you've set it the first time is not really a key use case, but it probably ought to work.
I guess we should try to clarify that the purpose is to set the role once, not to make it a dynamically changing state like aria-checked.
I guess we should try to clarify that the purpose is to set the role once, not to make it a dynamically changing state like aria-checked.
If that's the case it would be good to change the API to make role readonly, and to have the role be a constructor argument to AccessibleNode, I think.
What if you want to get the accessible node for an existing DOM element and change its role?
The AccessibleNode constructor is intended to be used when you want to create a node from scratch that doesn't correspond to a DOM node.
Most often you'll access AccessibleNode from a DOM node and add semantics, so you can inherit a lot that comes for free.
I don't think we can make role readonly or write-once. It would be reasonable to clarify that it's not something you're supposed to keep changing dynamically, but it's an important use case to modify it once sometime after its DOM node was created - for example some apps may build the GUI and then decorate it with accessibility later. Even better, it might be possible to defer accessibility code from running at all until it's needed, for a bigger performance win.