It turns out that none of the screen readers I've tested with so far even speak removals when aria-relevant contains removals. I tested VoiceOver, NVDA and JAWS with Safari, Firefox and Chrome.

I got similar results. Wouldn't aria-atomic=true monitor that space where aria-relevant was intended?

That's weird, some years back I wrote the section at
http://whatsock.com/training/#hd25

Which references the example of aria-relevant at
http://whatsock.com/training/demos/lr/aria-live-polite-removals.html

I just ran the example page in IE11 and in Firefox using the latest release of JAWS2018, and removals are indeed being announced in both browsers. I'm using Windows7.

@devarshipant I'm not sure what you mean. The aria-atomic attribute basically ensures that if something inside an element changes, that the entire region is always spoken for any update, rather than just a part.

@accdc I was able to repro your results with JAWS. The difference in your test case from mine, is that in mine, I remove the actual live region. However, I was not able to hear any removals in NVDA or VoiceOver. Either way, I still think authors should avoid and we should consider deprecating. Any use cases I've heard of can be done better some other way. E.g. why was the buddy name removed from the list, were they banned or quit, or are just unreachable? What's your opinion? FWIW, my colleague and I are planning to publish an article on this today.

@aleventhal:

The aria-atomic attribute basically ensures that if something inside an element changes, that the entire region is always spoken for any update, rather than just a part.

I probably misunderstood then. The ARIA doc seems to suggest that only the changed node is passed on to AT:
...
2. If aria-atomic is explicitly set to false, assistive technologies will stop searching up the ancestor chain and present only the changed node to the user.
3. If aria-atomic is explicitly set to true, assistive technologies will present the entire contents of the element.

It also seems to suggest to use aria-atomic when aria-relevant is present.

"Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute."

I agree with the above about aria-atomic but the spec is a bit confusing think. It says.

traverse the ancestors to find the first element with aria-atomic set,

and later it says.

if aria-atomic is explicitly set to false, assistive technologies will stop searching up the ancestor chain and present only the changed node to the user.

That seems to say something like this should read "Row 14" when it changes from 13 to 14 (but it doesn't in AT)

<div aria-atomic="true">Row: <span aria-live="polite" id="rownum">13</span></div>

https://www.w3.org/TR/wai-aria-1.1/#aria-atomic

I don't think we should say "searching up the ancestor chain" in the explanation of aria-atomic, should we?

Should I file a separate issue, since this is about deprecating aria-relevant?

Should I file a separate issue, since this is about deprecating aria-relevant?

Yes. The spec should also clarify the term "changed node".

Consider the example (Refer to FS training page):

<span id="LiveRegion1" aria-live="polite" aria-atomic="true">
<span id="teams">Tampa Bay Rays: 
<span id="LiveRegion2">6</span>
<br>
Boston Red Sox:&nbsp;&nbsp; 5
</span>

Based on definitions of aria-atomic true and false in the spec, what would AT say in the above example when:

1. aria-atomic = "true"
2. aria-atomic = "false"

The one time I tried to use this property, the lack of browser and/or AT support really scuppered me. I was retrofitting a calculator to add accessibility, and wanted to flag up the change to the calculator's display when the user pressed the "Del" key, so I tried using aria-relevant. But due to the lack of support, I ended up communicating the change in a message that was hidden from everything except screenreaders. This was a last resort for me, as I'd have preferred a clean solution that was supported by browsers and AT, so I would much rather see this property supported than deprecated.

In terms of a use case, I found it was helpful for providing real-time input validation. For example, if a user is entering their name into a text input, I had a live region for error notifications that would tell them if there was a problem (i.e., too few characters, invalid characters, etc). Once they corrected the problem, the error message would be removed, and having the SR announce this fact to the user was nice.

Granted, it didn't work in all SR + browser combinations due to the poor support, but I kept it in as a progressive enhancement.

@JamesCatt I think that removing the aria-invalid attribute would arguably be the semantic way to handle that case. Not sure screen readers would handle that though.

Alternatively, a live region announcement, even if a hidden one, that the error message was removed, would work more consistently and could offer a friendlier announcement than what you'd get with aria-relevant .

@JamesCatt I think that removing the aria-invalid attribute would arguably be the semantic way to handle that case. Not sure screen readers would handle that though.

In this case, simply removing the invalid state doesn't achieve the same effect, since invalid is a binary state--it doesn't provide any information on why the value is invalid. I certainly think it's good to complement the error messages with invalid, but it can't replace them.

To clarify, I'm thinking of a scenario where there are multiple errors on the same field. Another example would be a "choose your password" field, where the password has to meet multiple requirements (length, upper/lower case, numbers, etc). In this case, I found the experience provided by JAWS was perfect, reading out messages like "Removed 'password must contain a number'" as the user fixes the various problems.

Alternatively, a live region announcement, even if a hidden one, that the error message was removed, would work more consistently and could offer a friendlier announcement than what you'd get with aria-relevant .

True, there are alternate means of providing similar functionality. But if you consider the password example, it would be a fair bit more complex to build that than simply relying on aria-relevant. And as I mentioned, I thought that the announcement from JAWS was perfect for the use case. True, future SR implementations may not be consistent, but to me that doesn't seem like a valid argument for deprecation--just about every aria attribute is or has been inconsistent across SRs at some point.

If we were talking about adding a new feature to the spec, I would totally agree with you that simply relying on custom aria-live messages would make more sense--but we're not. The issue here is finding a use case, which I think this qualifies as. All I'm saying is that to me it doesn't make sense to go out of the way to deprecate a feature that is potentially useful and is already supported in the most popular SR on the market.

Discussed in https://www.w3.org/2018/11/29-aria-minutes.html

@jnurthen to work out howe to get more feedback on this.

aria-relevant=removed has been correctly output by JAWS for several years (with the addition: "removed").
I'm afraid I have to correct myself. This only applied to IE 11 and JAWS and certain methods of removal. A thorough test shows that aria-relevant is hardly correctly supported by JAWS in conjunction with IE 11, Chrome and Firefox: FreedomScientific/standards-support#289, FreedomScientific/standards-support#279

I think aria-relevant makes sense.
Make sense for all, removals and default (additions+text), but not for additions only and text only: #1048
An example for aria-relevant=removed, what I read at W3C, was: Person leaves a chat conversation.

@aleventhal:

The difference in your test case from mine, is that in mine, I remove the actual live region. However, I was not able to hear any removals in NVDA or VoiceOver.

Of course, if you remove the live region, nothing will be output. This only works if content within the live region is removed. That's the way it should be. In practice there is divergent behaviour.

After the test with JAWS 2019, the following recommendation can be given on using aria relevant

• Do not use aria-relevant, only use the default setting of aria-relevant ("additions text") (aria-relevant is not output correctly in Live Region FreedomScientific/standards-support#279, Live Region: The mix of text and element nodes leads to a strange output FreedomScientific/standards-support#283)
• Use only aria-relevant="additions text" instead of aria-relevant=removals (or aria-relevant=all). If you want the screenreader to output the removal of content, then add the appropriate information to the live region,
  i.e. insert a text telling that an item has been removed (aria-relevant is not output correctly in Live Region FreedomScientific/standards-support#279, Live region: aria-relevant=removals does not work FreedomScientific/standards-support#289).