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?

[stes-acc]

How is that at all helpful to anyone but a developer trying to get out of updating their code?

Because the majority of people implementing ARIA are developers. Maybe I am biased because I work frequently with them and do not underrate the related effort.

[scottaohara]

i'm not following your response, as it either seems to misunderstand my point, or you are advocating that developers shouldn't have to update code that either provides no value or is problematic for users - because it validates with a previous version of the spec.

[stes-acc]

I am advocating that developers shouldn't have to update code because validators complain for they have rulesets for latest ARIA. The problem is also that devs take ARIA spec for serious, if something is allowed there and in next iteration forbidden, it will cause distrust. This is of course a slightly other topic but the impact on rulesets of validators its obvoius.

[stevefaulkner]

If something does not work, has never worked, then obsolete it.

[stes-acc]

Now we are talking - should validators flag obsolete as an error or as a warning ? Or should they handle obsolate stuff in their rule sets as special case?

[stevefaulkner]

@stes-acc Error, but I would ask @sideshowbarker what he thinks since he is one of the Lords of validation

[scottaohara]

marking stuff as obsolete makes sense, but it doesn't address the point i was trying to make about validating against specific versions of the spec and why i think the idea that doing so would somehow fix this problem should even be entertained. e.g., something marked as obsolete in ARIA 1.3 because it was useless/a bug with the previous spec wouldn't be surfaced if someone was validating against the 1.1 version of the spec (unless the validator indicated that there was code that didnt' validate against future versions of the spec - but if it's going to do that, then... that's weird too). That problem would still exist, it'd still be a useless/broken experience for the user - but hey, no problem because it validates against 1.1. That's rubbish.

[stevefaulkner]

@scottaohara i would make it an error and ignore any nonsense about versioning.

[scottaohara]

we are in agreement :)

[sideshowbarker]

Speaking only from my POV as a maintainer of the Nu HTML Checker (W3C validator):

As far as the point about not validating against specific versions of the spec (versioning): I agree — and the HTML checker anyway intentionally doesn’t support checking against any specific versions of any spec. Instead, the checks in the HTML checker are always made against the current specs — the latest available versions of any specs.

So in the case of the ARIA spec, whatever checks we add are based on what’s currently in the https://w3c.github.io/aria/ spec — and we completely ignore every other published ARIA spec version except that.

---

As far as the other point about marking something as obsolete in the ARIA spec: In the HTML checker we would support doing whatever the ARIA spec normatively defines. But I notice that the ARIA spec currently doesn’t yet have anything marked as “obsolete”, and doesn’t define what “obsolete” means.

In contrast,at https://w3c.github.io/aria/#deprecated the spec does define what it means by “deprecated”, and says:

…the older feature is marked as "deprecated". This indicates that the feature is allowed in the conformance model and expected to be supported by user agents, but it is recommended that authors do not use it for new content.

So for the purposes of relevant checks for ARIA-deprecated stuff to the checker, that “it is recommended” spec language makes it clear that the checker should emit a warning — not an error — for anything the ARIA spec flags as “deprecated”.

If in addition to any existing warnings the HTML checker emits for cases the ARIA spec marks as “deprecated”, the intent is that the checker would also emit errors for use of ARIA features that are obsolete — then the ARIA spec would need to define what “obsolete” means, and then add a new spec section with some language like this:

…the obsolete feature is marked as "obsolete". This indicates that … authors must not use the feature.

---

All that said, I’m not sure that currently the checker even does any checks based on any requirements in the ARIA spec itself. I could be wrong but anyway in the vast majority of cases at least, the ARIA-related checks the HTML checker does are based on requirements in the https://w3c.github.io/html-aria/ (ARIA in HTML) spec. So if some feature were to be marked as obsolete in the ARIA spec, then ideally maybe a corresponding change should be made to the ARIA in HTML spec.

[stes-acc]

So .. what remains after the dust has settled seems to be the following:

1. ARIA spec should indicate those incorrect ly allowed properties (e.g. aria-expanded and containments (e.g. group role in list) explicitely as "obsolete" and spend explainer what "obsolete" means.

2. Validators should treat the useage of obsolete stuff as an error no matter which ARIA version was used in scanned code.

3. Developers have to fix these errors although it once was incorrectly allowed in ARIA spec and are left alone with the respective effort.

Right?

[scottaohara]

well, that's still up for discussion re: this will be on the F2F meeting. This whole additional conversation was just because I was trying to squash the idea that validating against any specific version of the spec would somehow be helpful/have helped solve this issue. It wouldn't.

It was already mentioned (meeting minutes) that being clearer about removal/deprecation/obsolete expectations would be for ARIA 1.3+. So, anything that has already been revised/removed from ARIA 1.1 to ARIA 1.2 is done at this point, unless that plan somehow gets reversed.

My parting comment before saving the rest for the F2F meeting, is that the idea that validators are punishing devs is hyperbolic. If devs had actually implemented and tested any of the removed/changed bits before, they would have been met with little to no support, if not actually broken experiences when using AT. If people get surprised by getting errors flagged due to these changes in the spec, then IMO that's unfortunate, but also a good thing in the long run. They obviously weren't testing to know what they had built had problems. Now, they'll know. But, I acknowledge that going forward the spec could do a better job calling out the 'whys'. E.g., there's the changelog now - but it doesn't link to issues/PR containing the rational about why the changes were made. People have to dig for that. That is something that any new process going forward could help resolve.

[spectranaut]

Discussed at TPAC this week: https://www.w3.org/2023/09/14-wcag-act-minutes.html#t03