[a11y]: ContainedList [usage examples] - content announced in one stretch

[andreancardona]

Package

@carbon/react

Browser

FF

Package version

carbon/[email protected]

Automated testing tool and ruleset

Manual QA

Assistive technology

JAWS FF

Description

JAWS announces the content in one stretch

When the focus goes to the mentioned text, JAWS is reading the content in one stretch.
Ex: List item List item details List item details

Note - Visually we can differentiate each item as 3 separate items but the screen reader is not

WCAG 2.1 Violation

1.3.2 Meaningful Sequence

Reproduction/example

Record Number 41 in the below table:
https://airtable.com/shrFsaeHhImOkuVNR

Steps to reproduce

When the visually separated text is announced together as one single element, The blind user would not realize that the text is visually separated. And also it makes SR over verbose which can be annoying.

Recommended fix

Screen reader is expected to identify the text separately how it is visible in each line

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[andreancardona]

Chatted with @mbgower and the functionality / implementation of this component needs further refinement. Need to discuss with design & dev.

@sstrubberg we will be reviewing this in the next a11y guild call - fyi 💯

[andreancardona]

after talking to Gower here are some notes:

From our a11y call it seems: contained list is less read-only than a structured list. So although it looks closer to a plain old list, it is actually closer to an actionable data table, with structured list, despite its multiple columns, being a nearer kin to a list

From that perspective, it seems even more true to me that we should treat them as tables under the covers. The moment you do that, there is no more issue for JAWS users (with even minor experience) in regard to hearing too much information.

Also from Tom:

Certainly looks like a table to me

I'd think the title is the caption, and then the first column is the heading and the others are data cells

[tay1orjones]

It looks like we're currently mixing native list elements with aria roles, which might be part of the problem. Based on this article, there's some differences in how list and list items are read when using native ul, ol, li, etc. vs using role="list" and role="listitem"

Right now ContainedList uses the native ul and li elements, but also places role="list" on the ul. If we remove the role="list" does it help screenreaders separate out the content based on what's focused?

Alternatively, if we keep the role="list", there isn't a role="listitem" on the li currently. If role="listitem" is added to the li's, does it help?

[dabrad26]

Any update on this ticket? Or some of the other accessibility tickets that are opened? We have some gov customers reporting some concerns around some of these issues.

[mbgower]

@tay1orjones I did a quick check with JAWS on Edge, and the answer to these two questions appears to be "no"

Right now ContainedList uses the native ul and li elements, but also places role="list" on the ul. If we remove the role="list" does it help screenreaders separate out the content based on what's focused?

Alternatively, if we keep the role="list", there isn't a role="listitem" on the li currently. If role="listitem" is added to the li's, does it help?