Should I label every row in a table of inputs?

Question

I find myself with some frequency creating a grid of inputs using a table where each cell consists of just an input field and the column headers define what the field is for. PHPStorm complains with this setup about the individual fields not having an associated label and I am wondering if providing one is really necessary.

As an example, here's a table I recently made.

^{download bmml source – Wireframes created with Balsamiq Mockups}

The user can add as many rows as necessary to complete their data entry and each row consists of a simple input in each column. I'd prefer not to clutter the table visually with a label for every input, but should I be adding something for each input for accessibility or is it ok to ignore the warning and leave them unlabeled?

If I should label them, what would be the best way to go about doing so while maintaining a simple design such as this? What would make a good individual label? "Row 2 Adjustment"?

Answer 1

You should probably mark it up as a table and follow the WCAG guidelines for accessibility.

Yours is a table with text inputs. You could use the aria-labelledby attribute as shown in example 2.

You might need to label each row also (with a <th> tag at the beginning of the row and then you add it to your aria-labelledby e.g. aria-labelledby="adj row1"). You should listen to it through a screen reader to check if it makes sense.

<table>
  <caption>Ledger</caption>
  <tr>
    <th scope="col" id="adj">Adjustment</th>
    <th scope="col" id="debit">Debit</th>
    <th scope="col" id="credit">Credit</th>
  </tr>
  <tr>
    <td><input aria-labelledby="adj"/></td>
    <td><input aria-labelledby="debit"/></td>
    <td><input aria-labelledby="credit"/></td>
  </tr>

</table>

Answer 2

Do you need a label on every row in a table of inputs? No.

Should you label every row in a table of inputs?

Who are your users? Are they data entry people, or grandparents? How often do they do it? How fast are they required (or strongly encouraged) to do it?

It comes down to user context.

If you're dealing with people who are working with this product daily, they are doing to know what column represents what data point. Labels may actually get in the way -- especially if users are visually scanning the data.

Is this basically a spreadsheet? If it is, and users understand that, they'll expect it to behave like a spreadsheet. Which do not have labels on every field entry.

If you're dealing with people who aren't necessarily familiar with your system, or who perhaps have trouble scanning data, or who only use your application once in a while, you are now starting to consider adding labels.

Answer 3

I disagree with the other two answers.

All inputs should have their own label, they don't have to be visible to the user but they are vital to screen reader users.

Another thing to think about is communicating what each row is for. If I was using a screen reader and we tabbing through your table I would find it very easy to get lost, everything would sound the same.

The fieldset element can be used with legend and this will announce the content of legend before each label. Then instead of using an actual table, whose purpose is to convey the meaning of tabular data, you could use a form with a set of fieldset elements and style them to look like a table.

Answer 4

Contrary to the folks saying you always need a label, W3C (the org that wrote WCAG) has made an example of a data table that does not have hidden labels:

https://w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html#

From that page:

...row and column headers are announced by screen readers during navigation. And, they are also navigable when using a screen reader's reading or browsing mode.

This conforms to my limited experience with the NVDA screen reader.

So screen reader users should be no more lost than sighted users. They both have equal access to the table headers.