Consider creation of aria-listtype for role parity with ul and ol

[joanmarie]

Currently both the ul element and the ol element have at least partial parity (i.e. with the ARIA list role). That may be enough. Then again, maybe users and/or ATs would prefer to use a reliable property to determine and/or present the nature of the list. For the sake of discussion, I'm going to assume the latter for now.

One way to solve this issue is to create a new property, something like aria-listtype. The value would be a token and could be one of the following:

• ordered
• unordered

[joanmarie]

Consensus at face-to-face: Most of us think this is worth doing.

[css-meeting-bot]

The ARIA Working Group just discussed role parity - List types.

The full IRC log of that discussion

<mck> TOPIC: role parity - List types
<jamesn> GitHub: https://github.com//issues/961
<mck> jd: general topic, not list type, we have some things where parity achieved achieved, some with none, and some partial
<mck> UL and OL have partial parity. We have one role for both.
<mck> Is that enough?
<mck> Anoter option is to add an another attribute.
<mck> Joanie triaged all the partial parity issues and suggested attributes for each.
<mck> The goal now is to decide whether these partial parities issues need resolution.
<joanie> https://github.com//issues/961
<mck> First talk adding an attribute for distinguishing UL from OL
<mck> jg: Has anyone aksed for this ability to distinguish?
<mck> gg: we would like to continue to have this disctinction. today we have to look at the tags.
<mck> jd: Orca doesn't, but this could make it easier for me to make it do it.
<mck> jn: Glen what do you do differently?
<mck> gg: can't tell you why we actively need to know diff between UL and OL
<mck> Would like to have the info available to JAWS.
<mck> jn: if no one is doing anything with it today, why provide it.
<mck> gg: get your point. But, the only way we can get the info today is via the tag.
<mck> gg: give hypothetical reason
<mck> In word, we optionally identify the bullet type.
<mck> jg: wyswyg editors allow you to picka type
<mck> jn: you can tell the difference from the items.
<mck> gg: other thing we can use it for is flexible web
<mck> there we key on what the tags are to disambiguate
<mck> every bit of info you have makes it easier
<mck> jd: If there is a custom list then you would not have the tag to distinguish
<carmacleod> q+ also, authors can turn off the bullets, but semantics might still be important
<mck> gg: could there be a possibility of having a single attribute that applies to multiple roles that would give this more specific descriptive info
<joanie> q?
<HarrisSchneiderman> ack me
<mck> cm: authors can turn off the bullets, and numbers but might want to keep the semantics
<jamesn> q+ for straw poll
<carmacleod> +1 to add aria-listtype
<jamesn> Straw poll: do we need aria-listtype
<joanie> 0
<HarrisSchneiderman> 0
<melanierichards> +1
<mck> +1
<jamesn> 0
<CurtBellew> 0
<bgaraventa1979> 0
<jongund> -1
<Glen> +1
<joanie> +1
<HarrisSchneiderman> update: +1
<carmacleod> +1
<HarrisSchneiderman> https://github.com//issues/960

[eps1lon]

What about allowing aria-sort on role="list"?

-<ul />
+<div role="list" aria-sort="none" />
-<ol />
+<div role="list" aria-sort="asc|desc|other" />

[JAWS-test]

I wonder if it is important to be able to perceive the difference between ul and ol with AT, or if it would be more important to be able to perceive the visual identification of the list, which is determined via list-style-type. With unsorted lists this may not be important, but with sorted lists this seems to me to be important in certain cases, e.g. when the text refers to a certain list entry ("See step 3", "as explained under B" etc.)
If I use role=listitem, I have to add these list characters anyway, because they are not generated automatically, i.e. the type of list would be perceptible via the list characters.

So I think it is sufficient if the ARIA specification states that the list characters (if meaningful) must be implemented in a way that AT can recognize them (i.e. not with layout graphics or aria-hidden=true). Whether a list is sorted or unsorted is something a sighted user can only tell from the list characters, i.e. a sighted user cannot distinguish between ol and ul either; thus I see no need to provide this information for AT users.

In addition, HTML AAM and Acc Name should specify that for ol and li the list characters are relevant and must be transmitted to AT via Accessibility API (see w3c/html-aam#256 and FreedomScientific/standards-support#333)

[brennanyoung]

Whether a list is sorted or unsorted is something a sighted user can only tell from the list characters, i.e. a sighted user cannot distinguish between ol and ul either; thus I see no need to provide this information for AT users.

While this is often true, I don't fully agree with this claim. What makes something ordered/unordered is not merely a matter of how the bullets look. It is also implicit - sometimes explicit - in the content and context.

In a recipe, for example, it's the difference between the list of ingredients and the list of preparation steps. Or, to put it another way, I'd expect aria-current="step" to appear in an <ol>, but not in a <ul>. The opposite is true of aria-current="location".

I'd go so far as to say that marking up (say) a "Top 10", a list of slides for a slideshow, or a chat log using <ul> (instead of <ol>) is semantically incorrect, since these things have a 'natural' order.

They have a meaningful sequence!

In the case of a slideshow implemented as a list of images where one slide is displayed at a time, the fact that the items are 'ordered' is not suggested by the item symbol character at all, yet I'd still want the AT to say something like "item 2 of 14" or whatever, (and in the user's chosen AT language).

Then we have the case where a list does not start at 1 (e.g. "Episode IV, A New Hope"), or when it is reversed. For example a pop music chat needs the Number 1 song at the end, and the AT should respect this. If the Number 1 song is announced as "item 10 of 10", something isn't right, and you'd have to resort to hacks to make the announced indexes in such content fully conformant with SCs 1.3.1 and 1.3.2

So if aria lists get the ordered/unordered distinction, shouldn't we also push for parity with the HTML list attributes reversed and start? Has this been discussed? The index in these cases can be quite important for maintaining a meaningful sequence.

There will also be cases where elements may be approached or considered in 'any' order. (e.g. "10 things you didn't know about ARIA" is unordered, especially since it is more likely number 4 which promises to AMAZE you, rather than number 1 or number 10).

Granted, the ordered/unordered distinction is rarely made explicit in practice, and lists are generally browsed in an ordered fashion regardless, (or even not marked up as lists at all), but this is largely a matter of web dev sloppiness or ignorance. The fact is there are genuine use cases where the distinction is important, and given that we have "Meaningful Sequence" as a WCAG success criterion, it makes sense that we can formally distinguish meaningful sequences of list items from non-meaningful ones, using ARIA.

Anyway, it appears that there is a consensus for adding the distinction, and I support that too, even if it is perhaps not the highest priority addition. Maybe one day the AT vendors will allow users to browse <ul> items in a sequence which differs from the one in the markup, but I think aria support needs to come first.

[brennanyoung]

Just noticed in the chat log above:

could there be a possibility of having a single attribute that applies to multiple roles that would give this more specific descriptive info

YES! I can imagine many use cases, especially for data visualisations, where authors will want to emphasise that a collection (region, group, figure, graphics-object etc.) has ordered children.

[brennanyoung]

Perhaps, instead of aria-listtype, we could adopt aria-sort for this purpose. It already exists, and already expresses order.

"sort" (as a noun) is also a synonym for "type".

For this to work, aria-sort would need to be permitted on any role which is represents a collection, i.e. list, feed, group, graphics-object, as well as the current columnheader and rowheader

So a collection with aria-sort present would therefore be "ordered" unless the value of the attribute is "none".

This would also remove the need for an additional aria-reversed (or equivalent), because aria-sort already permits "ascending" and "descending" as token values.

I still see a need aria-start (or equivalent) though, which would also be useful on collection roles - and I suggest it would especially suited for pagination too.

[rahimabdi]

Generally, I agree with @brennanyoung's assessment of this issue. The distinction between ordered/unordered is important and parity with native HTML list semantics (<ul>/<ol>) is desirable.

Where I would disagree is the use of sorting semantics such as aria-sort to convey order; I think it's hard to argue that an ordered list represents "sorted" information. For example, it may be inaccurate to say that a list of steps to back up a computer is "sorted"; its order is meaningful, but saying it is sorted ascribes an intentional ordering of the elements by some criteria/algorithm, rather than a "natural" or "logical" order related to the expected sequence of execution.

CC @cookiecrook

[scottaohara]

is the goal of this issue to simply revise the role description to state "ordered list" vs "unordered list" vs the current reality of the role being "list" for both types of elements? There's then the menu element as well which could be announced as "sad trombone i'm barely useful list"?

but seriously, w3c/accname#203 reminded me of this issue, because there really is no actual difference between these HTML elements outside of the markers that are used to convey a list as ordered vs unordered. (start, type and reversed attributes are red herrings since they just modify the list item markers - all hold overs of a time before CSS. if lists where being spec'd now, i would highly expect it'd just be a single element reliant on styles to differentiate).

If the markers are removed, they're both just "lists" (or not even lists at all 😉 depending on the browser). without the visual markers, any order or not would be completely contingent on other visual treatments which would likely then need to be paired with other descriptive text or accNaming of the list to convey said visual treatment.

so again, what would the expected outcome to this issue be that wouldn't be redundant to either the visual markers that would be used to convey the ordered/unorderedness of the list - for instances where visual markers were removed, redundant to other necessary context that the page would need to provide to indicate to all users the ordered/unorderedness of the list?

if the answer is "we want to be able to do this to indicate semantics for instances where it might be visually apparent (for some users) due to [insert styling reason], but wouldn't be understood by any other page content." then sure? but is what people want what I mentioned - a revised role description for the type of list? Is that it? i guess that could be done via an attribute rather than just giving the list an accessible name to convey this, or just setting the markers to have a zero opacity, rather than removing them outright - hey, that'd then mean that the ordering would be still provided were any other styling blown away via windows high contrast mode.

[rahimabdi]

If the markers are removed, they're both just "lists" (or not even lists at all 😉 depending on the browser). without the visual markers, any order or not would be completely contingent on other visual treatments which would likely then need to be paired with other descriptive text or accNaming of the list to convey said visual treatment.

After further investigation into list markers, I think this gets at the crux of the challenge here. I love the idea of semantically conveying list order however, since this depends on (visual) list marker content, it may be duplicative/extraneous.