Best Practice to Use Aria-Label as a Selector for Styling

Best practice to use aria-label as a selector for styling

To represent control states that are not natively conveyed in HTML, such as expanded (for example), then leaning on ARIA attributes as style selectors can be a good fit.

In this case you are relying on CSS to add content to a page based on ARIA I do not think you need. First, support for aria-label (on <td>s as well as other elements) can be shaky on older browser / screen reader combos, and second, support for CSS generated content by older browser / screen reader combos can be more shaky. I know nothing about your users, however, to know if this matters.

This also assumes the CSS loads without any issue (network drops, etc).

This means some users may never hear nor see the value in the cell.

I try to ensure that the raw content is available regardless of whether the CSS loads to style it, and I also try to limit my reliance on ARIA.

That being said, aria-hidden support is generally historically better than the two issues I raise above.

Let me toss another idea your way. This is not necessarily better, but I think it is more robust when considering unknown user AT configurations and potential network issues.

I put both the text and checkmark into the <td>. If the CSS never loads (or the users is on a really old browser), no big deal. The worst that will happen is a user sees / hears "Yes check."

Then the aria-hidden makes sure the checkmark does not get announced to screen readers. The CSS hides the text from sighted users. And I think you have the effect you want.

<td>
 <span class="visually-hidden">Yes</span>
 <span aria-hidden="true">✔</span>
</td>

.visually-hidden {
  position: absolute !important;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
  padding:0 !important;
  border:0 !important;
  height: 1px !important;
  width: 1px !important;
  overflow: hidden;
}

Are there reasons not to use ARIA states and roles as selectors in CSS?

Attribute selectors are a very flexible way to manage styles for large-scale CSS because the attribute selectors will always have a specificity of 0-0-1-0.

[aria-*] selectors are perfectly fine to use as styling hooks, and I also recommend using custom [data-*] attributes to fill in the gaps where you might need a one-off. Certainly class selectors should continue to be used, however you can do some very elegant style extensions with attribute selectors:

[data-foo] {
    color: red;
}
[data-foo="bar"] {
    color: blue;
}
[data-foo="fizz"] {
    color: green;
}

Each of these selectors has the same specificity, and the cascade will allow the styles to be applied appropriately.

You could create your own form of classes by using the [attr~="value"] selector if need be.

Using the "attribute contains" selector can be useful for a technique that I call "classy images"

One of the hidden benefits to using attributes over classes is a performance gain in JavaScript. Instead of having to check for the presence of a class on an element (which is remarkably easy to get wrong), browsers have supported getAttribute, hasAttribute, and setAttribute for a long time.

How to properly use aria selectors for definition lists in puppeteer

Definition lists kind of suck when it comes to accessibility. In your example, you have two terms and two definitions. When you navigate through the list with a screen reader, some screen readers will say the list has 2 items and some will say it has 4 items and some will say there isn't a list.

Technically, a <dl> does not have a list role by default so screen readers that say there isn't a list are correct.

I have not used puppeteer but from what I understand, the aria selector is looking for the accessible name. The accessible name calculation follows a set of rules (essentially a big if-then-else statement). <dt> and <dd> elements do not have an accessible name unless you use aria-label or aria-labelledby. They're not like <button> elements where a button can get its accessible name from the "contents" of the button (the text between the <button> and </button>), step 2.F in the calculation. So the text between a <dt> and </dt> is not the accessible name and thus not returned in a puppeteer aria selector.

Select elements by attribute in CSS

If you mean using an attribute selector, sure, why not:

[data-role="page"] {
    /* Styles */
}

There are a variety of attribute selectors you can use for various scenarios which are all covered in the document I link to. Note that, despite custom data attributes being a "new HTML5 feature",

• browsers typically don't have any problems supporting non-standard attributes, so you should be able to filter them with attribute selectors; and

• you don't have to worry about CSS validation either, as CSS doesn't care about non-namespaced attribute names as long as they don't break the selector syntax.

Is there any guidance on when to choose aria-describedby instead of aria-labelledby?

They are indeed very similar, there is one key distinction.

aria-labelledby

aria-labelledby will overwrite any existing labelling including any semantically derived label.

For example if you had a <button> and used aria-labelledby the button text would be overwritten by the first item you listed as the label.

In the following example if you tab to the button (using the mouse over will read the button text in some screen readers) it will read "first label" then "Further information" instead of "this text will not be read".

<button aria-labelledby="lbl1 lbl2">This text will not be read</button>
<p id="lbl1">first label</p>
<p id="lbl2">Further information</p>

<label for="fmUserName">Your name</label>
<input id="fmUserName">

<button aria-label="Close" onclick="myDialog.close()">X</button>`