Improve a11y of autofill assessment table

[martha]

Description

GH issue: https://github.com/open-path/hmis-accessibility/issues/139

I'm opening this PR against #998, in order to build on that work related to visually hidden column headers. (That PR addresses horizontal tables only, so this PR consolidates and applies the same logic to vertical tables.)

Summary of changes:

• Add visually hidden header text to the first column header of vertically oriented tables.
  • Since GenericTable doesn't currently receive the recordType prop, I implemented this as a new prop on GenericTable called verticalHiddenHeader, which is "${recordType} attributes", passed by GenericTableWithData. Let me know what you think about this approach. I'd be happy for feedback on the naming too.
• Apply the verticalCellSx to this cell, so that it gets a left border
• Add the rowheader role to row headers in vertically oriented tables
• Add visually hidden header text to all row headers in vertically oriented tables
• Move the "Select" button out of the header to its own row at the bottom of the Assessment Selection table. I’m proposing this design because I think it's sort of the vertical-table equivalent of our new Table Action Column pattern.
• Add additional visually hidden info to the column headers representing individual assessments, so screenreaders will read "Intake at XYZ Project - 6 months ago" instead of just "6 months ago".

Not done in this PR:

• Add a caption to this table. This is mentioned in the ticket, but I think it's low priority and should be bundled in with https://github.com/open-path/hmis-accessibility/issues/100 so that we talk to design and create a consistent approach to table captioning across the app.

Type of change

Accessibility improvement

Checklist before requesting review

• I have performed a self-review of my code
• I have run the code that is being changed under ideal conditions, and it doesn't fail
• My code includes comments and/or descriptive variable names to help other engineers understand the intent (or not applicable)
• My code follows the style guidelines of this project (eslint)
• I have updated the documentation (or not applicable)
• If it's not obvious how to test this change, I have provided testing instructions in this PR or the related issue

[gigxz]

This doesn't need to be a callback, it could be an external function similar to renderCellContents since it doesn't rely on any data from the component. I think that would be nice to match the pattern we already have:

const renderHeaderCellContents = <T extends { id: string }>(
  def: ColumnDef<T>
) => {
  return def.header ? (
    <strong>{def.header}</strong>
  ) : (
    // If header isn't provided, add a visually hidden header with the column key for accessibility
    <Box sx={visuallyHidden}>{def.key}</Box>
  );
};

[martha]

Thanks, I like this better too!

[gigxz]

Not really part of this diff, but maybe we can get rid of headerCellSx as we are standardizing tables - started thread https://www.figma.com/design/bsw8CX4UOq6SIdXYorZDWV?node-id=2424-868&m=dev#1081881485

[gigxz]

I think the ticket only specified to address accessibility issues, but not adjust the overall UI of the table. This seems relatively minor, but it does lead to the user needing to scroll down within the modal to find the select buttons. Is it necessary to have the button in a separate cell for accessibility reasons? (If so maybe it can remain at the top in another row?). I think unless we have a strong reason to update it, we should probably leave it the same to reduce the impact on users.

[martha]

I see! Yes, I think to fix the accessibility issue, it does need to be moved out of the column header. Otherwise, the screenreader will read out the select button every time the user navigates from column to column. But, good idea to move it back to the top in order to reduce user impact.

[martha]

@gigxz I think this is ready for re-review or just merge, let me know what you think!

[gigxz]

Looks good, thanks for the nudge!