Revisit aria-setsize="-1" authoring requirement

[smhigley]

The current text of aria-setsize has the following requirement for when the size is unknown:

When specifying aria-setsize, authors MUST set the value to an integer equal to the number of items in the set. If the total number of items is unknown, authors SHOULD set the value of aria-setsize to -1.

The issue is that while there is an author requirement to set the value to -1, there is no corresponding UA requirement for how to handle -1. There is also no apparent support that I could find for aria-setsize="-1" indicating an unknown number of items (though I did not test on Linux).

In core AAM the only mapping to special-case -1 is ATK/AT-SPI, which has the following:

State: STATE_INDETERMINATE if the author-provided value is -1

In tests, I found a mix of directly announcing the set size as -1, announcing the set size as 0, and ignoring the attribute entirely in favor of calculating the set size based on DOM. The result is weird or confusing UX, such as landing on "row 1 of 0" (in the case of a grid with a header row and loading body rows).

I think the author "SHOULD" should be removed in favor of "MAY", or potentially the entire section on "-1" should be taken out until there is at least minimal support for it.

related: #1323

[joanmarie]

I started looking into this. Since this is a "copious spare time" thing for me, I expect doing multiple updates. But regarding your observations of the inconsistencies:

• In the case of aria-setsize of -1, Chrome exposes -1 in Linux (and I'd bet for IAccessible2 on Windows, but will look later). This means that screen readers can process this correctly. They just need to. If they say "-1" with Chrome, that's a screen reader bug.
• Related to the previous item, I'd forgotten all about needing to do this in Orca. So I just did that implementation. Due to string additions, I cannot backport it, but when Orca v43 is released, that support will be present. At least for Chrome. See next item.
• In the case of aria-setsize of -1, Firefox does NOT expose -1 in Linux (and I'd bet for IAccessible2 on Windows, but will look later). Instead, Firefox actually does the calculation. This means that screen readers cannot process this correctly and will instead report the total item count, because that's what they have. That's this bug which I filed and proposed a patch for 5 years ago. 'Fraid I then dropped the ball on that. My "copious spare time" is not so "copious" and my mind is like a sieve. I commented on the bug and asked Jamie Teh if he could pick it up. Assuming he will, once that lands Firefox will be in the same status as Chrome with respect to Linux and Windows (IA2 consuming screen readers), namely if it's not working it's a screen reader bug.

My counter proposal to the "MAY" -- or taking it out completely -- is:

1. Add a user agents SHOULD (or maybe a MUST?) NOT calculate the set size when authors have provided -1 as the value of aria-setsize.
2. File bugs against Windows screen readers which do not correctly present the set size with Chrome
3. See what the story is on the Mac. I might be able to do that, but maybe @cookiecrook has more copious spare time than I do.

Lastly, regarding the special casing that is only on Linux: Orca doesn't actually need STATE_INDETERMINATE if -1 is exposed and -1 is NOT a valid value. Having it is appreciated, though. 😄 Maybe other ATs would like something special in addition to the exposure of -1, in which case that should be added to Core-AAM. However, I would not take the lack of that something special as an indication that -1 is insufficient for screen readers to correctly present this condition.

[joanmarie]

Note: The previous comment has been edited to point to the correct issue and commit in Orca. C&P fail before. Sorry for the noise.

[joanmarie]

The Windows situation, using Chrome Canary which exposes the value of -1:

• NVDA issue: aria-setsize when set to -1 should suppress stating the total number of items.  nvaccess/nvda#9823
• Narrator never announces the item count when entering the list (i.e. whether aria-setsize is used or not). But it does support aria-setsize of -1 when presenting the count as one arrows among the items. Normal presentation is "i of j" (e.g. 5 of 8). When the setsize is unknown, Narrator instead says "item i".
• JAWS issue (just filed): Support aria-setsize of -1 FreedomScientific/standards-support#645

I've also confirmed that Firefox exposes the calculated count via IA2, just like it does on Linux via ATK.

[joanmarie]

The macOS situation, using Chrome Canary, my locally-built Chromium, and Safari with the following test case:

<ul>
  <li aria-setsize="-1" aria-posinset="5">apples</li>
  <li aria-setsize="-1" aria-posinset="6">bananas</li>
</ul>
<ul>
  <li aria-setsize="10" aria-posinset="5">apples</li>
  <li aria-setsize="10" aria-posinset="6">bananas</li>
</ul>

Note: To examine the accessibility tree, I used ax_dump_tree because it works with all user agents, plus I'm just not seeing the expected properties in the XCode's accessibility inspector.

Findings:

• All the user agents are exposing the author-provided values via AXARIAPosInSet and AXARIASetSize as-is.
• VoiceOver treats both lists in all user agents tested in the exact same way:
  • "list 2 items" upon entering
  • "1 of 2", "2 of 2" when navigating within the list.

@cookiecrook: Am I doing something silly, missing a setting/command, etc. to get VoiceOver to report the author-provided posinset and setsize?

[joanmarie]

Another finding: Unlike aria-setsize set to -1 in lists, for articles in a feed, Chrome stomps on the -1 and replaces it with a calculation based on the number currently in the DOM. I don't know if that's a good thing or a bad thing in the specific case of feed. If the answer is "bad thing", this may be another case where spec text is needed, screen reader bugs are filed, etc.

[smhigley]

@joanmarie thanks for the really thorough testing and issue logging! That makes it really clear where the issue comes from browser mappings vs. screen reader behavior.

Would it make sense to push more for screen reader vendors to commit to actually handling -1 in a meaningful way, and revisit removing it only if that doesn't happen? The feature as a whole does make sense to me, my concern is just that without screen reader implementations the -1 value does more harm than good, coupled with us not yet having an indication that implementations are coming.

[joanmarie]

@joanmarie thanks for the really thorough testing and issue logging! That makes it really clear where the issue comes from browser mappings vs. screen reader behavior.

You're quite welcome! This sort of thing (answering "why doesn't this authoring work like the spec says it should?!") strikes me as a good use of the spare time I do have. So if you / the WG needs this again, please ping me.

Would it make sense to push more for screen reader vendors to commit to actually handling -1 in a meaningful way, and revisit removing it only if that doesn't happen? The feature as a whole does make sense to me, my concern is just that without screen reader implementations the -1 value does more harm than good, coupled with us not yet having an indication that implementations are coming.

I wholeheartedly agree with the above. @cookiecrook do you think VoiceOver should be modified to present sets of unknown size? (See this comment above.)

I don't know if commenting on the NVDA and JAWS bugs as authors / companies who need this supported would make it happen faster (i.e. due to limited developer resources on those teams). But it might be a tad more compelling than the Linux screen reader developer saying "this needs doing." 😉

[scottaohara]

action items:

• fix inconsistency with specs
• define what 'indeterminate' means in this context
• future issue to discuss with AT on how they want to convey the 'indeterminate' state to users. e.g., "on x of y (or more)"