Row headers with labels announce as 'blank' with table navigation

[aardrian]

Summary

Row headers that contain the <label> for a checkbox in a prior cell announce as "blank" when navigating the row header cells using table commands.

To reproduce:

1. Open JAWS
2. Open Chrome
3. Navigate to https://cdpn.io/aardrian/debug/YzBGbqJ/ac26bbdd973117bef637cc248aa3b6bd
4. Press T to navigate to the first table (caption "Does Not Announce Correctly").
5. Using table navigation (JAWS + →) navigate to the second column ("Title").
6. Using table navigation (JAWS + ↓) navigate down the column.
7. Observe the cell announces as "blank".
8. Compare to navigating the second table, captioned "Announces Correctly".

You can also Tab to a checkbox in the table (where it announces the label just fine) and then JAWS + → into the row header cell and observe it announces as "blank" in that scenario. Or any scenario where you navigate to those row header cells.

Expected result

I expected to hear the contents of the cell.

Actual result

JAWS announced "blank" instead of the contents of the cell.

Example

https://cdpn.io/aardrian/debug/YzBGbqJ/ac26bbdd973117bef637cc248aa3b6bd

Additional Information

JAWS version and build number

JAWS 2023

Operating System and version

Windows 11

Browser and version:

Chrome 119

Yet More Information

I discovered if I put an element, seemingly any element, into the <label>, that JAWS announces the contents just fine. Character entities do not do the trick.

To confirm, navigate to the second table (captioned "Announces Correctly") and repeat the steps above. The second table uses the following elements (which, yes, are mostly invalid there), most of which are void elements:

• <wbr>
• <br>
• <span></span>
• <hr hidden>
• <meta>
• <link>
• <sup></sup>

NVDA/Firefox, NVDA/Chrome, and JAWS/Firefox do not seem to manifest this bug.

The Chrome accessibility tree for the broken table shows the row header cell as:

rowheader "The Hidden Hand" readonly: false required: false
  ignored
    ignored

For the table that announces correctly, it shows the row header cell as:

rowheader "The Hidden Hand" readonly: false required: false
  LabelText ""
    StaticText "The Hidden Hand"
       InlineTextBox ""

I chose that row because it has the <hr hidden>. The others also have InlineTextBox except the last cell, which has superscript instead.

I understand this could be a Chrome bug and NVDA just papers over it, but I cannot be sure so here I am.

[JAWS-test]

This has nothing to do with the table, but with the following peculiarity of JAWS:

• for all form fields except radio buttons and checkboxes, the label is output separately (in a separate reading step, at the position where the label is located in the source code)
• For radio buttons and checkboxes, the label is not output separately, but only at the form element itself.

This is why the label is not output in your table cell, so the row header is empty.

If there is now an HTML element in the label, JAWS outputs the label twice for checkboxes and radio buttons: at the form element and at the position where the label is located in the source code (and thus also in a table at th element)

The problem occurs with Firefox, Edge and Chrome - also in your example (for table navigation with CTRL+ALT+arrow keys).

Interestingly, Chrome and Edge does not transmit the label element to the Accessibility API for radio buttons and checkboxes if they do not contain HTML elements. However, this is not the cause of the incorrect output because the problem also occurs in Firefox and Firefox correctly transmits the information to the API.

With JAWS and Firefox, the problem is even more serious because the label is never transmitted separately here, not even with an HTML element in the label, i.e. in your example, both tables are output incorrectly in Firefox and the title column is not reached at all, but skipped

[JAWS-test]

Related: https://github.com/FreedomScientific/standards-support/issues/305 and https://github.com/FreedomScientific/standards-support/issues/455

[aardrian]

This is why the label is not output in your table cell, so the row header is empty. […] The problem occurs with Firefox, Edge and Chrome - also in your example (for table navigation with CTRL+ALT+arrow keys).

The browsers' rendered accessibility trees are different. Firefox shows the full text all the way down the nodes for both tables while Chrome/Edge do not.

I think you are conflating two different factors and two different behaviors.

In Firefox, when JAWS navigates the table using table commands and the virtual cursor moves to the row header, JAWS instead moves it to the checkbox. The virtual cursor also will not move out of the checkbox column with table navigation commands.

So while that interaction is not ideal in Firefox, JAWS does not assert any content is "blank".

I appreciate you weighing in and linking related issues, but I would like to get some confirmation from Freedom Scientific folks on my experience, tests, etc. I see @BrettLewisVispero has been assigned. Can you confirm anything in here yet?

Also, @stevefaulkner did you add the "Solution provided" tag because of my hack or something else?

[stevefaulkner]

Also, @stevefaulkner did you add the "Solution provided" tag because of my hack or something else?

yes as it does workaround the problem, have changed label to workaround. Note I had assigned it to @BrettLewisVispero which means it will be imported as a bug into the Freedom Sci internal bug tracker, unless Brett comes back with some reason as to why not.

[aardrian]

Ace, thanks!

[JAWS-test]

In Firefox, when JAWS navigates the table using table commands and the virtual cursor moves to the row header, JAWS instead moves it to the checkbox. The virtual cursor also will not move out of the checkbox column with table navigation commands.

In Firefox, JAWS also recognizes the cells as empty. But a JAWS bug causes empty cells in tables to be skipped, which is analogous to https://github.com/FreedomScientific/standards-support/issues/403

[aardrian]

In Firefox, JAWS also recognizes the cells as empty. But a JAWS bug causes empty cells in tables to be skipped, which is analogous to https://github.com/FreedomScientific/standards-support/issues/403

Testing empty cells in Firefox with JAWS does not skip them. They are announced as "blank". The bug you linked is closed as fixed, and it appears to in fact be fixed.

So I am confused how it is analogous.

[JAWS-test]

So I am confused how it is analogous.

1. The cells are also empty for JAWS in Firefox, which is easy to check when navigating through the table using only the arrow keys.
2. The JAWS behaviour in Firefox is exactly as described in #403: if I come from the left, I can't navigate any further, if I come from the right, the cell is skipped.
3. The problem was never completely fixed, see #683

[JAWS-test]

@aardrian You can see that your problem has nothing to do with the table at https://codepen.io/jaws-test/pen/QWYmpQJ. There are no headings for JAWS here because the headings contain a label. However, the problem with headings only occurs with Chrome and Edge, not with Firefox

[aardrian]

The cells are also empty for JAWS in Firefox, which is easy to check when navigating through the table using only the arrow keys.

I think I understand the point you are making.

While cells intentionally left empty are announced fine in JAWS/Firefox, JAWS falls down in all browsers on cells with the construct I have used, though it manifests differently in Firefox and Chromium browsers.

You are referencing other issues that have some correlations or commonalities in the belief this makes them analogous.

So, back to my original response, I appreciate you weighing in and linking related issues, but I would like to get some confirmation from Freedom Scientific folks on my experience, tests, etc. If that results in including the issues you cited, even better!

[BrettLewisVispero]

Imported into ADO as bug 79582