HTML: RSPEC-1085 requires that every data table has a description

Based on RSPEC-1085, SonarLint requires that each table has a description, which may be provided as a caption element, referenced by means of aria-describedby or provided as an aria-label attribute. (I am ignoring the old summary attribute, which is deprecated in HTML 5.)

The claim that every data table requires a description appears to be based on a misunderstanding. What WCAG success criterion 1.3.1 requires with regard to table captions is the following:
if a table has text above it that looks like the table’s caption, then it must be marked up with a caption element (which is actually a child element of table). If for some reason, the caption element cannot be used, the “caption” can be referenced by means of aria-describedby.

Note the “if”. There is no requirement for a caption on every table, even though this is a good practice.

The inclusion of aria-label, which is for non-visible label and therefore unfit for table captions, confirms the impression that the rule is based on a misunderstanding.

For the sake of completeness, the error or warning is triggered by code such as the following:

    <table>
      <thead>
        <tr>
          <th>Name</th>
          <th>Age</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td>Methusaleh</td>
          <td>969</td>
        </tr>
        <tr>
          <td>Jared</td>
          <td>962</td>
        </tr>
      </tbody>
    </table>

(Even though I am using SonarLint, I assume this issue also applies to other Sonar products that implement this rule. It was reported to me as an issue flagged by SonarQube.)

1 Like

Hi Christophe,

I’m answering another of your threads about accessibility in HTML :slight_smile:

I’m not sure I understand your point. Sonar is not a WCAG audit tool, we simply care about good code (Although I think here we agree in spirit with WCAG…).

In this sense, we believe tables with audible descriptions are better and should be the norm.

Do you disagree with this? Or are you pointing out a defect in the rule detection or rule description?

Kind regards,

The point is that a good practice is not the same thing as a requirement.
Violating a requirement results in non-conformance, whereas not following a good practice merely means you’re doing something else.
The current rule turns a good practice into a requirement, even though there is not requirement in HTML or WCAG for a table description. The consequence is that developers are now expected to do a lot of work that is not required. (There are organisations where each Sonar issue is expected to get fixed. Rules like this cost a lot of time and energy that should be spent on more important things.)

Thank you for your feedback Christophe.

Could you share more about your context? In what situations is this problematic to you?

Maybe we are missing something!