Deprecate rather than remove aria-expanded from static roles

[WilcoFiers]

In PR #972, aria-expanded was removed as an allowed property of various static roles. This will create a significant backward incompatibility between ARIA 1.2 and 1.3. Browser, assistive technologies, and accessibility test tools don't just support a single version of ARIA. This is a continuum. Very similar to issue #1164, I think these attributes need to be added back and set up as deprecated.

You may also want to consider creating a "Deprecated states and properties" row, rather than add this bold "deprecated on this role in ARIA 1.2" bit at the end of the attributes. Personally I think that would be a cleaner way to organize that information, but that's up to the group.

[scottaohara]

Note that this PR was part of what became ARIA 1.2. So this is a difference between ARIA 1.1 and ARIA 1.2.

The rational behind the change is that the attribute wasn't meant for the elements it was removed from, and in reality - outside of firefox - the aria-expanded state is either not exposed at all, or inconsistently on a scant few elements.

I personally find it odd that this was never accounted for by automated checkers before - saying it's ok to use an attribute that has incredibly poor support on various elements it was noted it could be used on. I know that axe, for instance, has purposefully flagged instances of attributes which did not have wide support in the past. Arguably, even if the attribute were not to have been removed, checkers should have been similarly flagging it for being poorly supported for these elements - under the same rational for flagging attributes which were actrually meant to be valid but did not yet have good enough support.

But for some data - retesting today I can confirm the following:

In chromium with JAWS and NVDA, aria-expanded is only announced on a cell if it is keyboard focused. NVDA will also announce the expanded state if navigating with its reading mode. It's ignored for all other instances.

Webkit and Chromium browsers on macOS do not expose the expanded state at all on all elements it was removed from.

JAWS and Firefox have a small handful of elements that expose an expanded state
if keyboard focused:

• cell
• directory (exposed as a listbox because JAWS thinks someone has messed up in creating a listbox pattern)
• list / listitem (see above)
• menu
• term

the following two roles expose the expanded state if navigating with virtual cursor

• menu
• tree

NVDA and VoiceOver specifically with Firefox does announce the expanded state on all or almost all elements it is used on.

[WilcoFiers]

Thanks for the clarification Scott. I'm not sure how I missed that this got pulled in ARIA 1.2. Little disappointed in myself that I did to be honest!

I can't speak for other checkers, but when it comes to axe we only report things as not being supported by AT if 1. if we know about it, which we don't always do, and 2. if we're relatively confident its use will result in an actual accessibility problem. Take your new aria-braillelabel attribute as an example. Whether or not that's widely supported really doesn't matter as long as there's an accessible name as a fallback. Even if you end up pulling it from 1.3 (or 1.4), axe will likely never fail it.

ARIA not being backward compatible is a problem for us. Checkers can't simply remove allowed attributes like they never existed. It's fairly reasonable to say that aria-expanded isn't valid on these roles for components built today. Its far less so to do that for components built in 2018. It shouldn't be reported in the same "category" as attributes that were never supported by a role. That's the major benefit of deprecating these attributes over simply removing them is.

By not being backward compatible ARIA is forcing checkers into deciding between staying true to the spec, or staying backward compatible. Axe-core generally leans towards backward compatibility (we still let people use role="text"). Had these attributes been deprecated rather than removed, this wouldn't have been on the backlog for ages. I know ACT has also struggled with this question. There we have largely kept in the possibility for tools to continue allowing things removed from prior versions of ARIA.

@jnurthen Would it be worth having a meeting between ACT and ARIA during TPAC to talk about this topic?

[scottaohara]

understood @WilcoFiers. we actually had a very similar conversation when I made this PR to axe at the start of 2022 to remove the errant indication of support for aria-expanded to coincide with the ARIA update. Little did we know it'd take another year and a half for ARIA to actually go to rec...

I left that conversation under the impression that axe would have been creating its own messaging to let people know of this change, though you were very clear on your thoughts about what ARIA could have done / have restated them here.

quickly re:

It's fairly reasonable to say that aria-expanded isn't valid on these roles for components built today. Its far less so to do that for components built in 2018.

i would submit that support was relatively similar to now, since when the PR was made back then - we did so because of the lack of support for the attribute. I've even just re-checked with some older builds of browsers/screen readers that I keep specifically for testing, and finding similar support to what I've already mentioned.

I'm going to pause my response here. I'm sure there are others in the wg that have their own thoughts to add.

[spectranaut]

Added F2FCandidate to further discuss deprecation practices, specifically, a "deprecated" or "removed" section of the specification with advice to validators.

[spectranaut]

Discussed during triage this morning: https://www.w3.org/2023/08/03-aria-minutes#t01

[WilcoFiers]

I would love such a section in the spec! I'm indifferent on whether that should be deprecated or removed, as long as its consistent and clearly documented. I don't think it makes sense for some of them to get deprecated, and for others to get removed.

You may also want to consider some guidance on what user agents should do with these. Should they pull anything deprecated out? Leave it in? Should they add things even if they are deprecated? It would be useful to give a direction there too, if nothing else just to set expectations of developers.

[MarioBatusic]

The simplest way for validator software were to have a stated ARIA version in the document. But this possibility we have lost because this was not required from the beginning.

To declare some attribute / role as not working in a new versionwe should state it as deprecated. But I see a problem in that - as in the case of "expanded" it shoul be deprecated only for some roles and not generally. So I'm not sure about the best solution.

[scottaohara]

i just don't see any practical value in validating against previous versions of the spec - where things that were changed/removed were done for good reason. e.g., lack of support for aria-expanded on roles is wasn't meant to be used with. Or the aria 1.1. combobox pattern which is acknowledged as broken in ARIA 1.2, but if one were to validate against ARIA 1.1 it'd be "fine" - regardless of it actually being a broken experience for people. How is that at all helpful to anyone but a developer trying to get out of updating their code?