The author is advised against it, I would say, and user agents need to handle it by creating a new accessible object in place of the old one (assuming there was one previously created).

The author is advised against it, I would say, and user agents need to handle it by creating a new accessible object in place of the old one (assuming there was one previously created).

@aleventhal what does chromium do here? How about gecko and webkit?

Chrome and Gecko destroy the old object and create a new one.
It doesn't appear that WebKit does this, looking at the following source: https://github.com/WebKit/webkit/blob/master/Source/WebCore/accessibility/AXObjectCache.cpp#L1449
Because of that, as an author I would still be pretty cautious. Perhaps Apple has carefully tested all the potential edge cases with VoiceOver?( Are there any other platforms that matter wrt WebKit a11y)?
What should happen if a role changes within a complex structure. Perhaps the ancestor role changes, or perhaps a required descendant becomes an illegal one.
This was a bigger deal on Windows/ATK because of the binary interfaces that could change, e.g. suddenly the object should be exposing the AccessibleTable interface. On Mac, the API is more like a set of key/value pairs so this isn't as much of an issue probably.
Still, gives me pause. I'd see if you could ask them.
Originally we looked at the potential complexity in dealing with it and decided to advise authors against it, because we couldn't think of a use case to make it worthwhile.

BTW, setting the type attribute of an HTML <input> could have similar repercussions, and I wouldn't be surprised if it was really poorly tested and caused a11y bugs.

I've historically advised against this, but have discovered in recent years that the use cases for doing this are rather extensive.

For example, I was recently tasked with making the Slick.js Carousel accessible, and to do so, it required modifying the JS framework for all carousels as they are created with the proper roles and supporting attributes, and all of this had to be done within the Slick.js file itself, which programmatically modifies preconstructed user code and dynamically applies all carousel functionality. This was necessary so that clients could simply copy and plug the new Slick.js file into their own coding projects that spanned over a dozen websites and have the carousels in all of them work accessibly with them having to do nothing else to make it so.

You can examine the index.html file in the root of this repo to see what I mean.
https://github.com/accdc/slick

This is just one implementation like this, but the concept will have to apply to every JS library and framework in existence if people are going to be able to make these interactive widgets accessible in the future. It simply isn't feasible to have to recreate everything all the time.

So, the text in question has been removed. In addition, I opened w3c/core-aam#50 so we can add role to the event/notification-related mappings.

Warning: when the role attribute is changed on an existing element, most browser implementations destroy and recreate any corresponding accessibility objects. As a result, some internal browser and AT states tied to that object are generally thrown away, and events may or may not be re-fired. Changing from one role to another is not well-tested across browser-AT combinations, and unexpected behavior may occur. For example, if the selection or focus was currently on or inside the object, some browser implementations may re-fire related events, and some may not. Screen readers that tracked a users place within their own view (e.g. virtual buffer), may not gracefully handle the change. Content authors are therefore advised to either do extra testing, or at minimum to avoid changing the role of any object that may be currently focused or selected.

Before we add text which might not be factually accurate, I would like to do the following:

1. Come up with a concrete test case that we can test with all the main screen reader + user agent combinations
2. Determine if there really is a problem, if so: Try to get the screen readers to fix their bugs so that it's not a problem.

If it's really a problem and we cannot get fixes made in screen readers, ok, let's warn people.

Sorry I missed this in the Spring. There may be other implementation fallout, too. I know WebKit for example, does not update role changes properly on certain roles/elements like tables. I don't know if this is just a complicated "bug fix" or if there is some more serious implementation concern.

I'm not finding that bug now though, so it may have been resolved.

Given that there is renewed interest in this issue, reopening.

On Windows, AFAIK there is no event for a role change, so ATs that need to update any state may not know about the change unless the object is re-created.

Windows COM rules dictate that the set of interfaces supported by an object cannot change after the object has been created. So, changing a button to a table cell would cause problems. (Practically speaking, I think what will happen is that the AT may be told there's no table cell interface even after the change, since that result will have been cached from before.)

So, I don't think it's possible to support role changing without re-creation in some cases. I think we can try to eliminate re-creation for specific cases (though we may need to add a role change event in IA2), but for other cases (button -> table cell), we need to re-create.

The problem with object re-creation is that an AT has no way to know the new object was in any way related to the old one. In a lot of cases, this isn't really a big deal; if it's changing role so drastically, it's probably changing in a pretty significant way, so that's okay.

In short, I don't know that we need to prohibit role changing, but authors do need to be aware that the accessible might get re-created.

Tested change role with JAWS:

• ok with Chrome and Firefox (current role is output correctly)
• not ok with IE 11: current role is not output (but the status of the current role. For example, if role=link is changed to role=checkbox, JAWS will output "link not checked"). The role is output correctly if INS+ESC was pressed, which causes the DOM to be re-read.

With NVDA, the current role is correctly output for all three browsers (IE 11, Chrome, Firefox)

In short, I don't know that we need to prohibit role changing, but authors do need to be aware that the accessible might get re-created.

@jcsteh To play devil's advocate, user agents destroy and recreate objects fairly often, sometimes even upon focus. And we don't warn authors about that. Should we be figuring out all the reasons user agents do that and add warnings to the appropriate spec(s)?

user agents destroy and recreate objects fairly often, sometimes even upon focus. And we don't warn authors about that.

That's fair. However, it's also fair to argue that these are UA deficiencies that can be fixed (putting aside the difficulty of fixing these issues). For example, Firefox before 70 would re-build an a11y subtree if its associated layout frame was re-created by layout. In Firefox 70, we went to a fair bit of effort to fix this (finally!) because it causes all sorts of pain.

In contrast, re-creating the accessible for at least some of these role changes is not something a UA can ever reasonably fix.

FWIW, I recently tested how well different AT process role changes. I only have a single test, but it appears that the vast most AT/browser combinations do just fine. Of course, there are a lot of factors that play into this, and my test is not comprehensive. https://a11ysupport.io/tech/html/role_attribute#support-table-2

Hi @mfairchild365, a fair test would include something like:

• When focus is inside the the node that changes roles, e.g. focus is on a button that changes to a radio, and they are inside of a role="group", which changes to a role="main"
• When caret/selection is inside the node that changes roles, e.g. in a contenteditable

These should be tried when not in virtual cursor mode. My thought is that when the role changes, most browsers will destroy the object and create a new one, so any state would be destroyed with it, and the user may now be lost -- the screen reader might send them to the top of the document.

If that doesn't occur, then great!

@aleventhal that's a good point. While I didn't have time to test exactly what you suggested, I did add a test to ensure that the browsing caret location is not lost when a parent container's role changes from note to a named region. All AT/browser combinations that I tested with pass this, except NVDA with Chrome.

I'm curious why it is important to try the test cases that you suggested when not in virtual cursor mode. Can you explain that further?

Aaron: Do you still think this language is needed?

@joanmarie , what would you like to replace it with? Also, we might need to test what happens in various browser-AT combinations when there is a caret position inside of an object with a role change. Is it as simple as doing nothing and it all just works? If I didn't know how stuff was implemented, I would assume that was an ok thing to do as an authors, and right now we only hope that it works, no one really knows.

BTW, regarding this comment from @jcsteh, he helped me get a change into IA2 to include a new role changed event, although no one is implementing it yet:

On Windows, AFAIK there is no event for a role change, so ATs that need to update any state may not know about the change unless the object is re-created

@joanmarie , what would you like to replace it with? Also, we might need to test what happens in various browser-AT combinations when there is a caret position inside of an object with a role change. Is it as simple as doing nothing and it all just works? If I didn't know how stuff was implemented, I would assume that was an ok thing to do as an authors, and right now we only hope that it works, no one really knows.

Nothing unless and until we really know. 🙂

Perhaps we could do some local testing in Chromium in which we stop the destruction and recreation, emit the right event, and see what (if anything) breaks. And if something breaks due to screen reader failure, perhaps we can file bugs against those screen readers. And once everything is working as expected, then there's nothing to warn authors about.

That sounds good.

closing this because the issue being discussed as changed from the original issue which was resolved: #1798