The Roles model introduces a potential timing problem

[jnurthen]

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

The spec currently states here http://w3c.github.io/aria/aria/aria.html#roles

"Roles are element types and authors must not change role values over time or with user actions. Authors wishing to change a role must do so by deleting the associated element and its children and replacing it with a new element with the appropriate role. Typically, platform accessibility APIs do not provide a vehicle to notify assistive technologies of a role value change, and consequently, assistive technologies may not update their cache with the new role attribute value."

... and Core-AAM also states here http://www.w3.org/TR/core-aam-1.1/#mapping_conflicts

"Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided that has a corresponding role in the accessibility API, user agents must use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language."

Which leaves open the possibility (at the very least in HTML) that a document may load with elements that are mapped natively to accessibility roles to which WAI-ARIA roles are added programmatically at a later point (using for example JavaScript) (this is common in practice with the 1.0 version of the specification).

If a platform does not have the ability to override the role once something has been exposed through the accessibility API, then this introduces a timing problem that could lead to incompatibilities across platforms.

[jnurthen]

@dylanb Just digging through some old issues... Have you ever encountered this actually being a problem? If it is do you have any ideas as to how to resolve it?

[dylanb]

I have not but I wanted to raise it because it is a potential problem that the spec needs to address

[jnurthen]

Any ideas how to resolve then? Otherwise I'm going to set a future milestone on it.

[accdc]

Hi,
I'm a bit confused, since this was in 1.0 as well.

"6. Platform accessibility APIs typically do not provide a vehicle to notify assistive technologies that a role has changed. Due to this and document caching, assistive technologies are unlikely to process a change in role attribute value. Authors who wish to change a role are advised by the WAI-ARIA specification to delete the associated element and its children and replace it with a new element having the appropriate role. If a role is changed, however, user agents SHOULD update the mapping in order to reflect the content in the DOM. Since assistive technologies will not know that the role has changed, user agents MAY address this error condition by treating it as removing a subtree item and inserting a new one as described in Changes to document content or node visibility."
http://www.w3.org/WAI/PF/aria-implementation/#mapping_role

[dylanb]

I think the best way to resolve it is to differentiate between changes from implicit roles and explicit roles. Implicit roles should be allowed to be changed at any point but then once changed, they become (obviously) explicit. Explicit roles should adhere to the current language (must replace the element to change the role).

[accdc]

Unfortunately the processes involved are the same, so this couldn't work as just a spec change. This goes back to when I worked with Joseph, Rich, and Joanie on the UAIG, and it has to do with accessibility API events.

I do see the value of doing this, but it would require all of the browsers to agree to implement a new event within their accessibility APIs, such as a role_changed event, which could then be used to identify where and when this occurred so that assistive technologies could then use this information to update their own displays as well. Without that, the functionality won't ever work reliably.

James, do you want to put this on the agenda for the FTF when we all meet? The browser reps can weigh in then.

[jnurthen]

See #986

[jnurthen]

Closed by #986