fix: Make table column announcements less verbose for screen readers

[avinashbot]

Description

Basically, each column's <th> is typically labelled by its contents, which is normally fine. But because we could have two buttons in there (sort and resizer), what ends up happening is that each column is actually labelled with the same text multiple times, i.e. <column name> and <column name> (sort button and resizer button).

This also happens in screen readers when you move from one table body column to another (try VO+Arrow keys inside a table). This overrides that and makes sure the column label is only announced once by giving it an explicit label. I was unsure whether I wanted to get the label from the column.ariaLabel string, but we've been labelling the resizer with the visible text since forever and nobody's complained yet. Will also double check with our accessibility specialists next week before I merge this one.

Plus the way we suggest using column.ariaLabel is a little inaccurate, so I scratched that off the API docs as well. Perhaps we could even deprecate this property, but I haven't really thought about it and I don't want to get ahead myself.

Related links, issue #, if available: AWSUI-21306

How has this been tested?

Tested manually with VoiceOver, but added a unit test as well.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.40%. Comparing base (938e31b) to head (e072b98).
Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #3165    +/-   ##
========================================
  Coverage   96.40%   96.40%            
========================================
  Files         784      784            
  Lines       22136    22136            
  Branches     7602     7188   -414     
========================================
  Hits        21341    21341            
- Misses        743      788    +45     
+ Partials       52        7    -45     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gethinwebster]

As far as I can see, this change means that the ariaLabel only gets applied to the button(s), and therefore is never actually applied to the column itself. It still gets announced when navigating between header cells, but when navigating between body cells you now only get the visible column label. I think that this is probably a breaking change. At the very least, the documentation is now incorrect. But I could see cases where the ariaLabel might have been used, perhaps not as we would expect it and without the sorting state, and where changing this behavior could be a regression.

[gethinwebster]

In chrome+VO when navigating between header cells I now get announcements of [visible name] [visible name] [arialabel]. Previously it was [arialabel] [arialabel] from what I can tell. Neither is great, but I'm not sure this is an improvement.

[avinashbot]

Neither is great, but I'm not sure this is an improvement.

Table navigation is a big part of Cloudscape UX, and so I feel the additional friction when navigating table headers is worth it for the less verbose experience of navigating between multiple columns in a single row (because the information you need is behind this annoyingly long label).

But I could see cases where the ariaLabel might have been used, perhaps not as we would expect it and without the sorting state, and where changing this behavior could be a regression.

This is a fair point, I'll make it prioritise the actual ariaLabel if one's provided. I'll still remove that bit off the documentation.

[avinashbot]

Sadly closing - It's tenuously "better" on VoiceOver, but JAWS and NVDA don't like this fix. So it's just not worth it.