Craig Abbott wrote about the term “best practice” today. Thanks to posting his thoughts on Mastodon, I had time to kick my brain into gear and think about the topic myself.

The first thing I noticed when reading his piece is that how he experienced the term is different from how I have. Which means we’re off to a good start. 😃

Like most things, the term [best practice] started off with good intentions. A way to suggest fixes for things which are definitely accessibility barriers, but don't technically fail the Web Content Accessibility Guidelines (WCAG), or whatever standard you're auditing against.

This is not how I have ever seen the term “best practice” used, and I would be as upset as Craig if I did see it used this way.

You cannot fail websites and apps because they don’t meet your personal “best practice”. Best practices to me are techniques that meet the current level of technology and understanding. These techniques are used to meet WCAG success criteria. Most best practices will exceed WCAG.

Let’s look at this concrete code sample:

<span>Your Email:</span>
<input type="email">

This fails several WCAG success criteria, but the most obvious is that the <input> element has no accessible name¹ , so let’s focus on that.

A technique to make sure that the <input> element has an accessible name is to add an aria-label attribute:

<span>Your Email:</span>
<input aria-label="Your Email:" type="email">

That meets the success criterion, but it is not what I would generally recommend because it has some drawbacks:

• aria-label is often not translated when using in-browser translation.
• The value of aria-label can easily be overlooked when copying and pasting code to generate new, similar interfaces. That’s a future accessibility risk.
• In some screen reader/browser combinations, the aria-label will be announced in the browser language, not in the website language.
• The visual label cannot be clicked to activate the text field.

If I came across code like the example, I would not fail it against the WCAG success criterion, because there is an accessible name² .

Another way to do it is to use aria-labelledby instead:

<span id="emailLabel">Your Email:</span>
<input aria-labelledby="emailLabel" type="email">

This also meets the success criterion. But it also has drawbacks, but arguably fewer:

• The value of aria-labelledby can easily be overlooked when copying and pasting code to generate new, similar interfaces. That’s a future accessibility risk.
• In some screen reader/browser combinations, the aria-labelledby may be announced in the browser language, not in the website language.
• The visual label cannot be clicked to activate the text field.

Lastly, another way is to use the HTML <label> element instead of ARIA:

<label for="emailInput">Your Email:</label>
<input id="emailInput" type="email">

While this solution is still susceptible to copy and paste errors, you can now click on the label to set the focus into the text field, and the label’s text is always read in the page’s language.

So, what’s the best practice?

For me, I would always recommend using the <label> element. So if I find an element without an accessible name, this is my go-to technique. It’s my “best practice” because I think it has the least downsides and is usually not that difficult to implement.

That said, I do not always recommend it. Every so often the component is not relevant enough or the page is unlikely to be translated, so using a band-aid aria-label is good enough.

Frequently I will mention both: The quick fix and my “best practice”.

This gives designers and developers options. Some might find the “best practice” easier to implement, while others will only look at the quick fix.

Recommending best practices is always a double-edged sword: sometimes it can distract and lead to inaction, so the goal is to use them only when they make a noticeable difference for users in the context.

What about non-WCAG accessibility issues?

It happens. The site uses a technique that we think is so bad that it doesn’t meet our high standards.

If you are in accessibility, this should happen every time you do a review. Your standards need to be high to make the differentiation between something that does not meet the minimum requirement and something that just about does.

Grading on a scale from “oops all <div>s” to “this is the most beautiful code I could have written” is important to make the distinction where the line goes.

When an implementation reaches the minimum, but you’re still unhappy with the result, you can add a “Recommendation”. Make clear that it is not a failure but an opportunity for improvement. Ensure that fixing WCAG failures is prioritized over recommendations.

Conclusion

Defining what is the best technique to recommend in a situation is an essential skill for fixing accessibility, a skill that can only be trained by using different techniques and learning about their advantages and disadvantages.