<TH> on both row and column as an acceptable method of accessibly naming input cells

[mbgower]

I was curious if any discussion/conclusion has occurred on the validity of using properly scoped th values as the accessible names for inputs in a matrix. Radio button or checkbox cells in a likert scale are a common example.

One could of course use aria-describedby or title and concatenate those values explicitly, as in https://codepen.io/fstrr/pen/KKomqbm, but I would have thought the computation should allow th to accessibly name input cells in a grid. I don't see it in the computation?

[scottaohara]

Not presently part of the computation here or in HTML AAM. Worth thinking about, but initial thoughts are of how chatty this would make things. Navigating the first example from the codepen, even though I'm in the "a five-ounce bird..." row, I have to hear that question every time I navigate to each of the radio buttons, before I can hear the unique decision they represent. That'd be like if the content of a legend was prepended to the accName of each control within it.

Maybe columnheader / rowheader could be considered fallback naming mechanisms in the algorithm... kinda like title and placeholder are, for example. Not the ideal naming method, but something to give these things a name if developers don't name them with more preferred methods? That'd at least give the radio buttons in the second example names, where as now they have none.

[mbgower]

but initial thoughts are of how chatty this would make things. Navigating the first example from the codepen, even though I'm in the "a five-ounce bird..."

To make sure I'm being clear, it appears that right now a properly structured table with inputs in each cell would fail accname even though each is programmatically 'named' by its position in the matrix via th A screen reader user can get all that information with just the th. it's not verbose and screen readers handle the navigation pretty elegantly (i.e., only surfacing column info if you are travelling across a row).

So the 'chatty' results you are concerned about could be the result of someone adding aria-labelledby or whatever to each cell to get it to pass accname (at least, that's my read on it).

PS I also think that in more typical examples I've seen, a group name or such would offer the larger context and the th values are much shorter (as they tend to be in table headers), so the verbosity of the example is not what I would think of as a real world example, e.g. Animals that can carry a five-pound coconut Table row with column headers agree, undecided, disagree Table column with row headers: -Goldfish -Sparrow -etc

[scottaohara]

To make sure I'm being clear, it appears that right now a properly structured table with inputs in each cell would fail accname even though each is programmatically 'named' by its position in the matrix via th

but they're not programmatically named (which is why i assumed you were opening this issue). They are programmatically unnamed, but the column/rowheaders are announced if one were to navigate to these unnamed controls within a table - effectively giving a user the context though the control lacks a name (which is how i interpret your use of quotes around 'named' in the referenced sentence).

So that's my point regarding the chattiness. If column/rowheaders contributed to the names of the controls, then this information would be redundantly announced if AT were to not mitigated it by having to figure out when to announce the column/rowheader content vs the name of the control.

[JAWS-test]

The screen readers output the column and row headers as context (and not as Accessible Name) only for certain navigation methods, e.g. in form mode for TAB navigation. However, no output of the table context occurs, e.g. in the element overviews of the screen readers. There the elements would be unlabeled. This is the difficulty with such elements in tables:

• If I do not explicitly label them, I violate WCAG 4.1.2.
• if I label them explicitly, then this label is output several times (as Accessible Name and as Table Context), depending on the navigation method.

Currently best solution: avoid tables, especially for the radio group example, because here I want to hear the group label only when entering the group.

In the future it would be nice if there could be a labeling mechanism that fixes these problems.

[mbgower]

Currently best solution: avoid tables, especially for the radio group example,

Is that practical? Matrices that have cells that contain inputs are pretty common.

If you wanted to avoid them for radio button groups, I can conceive of a table-like presentation that is not in fact a table, where much of the benefit to visual users of aligned values could be provided. It's a little harder to imagine an alternative to a situation where people use a mix of inputs and read-only content in a table. Things like the aria example of a grid, for example. https://www.w3.org/WAI/ARIA/apg/example-index/grid/dataGrids.html

And think of a spreadsheet-like situation. The letters and numbers representing the row and columns are pretty important to navigate. I know we can quickly get into scenarios involving content that has headers within a spreadsheet, but in both scenarios, people are ultimately interacting with unlabelled inputs that nonetheless derive context from headers, if properly constructed.

Is there a place for this inside the computation?

[accdc]

Hi, We spoke about this during the last ARIA WG meeting, and it was decided that this would add too much complexity to the algorithm, especially since AccName core aims to provide a generic recursion mechanism that does not heavily reference different behaviors for specific HTML elements. For practicality reasons this does occur for some things, but adding more would add a lot of work for little gain, especially considering that naming mechanisms already exist for this type of scenario by using aria-label or even the title attribute on unnamed form fields embedded within data table cells. This is important to handle cases where such cells include more than one type of form field, such as radio button groups or buttons and links and other active elements. There is no way to predict how many ways these types of combinations can be combined, which is why the group decided it wasn't worth trying to map all these things out when it can simply be addressed by adding an attribute to the input.

[mbgower]

Thanks for investigating! So in summary, using properly scoped table headers to give context to otherwise unlabelled inputs in a table will be insufficient for accname. Will it then be a failure of 4.1.2 Name, Role, Value? Obviously something that passes accname will pass 4.1.2's name requirement. But does it follow that something that fails accname also fails the name requirement in 4.1.2?

name text by which software can identify a component within Web content to the user

NOTE The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.

NOTE This is unrelated to the name attribute in HTML.

[scottaohara]

the inputs aren't actually named - they are just provided context due to the row/column header announcements. So at a simple reading of the 4.1.2 rule, yes this would fail.

That said, if you think there needs to be a further discussion on why this should/should not fail - that seems a question to ask WCAG since it's their rule.