[data grid] Screen reader reads wrong column / row when using column pinning feature

[lioneltay]

Steps to reproduce

Link to live example: (required) https://next.mui.com/x/react-data-grid/column-pinning/

Steps:

1. navigate to https://next.mui.com/x/react-data-grid/column-pinning/ (the first example). The issue is worse on v6 https://mui.com/x/react-data-grid/column-pinning/.
2. turn on screen reader
3. navigate the table and notice that the screen reader reads 11 columns when there are only 10.

Current behavior

The header row is broken up into two separate rows, one containing the pinned columns and one containing the rest. All other rows work as expected. This causes the screen reader to associate columns in the non headers rows with the incorrect column headers. In that example if you were on the first row of the age column, VoiceOver would read "Date Created 35 column 3 of 6" where Date is actually the 4th column and 35 is an age.

Expected behavior

Screen readers shoudl read the correct column header when navigating the grid.

Context

We have a requirement to meet WCAG AA standards and have not been able to workaround this current issue.

We are currently using v6.18.1 and have noticed that the column structure splits many of the rows into multiple columns causing issues when using a screen reader to navigate the table, a similar issue was reported here https://github.com/mui/mui-x/issues/10339.

Since then this https://github.com/mui/mui-x/pull/10059 has gone through and is part of the v7 alpha/beta.

Now all the rows apart from the header row seem to be structured correctly, however the header row is still being separated into 2 rows causing the issues mentioned above.

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: wrong column accessibility Order ID: 74734

[romgrk]

@mui/xgrid I didn't update the headers in #10059 because the PR was too big already. Do we want to complete this before v7? If we consider the DOM tree as a public API, this would be a breaking change. Imho we should stop considering the full DOM as a public API, which would allow us to do these kind of changes anytime.

[cherniavskii]

@romgrk If we can do this in v7 beta - great, if not - I think it's still fine as this change shouldn't cause breaking changes for our users and can be treated as a bugfix.

[github-actions[bot]]

:warning: This issue has been closed. If you have a similar problem, please open a new issue and provide details about your specific problem. If you can provide additional information related to this topic that could help future readers, please feel free to leave a comment.

How did we do @lioneltay? Your experience with our support team matters to us. If you have a moment, please share your thoughts through our brief survey.