This feature makes the table cells clickable so their value is copied to the clipboard. It currently creates barriers, has usability issues, and just doesn't work, for some people.
Tested with
On macOS 14.6.1.
Keyboard operation with Safari 17.6 and Chrome 128
Screen reader (VoiceOver) with Safari 17.6
Barriers
By adding every table cell to the focus order, a sighted keyboard user has to tab through all of them to get to the links in the footer.
By adding role="button" to the <td>, its table cell role is not conveyed by a screen reader. When I tested it, no role was convey and worse, the cell's value was not conveyed, it just said "blank" for each one. It wasn't even possible to to navigate "into" the cell to try to read the text node by word or character. See the Second Rule of ARIA Use.
Usability
Even if the footer links are unimportant, having to tab through many cells to get to the one you want is tedious.
In testing, the Contrast ratio "${ratio}" copied to clipboard! dialog was not conveyed by the screen reader, even though it has aria-live="polite". I think this is a common issue with using ARIA live regions that aren't already in the DOM tree (dialog elements are initially display: none). Writing the innerText after showing the dialog is not sufficient, in my testing, the text had to be inserted ~50ms after showing it, which is late enough to be visually noticeable. The typical solution is to let the visual "toast" message be for sighted users and to insert a 2nd copy of the text in a visually-hidden ARIA live region that's already on the page.
There's a bug (probably VoiceOver specific) where when the cell is clicked, the virtual cursor expands to be around the current cell plus the two cells to its left and that content is read aloud; this is unrelated to the cell's role being replaced.
Doesn't work
Adding tabindex="0" adds the elements to the focus order and role="button" conveys a role (well, it's meant to), but it doesn't add the behavior of an actual <button>. A sighted keyboard user pressing Enter doesn't trigger the 'click' event that's being listened for. Screen reader users can activate it, they can emit a simulated 'click' event.
Options
Remove the feature. To me, there's not much value to it, it's easy enough to triple-click the cell to select its contents then copy it. For copying many values, it's not really a time saver, it's more efficient to drag-select a row or whole table to copy and paste into a document.
Make it a pointer-only enhancement. People can still select and copy the text as usual. All this should require is removing tabindex="0" role="button".
Make it an ARIA grid. This is fairly involved but it makes it a single stop in the focus order (arrow keys are used to navigate) while ensuring each cell in the grid is keyboard operable. See the ARIA Authoring Practices Guide on the Grid Pattern.
This feature makes the table cells clickable so their value is copied to the clipboard. It currently creates barriers, has usability issues, and just doesn't work, for some people.
Tested with
On macOS 14.6.1.
Barriers
role="button"to the<td>, its table cell role is not conveyed by a screen reader. When I tested it, no role was convey and worse, the cell's value was not conveyed, it just said "blank" for each one. It wasn't even possible to to navigate "into" the cell to try to read the text node by word or character. See the Second Rule of ARIA Use.Usability
Contrast ratio "${ratio}" copied to clipboard!dialog was not conveyed by the screen reader, even though it hasaria-live="polite". I think this is a common issue with using ARIA live regions that aren't already in the DOM tree (dialogelements are initiallydisplay: none). Writing theinnerTextafter showing the dialog is not sufficient, in my testing, the text had to be inserted ~50ms after showing it, which is late enough to be visually noticeable. The typical solution is to let the visual "toast" message be for sighted users and to insert a 2nd copy of the text in a visually-hidden ARIA live region that's already on the page.Doesn't work
tabindex="0"adds the elements to the focus order androle="button"conveys a role (well, it's meant to), but it doesn't add the behavior of an actual<button>. A sighted keyboard user pressing Enter doesn't trigger the 'click' event that's being listened for. Screen reader users can activate it, they can emit a simulated 'click' event.Options
tabindex="0" role="button".