Open Bug 1832372 Opened 2 years ago Updated 1 year ago

role="presentation" should propagate from a row to its cells

Categories

(Core :: Disability Access APIs, defect)

Firefox 113
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.

Flags: needinfo?(jteh)

Thanks. I stand corrected. I'm relatively familiar with the ARIA spec for obvious reasons, but apparently not quite familiar enough. :)

Blocks: tablea11y
Severity: -- → S3
Status: UNCONFIRMED → NEW
Component: Untriaged → Disability Access APIs
Ever confirmed: true
Flags: needinfo?(jteh)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All

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.

Severity: S3 → S4
Depends on: 1832261
You need to log in before you can comment on or make changes to this bug.