Spurred by PR#12218

Over the past weekend, I tried making tests foruseClickable anduseClickableTableRow.useClickable is done, but after doing some digging, it looks likeuseClickableTableRow might be the wrong abstraction, because even though it's trying to help with accessibility, it's causing more violations than there would be without it:

/** *@file 2024-02-19 - MES - Sadly, even though this hook aims to make elements * more accessible, it's doing the opposite right now. Per axe audits, the * current implementation will create a bunch of critical-level accessibility * violations: * * 1. Nesting interactive elements (e.g., workspace table rows having checkboxes *    inside them) * 2. Overriding the native element's role (in this case, turning a native table *    row into a button, which means that screen readers lose the ability to *    announce the row's data as part of a larger table) * * It might not make sense to test this hook until the underlying design * problems are fixed. */

Point (1) was detected via axe, but point (2) can't be detected with automated audits, because the auditing tool has no way to detect what ourintent for the code was. But if something looks like a table, it feels like users should be able to interact with it like a table.

Here's a screenshot of the audit report for the main workspaces page – each individual table row is a violation, but fixing things at the source should clear them out in one go.

One possible solution that comes to mind is making it so that the table row keeps its base semantics, but it hasonClick callbacks meant to receive and intercept events from its children. If we do decide to keep the hook, it will also need tests added.