Done

Makes sortable table headers keyboard-accessible by wrapping the text in button elements. Follows w3c example which recommends wrapping the header text in a button, inside the th.

Fixes https://warthogs.atlassian.net/browse/WD-32943
Fixes #5735

React Components will require an update (updating the table headers markup) to benefit from this fix.

QA

• Open table example
• Use the keyboard to sort the table. You can use SPACE or ENTER on a header to sort it.
• Verify sorting still works, identical to using the mouse.
• Verify focus ring appears around the header when focused, and not when hovered.
• Open legacy sortable table example and verify it can still be sorted (with the mouse, not with the keyboard).
• Use a screen reader like ORCA and verify the table headers are semantically described as table headers with interactive buttons, and they announce when the table is sorted.
• Use dev tools to add lots of text to a table header so that the text is ellipsized. Verify that text is still ellipsized and sorting still works (though the sorting icon is hidden by the ellipses.... this is a pre-existing issue that should be handled separately). Verify the text doesn't overflow (it is truncated)
• Review sortable table docs
• Review 4.39.1 release notes

Design

• I used the button element for proper interactivity semantics, but this carries with it the default button styling. I made the table sort button inherit the table header label's styling to negate this, but have a look and make sure I didn't miss anything.
• I handled the focus ring by applying a 2x4x2x4 padding around the button to make the focus ring appear like a link focus ring (since this visually appears like a link, not a button). Then I cancelled out the padding with negative margin to avoid affecting the size of the header itself. This is worth extra attention.

Check if PR is ready for release

If this PR contains Vanilla SCSS or macro code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention
  • if existing APIs (CSS classes & macro APIs) are not changed it can be a bugfix release (x.x.X)
  • if existing APIs (CSS classes & macro APIs) are changed/added/removed it should be a minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) or macros should be listed on the what's new page.