Best Prctice for Documenting Table Headers

[Jenneh]

Problem and context

When navigating a table with a screen reader, if required to leave the table and come back, it can be difficult to find your way back to the same spot. Tables often have headers that require a definition to be understood. Header definitions need to be readable without losing focus on the table cell.

Possible solutions

• Documentation of header meanings should not be done within a section of the same notebook. Instead linking to an external documentation page is better. That way, if the user is within a table, they do not have to leave their spot to find the title description. It is easier to jump between 2 tabs then to move around on the page.

Acceptance criteria

Tasks to complete

• Add a best practice for how to link to documentation, specifically within for table headers.

[tonyfast]

this seems like it might overlap with #18

[smythp]

In terms of leaving the table and coming, back, that's definitely a pain point, but I think it's one related to how specific screen readers work. It's possible I'm missing something, but I don't know how we would address that issue by changing the structure of the notebook.

The issue of headers is a little different, and I think making sure that there are correct scope attributes on the tables would be useful. There are a lot of ways tables can be generated, though, so this might be a deceptively large issue.

[tonyfast]

i not sure what headings this relates to but i think it relates to astropy tables. https://tonyfast.github.io/tonyfast/draft/tonyfast/tonyfast/tonyfast/xxiv/2024-03-05-astropy-table-repr.html these tables should be more accessible building off of prior accessible table work.