role="presentation" should propagate from a row to its cells
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: mtchllvn, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
In #1257490 the first table example has a row with role="presentation" and empty cells. The purpose of this table is "for organizing a grid with a vertical scrollbar (the first table - for displaying a fixed header)".
Pasted here:
<table>
<thead>
<tr>
<th><a href="#">First header</a></th>
<th>Second header</th>
</tr>
</thead>
<tbody>
<tr role="presentation" style="height: 0; font-size: 0; border-width: 0;">
<td></td>
<td></td>
</tr>
<tr>
<td>First cell</td>
<td>Second cell</td>
</tr>
</tbody>
</table>
Actual results:
In #1257490 James Teh [:Jamie] wrote in comment number 7:
This is mostly resolved by Cache the World, which is enabled by default in Firefox 113.
One issue remains, which is that the first table is reported as having 4 columns instead of 2. That's because even though the tr has role="presentation", the td elements inside it do not. Per the spec, role="presentation" isn't meant to propagate to descendants, so I don't think Firefox is incorrect here.
Expected results:
Actually cells should inherit role="presentation" from their parent row, per the following specs.
"When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined."
https://www.w3.org/TR/wai-aria-1.1/#presentation
The role="row" has required owned elements of cells and headers.
https://www.w3.org/TR/wai-aria-1.1/#row
<tr> has the implicit semantic of role="row"
https://www.w3.org/TR/html-aria/#el-tr
Therefore, the inherited role="presentation" should cause the example table to expose 2 rows and 2 columns in the accessibility tree.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
Comment 2•2 years ago
|
||
Thanks. I stand corrected. I'm relatively familiar with the ARIA spec for obvious reasons, but apparently not quite familiar enough. :)
Comment 3•1 year ago
•
|
||
One issue remains, which is that the first table is reported as having 4 columns instead of 2.
This is now fixed by bug 1832261. I'm leaving this open because even though this now works as expected for users, there are still two generic Accessibles in the tree for the two presentational table cells. That's probably going to require a special case fix in nsAccessibilityService::CreateAccessibleByFrameType for eHTMLTableCellType on the td element. This is purely pedantry, though; users will not be impacted by this.
Description
•