a11y concerns in the data-grid example

[YonatanKra]

In the data-grid example, the header is not focusable. This prevents screen readers from finding out about the headers.

Is this intentional? Should the column headers be navigatable?

[JAWS-test]

https://www.w3.org/WAI/ARIA/apg/patterns/grid/#datagridsforpresentingtabularinformation:

In a grid, every cell contains a focusable element or is itself focusable, regardless of whether the cell content is editable or interactive. There is one exception: if column or row header cells do not provide functions, such as sort or filter, they do not need to be focusable. One reason it is important for all cells to be able to receive or contain keyboard focus is that screen readers will typically be in their application reading mode, rather than their document reading mode, when users are interacting with the grid. While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements. So, screen reader users may unknowingly overlook elements contained in a grid that are either not focusable or not used to label a column or row.

The column headers are perceptible with the screen reader because they are automatically output with the cells. This is a feature of screen readers that works in tables and grids as long as the column headers have been marked as such (th element or role=columnheader).

Personally, I think it would be better if the column headers of grids would always get the keyboard focus as well, regardless of whether they contain controls or not.

[YonatanKra]

Thanks a lot!

My first implementation was to have them focusable, and the fact they are not focusable in the example took me by surprise.

"They do not need to be focusable" leaves an opening to leave them focusable, right? ;)

Thanks again!

[JAWS-test]

"They do not need to be focusable" leaves an opening to leave them focusable, right? ;)

Yes.

Furthermore, the ARIA APG are not normative, i.e. even if it said that column headers must not receive focus, it would not be per se forbidden to design them to receive keyboard focus anyway. Normative are the correspondingly marked sections of the ARIA specification and the WCAG.
Moreover, the wording "They do not need to be focusable" means that even my interpretation can be correct, namely that it would be even better if they receive the focus.

[JAWS-test]

@mcking65 perhaps at one of the next meetings you can discuss whether it should be recommended that column headers be focusable, even if they do not contain controls.

Reason:

• Consistency with most grids where this is the case.
• structure of the grid can be better explored if the column headers and only these (without cell content) can be perceived
• avoidance of confusion why only row 2 to end, but not row 1 can be focused with the keyboard

[mcking65]

My first implementation was to have them focusable, and the fact they are not focusable in the example took me by surprise.

"They do not need to be focusable" leaves an opening to leave them focusable, right? ;)

Absolutely, the language is intended to convey that it is a design decision best left to individual developers.

[mcking65]

@JAWS-test wrote:

@mcking65 perhaps at one of the next meetings you can discuss whether it should be recommended that column headers be focusable, even if they do not contain controls.

Reason:

• Consistency with most grids where this is the case.
• structure of the grid can be better explored if the column headers and only these (without cell content) can be perceived
• avoidance of confusion why only row 2 to end, but not row 1 can be focused with the keyboard

OK, we will discuss. Perhaps we leave it as a design decision but lean in the direction of the default approach is make them focusable. It is certainly worth a new discussion.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 2626 - Guidance on focusability of col and row headers in grids.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 2626 - Guidance on focusability of col and row headers in grids
<jugglinmike> github: https://github.com//issues/2626
<jugglinmike> Matt_King: Our current guidance is that if you make a grid with row and column headers, and those headers don't have any function (e.g. sort), then because they will be read by the AT, they don't need to be focusable
<jugglinmike> Matt_King: The reporter suggests that the column headers should always be navigable even if they don't offer any particular functionality
<jugglinmike> Matt_King: They seem to say that when the headers are not navigable, that prevents screen readers from finding the information. That isn't accurate
<jugglinmike> Jem: What is the advantage of allowing focus to the column header?
<jugglinmike> Matt_King: The downside of allowing focus is that it introduces another step in navigation to reach the data
<jugglinmike> Matt_King: If you want to spell out the column header, you can just go into reading mode
<jugglinmike> Matt_King: If you can't do anything with the column header, I don't see the value in allowing focus to visit there
<jugglinmike> CurtBellew: Our libraries always have focusable headers, but they mostly have associated functionality.
<jugglinmike> Jem: There may be a misunderstanding about screen readers requiring focusability to discover or announce the column headers
<jugglinmike> Matt_King: Our current guidance says that you can make column headers focusable if you want to, but you don't need to make them focusable if they don't have any associated functionality
<jugglinmike> Matt_King: We don't have a sortable example, and we really should
<jugglinmike> Jem: We do have that, actually. It's described by a note for the datagrid example
<jugglinmike> Zakim, end the meeting