Improper ARIA Roles for ListGrid and listgrid element Column Headers

[aayushi_mali]

Product Version: SmartGWT PowerEdition v12.1p_2021-07-14
Screen Reader Used: NVDA


During accessibility testing and debugging, we observed that the SmartGWT ListGrid component renders with the following ARIA role issues:

The main container of the ListGrid has role="list" instead of role="grid" or role="table".

The column header section, which contains all column titles, is rendered as a single group with role="toolbar" instead of having individual role="columnheader" elements within role="row".

This implementation does not align with WCAG 2.1 or WAI-ARIA Authoring Practices for Grids and Tables, which state that:

A data table or grid should use role="grid" or role="table" on the container.

Column headers must use role="columnheader", each inside a role="row".

Grouping all headers under a single role="toolbar" does not convey correct semantic or structural information to assistive technologies.

As a result, screen readers cannot interpret column relationships properly, which significantly impacts keyboard navigation and accessibility for users relying on assistive technology.

We are seeking guidance or a framework-level solution.

Please see this example on Smart GWT showcase: https://smartclient.com/smartgwt/sho...ce_columnorder

Thank you.

[Isomorphic]

The ListGrid can play either the ARIA role of "list" or "grid" depending on how it is used in a given application. As an example, when you use a SelectItem or ComboBoxItem, that dropdown is actually a ListGrid instance!

So, first, please refer to our Accessibility Overview - it looks like you may have been doing naive DOM scanning of the nuances or of the many settings that are available:

https://smartclient.com/smartclient-....accessibility

Then, if you run into trouble, please be aware that SmartClient has survived 100s of accessibility reviews, from several world governments, large corporations, etc. If you're having trouble, we can help.

Here's where to start if you want to tap our expertise!

https://smartclient.com/services/#consulting

[aayushi_mali]

Thank you for your response.

I understand that ListGrid can function in different ARIA roles depending on context. In our case, it functions as a traditional data grid with multiple columns and rows with interactive features (e.g., sorting, column headers, rows as shown in the reference example), Based on our accessibility testing using NVDA, we observed that the ListGrid is currently rendered with a default role of list. For our use case, setting the role to "grid" using listgrid.setAriaRole("grid") appears to be more appropriate for screen reader support, particularly to align with WAI-ARIA Authoring Practices.

And also, we have ScreenReaderMode enabled by setting SC.setScreenReaderMode( true ) in onModuleLoad() method. While I have again reviewed the Accessibility Overview, I would appreciate clarification on whether there is a recommended configuration or API option to explicitly render the ListGrid with full grid semantics - specifically, using role="row" and role="columnheader" as defined by WAI-ARIA.

Additionally, I came across the following properties, which may be relevant to achieving this behavior:

ListGrid.setHeaderButtonAriaState()

ListGrid.canTabToHeader

ListGrid.canTabToSorter

ListGrid.screenReaderCellSeparator

ListGrid.screenReaderRowSeparator

ListGrid.screenReaderIncludeFieldTitles

Could you please confirm if these settings are intended to enhance accessibility support and, if so, how best to use them in combination with role="grid"?

Thanks again for your guidance and support.

[Isomorphic]

Again, we have been through several accessibility reviews, and that's why we know that the ariaRole "list" is a perfectly reasonable default for our ListGrid, because this component features row-level selection and navigation semantics, so row-level reading is appropriate.

Elsewhere, we use the ariaRole "grid" for the CubeGrid, because it has cell-level selection and nangiation, so cell-level reading is appropriate.

The way you figure out which role is appropriate on a given screen is ti examine the reading and try interacting with the component through a screenReader.

The way to submit an accessibility bug is to tell us about a specific screen reader and a specific bad reading or interaction. You have instead posted twice now that our use of roles is "improper" because you noticed that ListGrid has the word "grid" in it.

However, because accessibility bugs require specialized tools and expertise to look into, note that to look into a claimed accessibility bug, we required at least Paid Support, not the Free Community Support you are currently relying on.

Further, there is no need for us to recommend settings since the default settings are already correct, nor do we need to explain those properties and the variations they offer on the reading, because they are already documented, so you just look at the docs.

However, if you did expect that level of service, that requires Hourly Consulting.

To sum up:

1) if you want to submit a bug, submit it properly, with a specific tool and reading, and after having thoroughly reviewed the docs to understand whether there is an option to get whatever reading you prefer. Also, get Paid Support as a minimum.

2) if you want a further level of service, such as having us recommend settings for a particular use, explaining tradeoffs between ARIA roles, arguing semantics in the abstract, or possible enhancements to the framework to get a particular reading, that's Hourly Consulting