Here we go again.
- Open this URL:
data:text/html,<table><tr><th>a</th><th style="display: block;">b</th><th style="display: block;">c</th><th>d</th></tr></table>
- Query the (0-based) column indices for b and c.
- Expected: 1 and 2.
- Actual: 0 and 0.
- Query the (0-based) column index for d.
I haven't debugged this, but here's what I think is happening:
- The tr element gets an HTMLTableRowAccessible, which is correct.
- As specified by MarkupMap, the th element gets an HTMLTableHeaderCellAccessible because it's a child of an HTML table row.
- Things fail because an HTMLTableHeaderCellAccessible needs an nsTableCellFrame, which this doesn't have because it's display: block.
I think we shouldn't use HTMLTableHeaderCellAccessibleWrap for display: block. I guess we can achieve that by checking for AccessibleType() eHTMLTableCellType.
Impact: This causes incorrect table coordinates to be reported by screen readers for affected tables, as well as making screen reader table navigation impossible.
S3 because while this is pretty nasty, I don't know of any cases of it occurring in the wild.
Originally reported as: https://github.com/nvaccess/nvda/issues/8428