Table Reading with screenreaders

Jenneh commented 2 years ago

Problem and context

As a user navigates through table cells with a screen reader, it reads first "the_data_in_thecell" followed by the "column#" The column number does not give context of what the column title is, and is not useful information.

This was discovered with JAWS

Possible solutions

After reading the cell content, the screen reader will read out the column title, not the column #

Note from test: The summary command should be at the from (aria command) in summary for table (This may be relevant to a different issue..?)

Acceptance criteria

The user will be informed of the column header while navigating through cells so they do not have to leave the cell to read the header and then struggle to find their place in the table again.

Tasks to complete

[ ] Confirm that the column title is not being read at the beginning when a cell is selected.
[ ] Confirm this behavior is consistent between different screen readers.
[ ] Implement tech solution...?

smythp commented 2 years ago

I think this one is expected default behavior for JAWS and NVDA. By default, the column header is read so that you know which column the information relates to.

From this tables tutorial:

In many tables, the first row, going from left to right, contains headers for the information in the columns below it. Also, many times the first column, going up and down, contains headers for the information in the rows to the right. By default, JAWS treats the information in the first row and the first column as headers and automatically reads this information as you navigate using the JAWS table reading commands. When moving left and right in a table, you hear the item in each column at the top of the column and then the contents of the current cell. When moving up and down in a table, you hear the item at the beginning of each row and then the contents of the current cell.

There should be a setting in JAWS to decrease the verbosity when traversing tables. In NVDA, there are a number of relevant settings under Document Formatting, but I don't have access to JAWS to find if there is such an option. From a notebook generation perspective, however, the headings are generated with the correct and elements.

smythp commented 2 years ago

Re-reading the issue, I missed that it's incorrectly reading the column number, rather than the full column name, which is far more useful. I can confirm that on our test page, NVDA reads the full column name. I'll see if I can find anything on this, though the table seems correctly formatted, at least.

smythp commented 2 years ago

OK, just dug into this a little. One possibility for the improper reading could be a missing scope attribute on the <th> elements (the table headings). This is how the HTML currently looks:

<table id="table140630505372920" class="table-striped table-bordered table-condensed">
  <thead>
    <tr>
      <th>obsID</th>
      <th>obs_collection</th>x
      ...
    </tr>
  </thead>
</table>

With the included scope attribute, it might look like this:

<table id="table140630505372920" class="table-striped table-bordered table-condensed">
  <thead>
    <tr>
      <th scope="col">obsID</th>
      <th scope="col">obs_collection</th>
      ...
    </tr>
  </thead>    
</table>

I don't currently have access to JAWS, so I can't test this possible solution, though maybe I should look into getting a license.

W3 Schools Scope Attribute

tonyfast commented 1 year ago

missing scope on th in rows and columns is going to mess up the screen reader experience. i started on a document about making pandas dataframes acccessible. the tough part is that a lot of fixes are on the author applying best practices.

there might be some cases where it is safe to infer a remediation for tables, but in most cases there is too much ambiguity. we could provide user warnings when certain best practices are violated.

Iota-School / notebooks-for-all