display: block table cells get wrong coordinates when inside a normal <tr>
(Core :: Disability Access APIs, defect, P2)
(Reporter: Jamie, Unassigned)
(Depends on 1 open bug, Blocks 1 open bug)
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.
- Expected: 3.
- Actual: 2.
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
3 years ago
(In reply to James Teh [:Jamie] from comment #0)
I think we shouldn't use HTMLTableHeaderCellAccessibleWrap for display: block.
That would only fix step 2, cells b and c. The final th (cell d) would still have an incorrect column index (step 3) because that's what we get from layout. I guess layout treats a block element between two cells as a single cell, regardless of what element it is. The only way I see to fix that is to use our own ARIA table calculation code for everything, even HTML tables.
2 years ago