Smooth Accessibility Implementation (From the Perspective of the WCAG Audit)

In times of swift, agile operations, companies must often strike compromises to finish developing their IT products on time. This often means dropping nice-to-haves and/or sidelining non-essential features – at least temporarily. Unfortunately, accessibility is usually one of the first victims of this approach.

However, since some companies can’t ignore accessibility entirely (because they’re legally inclined to make their solution accessible), they start looking for shortcuts.

And that’s rarely (never?) a good idea.

But there’s good news – you can make your accessibility implementation smoother. Not by magical shortcuts but with good planning.

In this article, I’ll explain how ⬇

Starting Point – The WCAG Accessibility Audit

For many, the starting point in their accessibility endeavours is the WCAG accessibility audit.

WCAG stands for Web Content Accessibility Guidelines. These guidelines are a set of recommendations for making Web content more accessible, primarily for people with disabilities — but also for all user agents, including highly limited devices, such as mobile phones.

A WCAG audit is a thorough, professional evaluation of how well a website and other digital properties are performing with respect to the abovementioned guidelines.

The WCAG 2.1 includes 78 accessibility requirements on three levels – A, AA, and AAA.

Through an official WCAG accessibility audit, organizations can get accessibility certifications.

However, WCAG requirements also serve as a waypoint when implementing accessibility. Thanks to the list of needed elements, companies can include them in their website/application to make sure they’ll pass the official certification assessment.

Yet, the list of requirements is long. So, returning to the issue introduced in the intro – many wonder if this workload can be shortened.

The answer is yes. But it’s not that straightforward.

Randomly Excluding Some of the WCAG Requirements

First, I’ll tell you what not to do.

A somewhat popular strategy at some companies to limit accessibility efforts is skipping the internal audit. Instead, executives decide to take an “alternative route” – manually picking out “the most important” accessibility elements (for example, those that address to the most common impairments) and implementing only these hand-picked components.

At this point, the first reservation I can think of is this – what are these “most important” elements in the first place?

Does it mean implementing only level A accessibility standards? Or, rather, fixing those accessibility issues that come up as the top 10 gravest accessibility mistakes?

I won’t try to answer these questions. Instead, I’ll say right away that, in my opinion, there are no “most important” accessibility elements. Although the WCAG isn’t perfect, it was designed to never discriminate against any impairment type. So, if anyone decides to sideline accessibility elements that are deemed important in the guidelines, they should do it consciously – with the understanding that they’re potentially excluding some of their users.

Consequences

So, if you’re ever working under a strict deadline or budget, remember that implementing only randomly picked accessibility elements will likely result in the following:

— no auditor will rate your website/application as WCAG compliant,

— in some parts of the world, you risk legal consequences for digitally excluded users.

So, Making A Solutions Accessible Requires an All or Nothing Approach, Right? Well, No

Luckily, all the above doesn’t mean you have to drop everything and concentrate solely on making your website/application accessible. No; there are smart ways to approach accessibility.
 
First, you can limit WCAG requirements in two steps:

• dropping level AAA accessibility standards; even lawmakers treat them as optional. As a result, instead of 78 WCAG 2.1 requirements, you end up with only 50.
• Next, you can limit your activities based on the type of content your website/application has. If your website, for example, doesn’t have any audio/video content, you don’t have to implement accessibility requirements that relate only to that type of content.

I can give you a practical example of this approach.
When I recently performed an audit for a client, I could limit the audit to only 36 requirements.
 

Yet – Instead of Limiting Accessibility Efforts, Maybe You Should Think of The Early in Development?

 
Commonly, the idea is that a WCAG-compliant website or application is accessible. However, now I need to point out the obvious – being WCAG-compliant doesn’t guarantee accessibility; it simply states, that your solution is WCAG-compliant.
If that sounds confusing (or too trivial), let me elaborate.
Surely, being WCAG-compliant is a huge step forward. But offering accessible solutions means more than just doing the basics. It means designing universally, with inclusivity in mind.

For these reasons – and many, many more – perceiving your website as accessible only because it achieved a certificate isn’t fully correct.

If That’s The Case – Should I Even Do All These Audits?

 
Importantly, audits aren’t solely about WCAG compliance.
An audit also takes usability into account. This includes tests with the support of people with disabilities. The result isn’t displayed as a simple “passed/failed”. An audit also provides a broader analysis – for example, if the content and/or the processes on the website/application are understandable.

Thus, audits are a way to assess accessibility in a broad understanding – not only from the perspective of WCAG compliance, specifically, but also from a holistic perspective.

Key Takeaways – List

1. A WCAG accessibility audit won’t make your website or solution accessible – it only serves as an assessment.
2. Audits are – and will continue to be – a basic tool to assess accessibility (for instance, in the public sector).
3. A well-documented audit plan will enable you to adjust the number of requirements to limit the work scale.
4. An accessibility audit will usually refer to the WCAG standards and with the use of the methods described there.
5. Even if you’re not an auditor or a person responsible for identifying accessibility issues, you can still use the audit to identify accessibility shortcomings which you can then eliminate.
6. In some cases, the audit is necessary – and required by law.
7. The outcomes of the audit will support you in creating an accessibility strategy and will be helpful when drafting an accessibility statement.
8. You should start your accessibility endeavours by researching and interviewing people with impairments – and conclude it with an audit performed with the same people.
9. You should limit your WCAG endeavours only from the perspective of your website’s/solution’s content and functionalities.