Concerning the current reality of aria-setsize

[scottaohara]

Having read the ARIA spec for aria-setsize, as well as the CORE AAM mappings for aria-setsize and the referenced Group Position section, there seems to be something off in how this is all reflected in reality.

First, and the context for why I'm raising this issue is that ARIA says that a -1 value is allowed and SHOULD be specified when the total number of items is unknown.

However, save for ATK the mapping table makes no mention of how to handle this value. And the Group Position section then contradicts the ARIA spec by having the following 'user agents SHOULD':

If any of these properties are specified by the author as either "0" or a negative number, user agents SHOULD use "1" instead.

This reads to me as the crux of the issue I'm presently finding, where Chromium, Gecko and Webkit browsers all appear to be doing something different (all of which has been cited as being confusing per the feedback I've been receiving from devs and users):

In the context of a listbox component where the options are dynamically loaded and it is unknown to the web author how many items will load (as they are merely pulling in the data from variable sources, but there is no programmatic way (i've been told) to determine the final count of the options).

• Chromium browsers will announce the numeration of options as the currently specified aria-posinset value for the current item that is being interacted with. This makes sense. Chromium will also expose the total number of items in the listbox reflecting the value of the highest aria-posinset item that is presently in the DOM / exposed to the a11y Tree. E.g., if there are 5 items in the DOM, with aria-posinset values of 1 to 5, then the total number of options will be exposed as 5. In this situation, if focusing on option 4 triggers an event to load additional options into the listbox, on pressing down arrow to go to item 5, the numeration will instead be exposed as "5 of [new highest posinset value available]"
• In this same situation, Gecko will instead not update the total count number, and it will always reflect the number of options that are present in the DOM. This can lead to situations such as being told one is interacting with item "68 of 10".
• Webkit (macOS Safari in this example) does not follow either of the above, and instead if the aria-setsize value is set to -1, VoiceOver will say that someone is interacting with item "X of -1".

See https://codepen.io/scottohara/pen/mdLQwPQ for a reduced test case.

I personally am not sure any of the above is the "one right answer" - not just from my point of view, but because anecdotally I haven't heard much satisfaction from those I've talked to about any of the current behaviors.

That said, leaving further opinion of mine on how to resolve this for later discussion.

[douggeoffray]

First, thanks for working all this out Scott. It does seem to be a mess at the moment. The intent for me is to inform the user the index of the item they are on, when possible. Meaning when both the aria-posinset and aria-setsize are accurately known, give the user a reliable “x of y.” When the aria-posinset is known but the aria-setsize isn’t, it is still helpful to know the “x” but don’t try and make up a “y.”

In the case of screen readers, they should be smart enough to interpret a setsize of -1 and expose this in a user friendly manor, not simply give an index of “x of -1.” I don’t think standards should state how the screen readers exposes -1, but screen readers should create a friendly way to expose it best for their user’s needs. Keep the user informed and productive without causing confusion.

Of course, in order for screen readers to even have a chance of providing a trustable index, the browsers themselves need to be consistent and simply pass along the aria-setsize as provided by the web author, even if that is -1.

[travisleithead]

[updated] Browsers do have a significant stake in how they are computing implicit setsize (or relying exclusively on the aria attribute). I would personally like to see a much more algorithmic description in the spec of how a browser should process the various signals for posinset and setsize in conjunction with implcit DOM structure so that the various accessibility APIs have a chance at being a bit more consistent. From that standpoint, the Accessibility API needs to fed information that there is no setsize (I don't like returning -1, but that might be the only option) or not returning a setsize to avoid screen reader confusion.

[JAWS-test]

Related: w3c/aria#1759

[scottaohara]

Thanks @JAWS-test. I did not pay attention to that previous issue as it was marked as Editorial. I'm not sure that labeling is correct per the discussion in the issue and regarding what I've outlined here. @jnurthen @joanmarie @spectranaut @smhigley what do you think? Or will we potentially re-evaluate that when we discuss this issue since it'll be on the agenda?

[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)"

[spectranaut]

Here is the meeting where we discussed the above: https://www.w3.org/2022/10/20-aria-minutes#t05