Should form field in cells have name computed from table/grid headers (Was: Data grid example, form field missing accessible name)

[WilcoFiers]

We got a question in axe-core recently asking if form fields inside a data grid required an accessible name. My expectation is that it does. The textfield role requires an accessible name after all. But it looks like APG's data grid example 2 does not set an accessible name on the input element when a cell is edited:

https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-grids/#ex2_label

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Label requirements for inputs in grids.

The full IRC log of that discussion

<jugglinmike> Topic: Label requirements for inputs in grids
<jugglinmike> github: https://github.com//issues/2148
<jugglinmike> Matt_King: My expectation for inputs in a grid or table has always been that the row or column heading serves as a label. If you had another label on it, that could create a pretty verbose screen reader experience
<jugglinmike> Matt_King: I know that column headers are technically not the accessible name of a cell, though, so I'm curious
<jugglinmike> Matt_King: Maybe this is actually a spec issue. Or maybe the current specs are right, and there should be labels in APG. In that case, though, the current screen reader behavior may also be wrong
<jugglinmike> CurtBellew_: In this case, I thought one of the standards applied to labeling included some exceptions for when you are in structures like tables
<jugglinmike> CurtBellew_: We generally recommend labeling as a best practice
<jugglinmike> dmontalvo: I would agree with that. It would be very verbose if you had labels in addition to headings. This may be an issue in ARIA
<jugglinmike> Matt_King: We could move the issue
<jugglinmike> CoryJoseph: We treat the datagrid component as a data table, so row and header [serve as the label]
<jugglinmike> Matt_King: In certain situations, it would be onerous to code labels like this. The implementation could get almost out of hand in some situations
<jugglinmike> Matt_King: WCAG might say something about this. There may even be a WCAG technique
<jugglinmike> CurtBellew_: It might be "labels and instructions" or maybe one-three-one...
<jongund> https://www.accessibility-developer-guide.com/examples/forms/in-tables/
<jugglinmike> Matt_King: If you were reading a table with table-reading commands, and there were labels that matched the column header and/or row header, the experience would be awful
<jugglinmike> dmontalvo: I support transferring the issue to ARIA
<jugglinmike> dmontalvo: The closest topic in WCAG I could find is "H79"
<dmontalvo> https://www.w3.org/WAI/WCAG22/Techniques/html/H79
<jugglinmike> Matt_King: One place where this might be a gap is in accname calculation
<jugglinmike> jongund: But does accname take the "label" element into account?
<jugglinmike> Matt_King: Yes; accname accounts for all possible ways of computing a name
<jugglinmike> Matt_King: I think what might be a problem here is (at least for inputs) if you bring up a list of inputs, and they're not labeled in a table. That feels like an accname problem
<jugglinmike> Matt_King: I'm startingto get the feeling that the answer needs to come from a different group, not from APG
<jugglinmike> Matt_King: And that until then, APG shouldn't make a change
<jugglinmike> Matt_King: Based on our discussion here today, do we have consensus on that response?
<jugglinmike> CurtBellew_: I don't see enough evidence. Like I said, we suggest labeling just as a best practice
<jugglinmike> AriellaGilmore: I'd like to hear from ARIA before making the change to APG
<jugglinmike> CoryJoseph: I also think consulting with ARIA makes sense
<jugglinmike> Matt_King: The more I think about this, the more nuanced I think the problem is
<jugglinmike> s/as a best practice/as a best practice, but not a requirement. We encourage folks to use "aria-labeledby" to reference table headers, but we don't insist
<jugglinmike> s/labeling as a best practice/labeling as a best practice, but not a requirement.
<jugglinmike> s/labeling as a best practice/labeling as a best practice, but not a requirement./
<jugglinmike> Matt_King: If anyone wants to attach some CodePens to this issue, that's cool
<jugglinmike> Zakim, end the meeting

[mcking65]

Based on discussion in today's meeting, moving to ARIA for discussion.

[stes-acc]

I think it is expected from screen readers like Jaws that they query on input focus the parent cell relationship to its row/column header label and speak that. Because this is implicit, validators checking directly for explicit label properties of the focused control are left out in the cold.

But reality shows that this lookup evaluation is not done consequently by some screen readers yielding in the effect if you TAB from one input to the next (instead using cell navigation), no column label will be spoken at all.

These effects lead to the somehow superfluous situation that authors need to apply extra labelling for the contained controls to satisfy validators and to ensure a good user experience.

There is definitely a need for auto-labelling of embedded form elements using the relation of the parent cell to its row/col header accessible Name, not only for textboxes but also for checkboxes etc.

Technically, it has to be discussed if this auto-labelling could be done by the browser or by assistive technology. In any case, validators need a clear perspective what they can expect. This can be accomplished for instance by advising to check if the direct parent has a headers relation that serves as a label assignment.

[curtbellew]

I generally label the inputs with at least the column headers. Column and row headers as labels can be ideal assuming the row header is not too long. I understand the auto labelling idea would be a nice catch all but it also creates a risk of labels that might not be as descriptive and concise as we would like.

[aardrian]

Memorializing (per request) my suggestion on the WG call that this may be worth discussing in Accessible Name spec. Can we calculate field accName when in well-formed tables, with override for explicit naming.

[spectranaut]

Discussed today during new issue triage: https://www.w3.org/2024/03/14-aria-minutes.html

[MarioBatusic]

I think, there are following situations and their combinations to have in mind:

• Is the concerned control (input, checkbox, ...) in a cell of a table of in a gridcell of a grid / treegrid?
• Is this control the only one widget therein?
• Are the column and row header sufficient and exactly correct to give a clear accname for the widget?
  The idea of computing the accname automatically is to comölicated for browsers. It could anyway be applied only if an input / checkbox / ... is the only widget in a cell.

IMO: The best way is to engage the screen reader calculation as follows:

• If the aria-label set on an only widget in a cell / gridcell is identical with the concatenation:

• • Column header + row header, or
  • row header + column header
    then speak the label only once on focus of by the screen reader table navigation.

• If, again, there is only one widget in the cell, and the author lets it intentionally without label/title atc, setting non-blank content in both ros and column headers, then it shuld be sufficient for screen readers / evaluation tools as a correct label for the widget.

[pkra]

Discussed on today's call https://www.w3.org/2024/03/28-aria-minutes.html#t05

[cookiecrook]

Discussed in the ARIA WG April 4th 2024

@aardrian mentioned wanting to discuss this as a deep dive topic. Possibly April 25th, 2024. Including multiple fields in the same cell.

[aardrian]

For any form control that has no accName (from 2.A through 2.I of the Accessible Name and Description Computation 1.2), I am going to propose a new step to calculate an accName from the corresponding row and column headers.

• First identify if the field genuinely has no accName (steps mentioned above).
• Then identify if the field lives in a cell within a table or grid.
• If so, identify if that cell has a column and/or row header (columnheader, rowheader).
• If so, use the value of each, separated by a space character as in 2.J, and make those the accName of the field.

This will not prevent multipled controls in the same cell from having the same accName nor is it meant to.

This proposal is not meant to create usable accNames, but instead to provide an accName. The logic for how to determine a usable accName solely from context can make this unwieldy to implement (never mind bogged down in debate).

Screen readers should be encouraged not to expose the control's accName when the user is moving into a cell in a way that would announce either the column or row header.

It may be worth exposing the header that is not announced (if a user moves into a new column, the row header will already be announced but the row header may be useful to re-announce as the accName, or not). I expect this will elicit debate, which is fine. I expect SR makers to be in a better position than I to debate that.

The goal here:

• provide guessable accNames for voice users (which depends on visible column and row headers, of course).
• provide accNames for SR users who navigate by control.
• provide accNames for SR users who list controls.
• avoid redundance with column/row header announcement for SR users who navigate via table.

Again, this is not meant to be perfect. It is meant to be a final fallback for users who have not been provided with accNames from authors.

This is my pitch for the deep dive.

[aardrian]

ping @spectranaut @jnurthen as I am new to the deep dive process.

[aardrian]

Minutes from the deep dive:
https://www.w3.org/2024/05/02-aria-dive-minutes

general consensus is that we should go forward with this