"Best practice" is just your opinion

I'm going to be honest, when doing accessibility audits, the term "best practice" bothers me.

Like most things, the term 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.

Now, you’ve seen it happen. I’ve seen it happen. We've all seen it happen! We hand over our lovely audit report, complete with best practice suggestions, and what happens? Tickets will get created for anything which fails level A or level AA, if you're lucky. Then, anything marked AAA or best practice just gets thrown in the bin, or forgotten about.

I raised this topic with the accessibility community, and the discussions highlighted why the term "best practice" is somewhat problematic.

Best practice implies it's optional

The term "best practice" may not be the sole reason that accessibility barriers are ignored. But, language matters!

The moment we refer to anything as "best practice", the issue will almost never be considered a barrier with real-world consequences. Because it's not badged as a failure, it kind of implies it's just "nice-to-have".

When we use the term "best practice", it sounds like what we're saying is, "what you've done is fine, but here's another way you could have done it." When in fact, what we're really saying is, "I want you to fix this accessibility issue, but I can't technically fail you on it, because it's outside the scope of this particular standard."

As an example, let's imagine a building with a well-built wheelchair ramp out the front. Now, imagine somebody has parked a car right over the entrance to the ramp. You instantly recognise this as a barrier, right? So, if you were assessing the accessibility of this building, would you write that up? Or, because the car is not part of the building, would you consider it out of scope?

I'd like to think you'd still write it up, because it's still a barrier to access. And, just because it doesn't fail that particular building standard, it doesn't mean there aren't still other risks. The car might not cause a failure of the building regulations, but it would certainly fail on fire and safety regulations.

As the building owner, you probably wouldn't just ignore the car and think, "well, people should know it's just best practice not to park there." You'd create a parking policy. Put up signs. Introduce fines. You'd essentially create your own standards for compliance to make sure this barrier was removed. So, why don't we do this for Digital products?

Best practice isn't consistent

The term "best practice" is super opinionated. What is best practice to one person might be frowned upon by another. As my colleague, Patrick H. Lauke, often quips, "Best practice? According to whom?"

Everybody has their own preferred ways of doing things, and there are often pros and cons to different approaches. For example, I'm of the opinion that we should use as much native HTML and as little WAI-ARIA as possible.

However, my approach might have too many constraints when trying to re-design large, complex applications. In that context, it would be wrong to write people up for using WAI-ARIA roles and attributes and argue it's "best practice" to stick to native elements, just to push my own opinion.

Worse still, there are some people who will regularly bend the intent of WCAG to fit their own narrative. It's a longstanding battle which Patrick continues to fight!

I've genuinely heard people say "what can I get them on for this?" It's a tactic that has probably been born out of the fact that we all know people only pay attention to WCAG failures, but we can't push our own opinions as that of the W3C (World Wide Web Consortium).

My "best practice" and your "best practice" are just our own internal standards. It's our opinions, based on our own experiences, learnings and preferences. But, we can't have learned and experienced absolutely everything! So, whether one is better or worse relies entirely on the knowledge we have at the time, and the context of the problem we're trying to solve.

Best practice is always evolving

What is considered best practice today, might be considered archaic in 12 months time. If there's one thing we know for sure about technology, it's that it always moves on. And, when it does, it moves on fast!

As an example, Flexbox was once an emerging technology, and established itself for many years as "best practice" for web layouts.

But, after it was released in 2009, would you have scoffed at anybody still using float:right and clear:both in their layouts in 2010?

When would you have started telling people using Flexbox is "best practice"? When it was:

1. brand new, and barely supported?
2. supported in major browsers on their latest version?
3. supported in all major browsers for 3 major versions?
4. 1 year old?
5. 5 years old?

Whatever your answer, it's likely when building web apps for some organisations, it still wouldn't have been considered "best practice".

For example, it's common for government, healthcare and banking organisations to be tied into long-term contracts, which only provide support for a set operating system version. They're often several major operating system versions, and multiple major browser versions behind. So, for those organisation, anything built using Flexbox would have just been broken for many years. Therefore, it would have actually been considered "bad practice" to use it.

Best practice can sound arrogant

Although "best practice" is a common term, Rebekah Barry pointed out that depending on how it's received, it can potentially harm the underlying message you're trying to deliver:

I think this point is an important one, because in accessibility we often have to be diplomatic. Nobody likes being told that the work they've produced is below the required standard.

When we use the term "best practice", it could imply that what they've actually done is "bad practice". And, if we upset somebody in our initial engagement, make them feel embarrassed or disrespected, getting them to buy-in to accessibility or take our advice in the future is going to be difficult!

Is there a better alternative

Unfortunately, I don’t really have a solution at this point. But, we clearly need a stronger, more honest term.

Non-WCAG accessibility issue?

I initially thought of using the term "Non-WCAG accessibility issue", because it communicates two truths.

1. This is still an accessibility issue
2. This is not covered by WCAG… yet

However, Karl Goldstraw quickly pointed out an issue with this term.

Karl is right! Because if we applied another standard, the term "Non-EN 301 549 accessibility issue" doesn't quite have the same ring to it! So, this one is probably a write-off.

Accessibility issues?

Shaun Conner suggested just using "accessibility issues". But he does highlight some challenges with the term:

Similarly, James Buller suggested just calling them "Other inclusion barriers".

I think this also works. It does what it says on the tin. And, by using the word "inclusion" rather than "accessibility", it also leaves scope to be able to call out other types of issues which could cause harm. For example, design choices which might result in somebody being misgendered.

However, this could lead to scope-creep, or muddy the waters for where an accessibility audit ends and where an inclusive design review starts. So, we'd need to be careful about how we use it.

Competency?

Andy Bell, with his typical tongue-in-cheek approach, suggested we simply call it "competency". Where, like a Jedi-mind trick, we'd almost be suggesting that people are incompetent if they don't do it.

Although I know Andy is, at least half-joking. And, although I found this amusing as an idea, as a socially awkward Autistic with anxiety issues, I personally don't have the charisma or the charm to be able to pull this one off! As I discussed earlier, we have to be diplomatic and not upset people, and given I struggle with tone and can come across as overly-serious, I think just upset everybody with this one!

Standard of care?

Matt Howell suggested "standard of care", as a nod to the medical profession.

I love this idea!

The "medical standard of care" is defined by what "a reasonable and prudent professional" would do to apply the appropriate processes, diagnostics, and essentially, effort, for a patient's condition or circumstances. It's basically a benchmark for competence, based on the understanding and consensus within the medical community.

The only issue with this one, is we'd need to actually establish a baseline for what that standard of care is. And, given some of the issues raised in the WCAG GitHub repo, it's safe to say, that the accessibility community often struggles to agree on anything!

Final thoughts

WCAG is awesome, but it's not infallible. It doesn’t cover every use-case, especially when it comes to nuances like cognitive accessibility, usability, or the way assistive tech actually behaves in the wild.

When something is broken for people, but not covered by WCAG, they’re often left in a grey area. But, instead of saying, "This is inaccessible", we resort to a label that implies, "Technically fine, but…" This is the real crux of the issue. Best practice isn’t just misleading, it’s doing a disservice to people who are already facing many accessibility barriers.

In my opinion, "best practice" has had its day. It’s time we stop hiding behind it, and start trying to create some urgency around things we know to be accessibility issues. We need terminology that prompts action, not apathy! Because if somebody can’t use your service, it’s not "best practice", it’s a problem!

What term do you use? Do you have a better way to label these issues? I’d love to hear your suggestions! You can join in the conversation on:

• LinkedIn
• Bluesky
• Mastodon

Thanks, Craig

Post details