[DOCS]: EuiTable examples updated with unique checkbox labels.

[1Copenut]

Summary

This PR came about from my investigation into #7542. That issue requested a way to add accessible aria-labels for EuiDataGrid. After confirming we could create unique labels in the data grid, I looked closer at EuiBasicTable to see if a similar mechanism was available.

The selectableMessage() callback accepts a second argument item: User, which was exactly the API I was looking for. Using that second argument, I refactored examples to concatenate accessible labels for the EuiCheckbox columns.

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Browser QA
  • Checked in mobile
  • Checked in dark and light theme
  • Checked in Chrome, Safari, Edge, and Firefox
  • Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Added documentation
  • Checked Code Sandbox works for any docs examples

[cee-chen]

I think this PR is totally great, but I just want to make sure I want to understand the outcome of our a11y recommendations as related to the discussions in #7542:

1. EUI will not be baking in any default selection checkbox screenreader copy into EuiBasicTable/EuiInMemoryTable
2. If consumers/Kibana have any axe failures around missing checkbox labels, EUI instead directs them to use the selectableMessage API and to write their own screenreader text

Is my understanding correct?

[kibanamachine]

Preview staging links for this PR:

• Docs site: https://eui.elastic.co/pr_7578/
• Storybook: https://eui.elastic.co/pr_7578/storybook

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: ee0e5c8

History

• 💚 Build #1497 succeeded cdafa3a

cc @1Copenut

[1Copenut]

Is my understanding correct?

Yes, your understanding is correct. Per the discussion in Slack, we're in agreement it's best to provide product teams the hooks to create accessible labels for EuiCheckbox columns without being overly prescriptive about what the labels should say.