Part 1 – An Introduction to Web Accessibility

A lot of discussion at Revium recently has been around how we can help clients to do better on the web - particularly, how we can be doing better with web accessibility. For businesses and organisations of all sizes, making sure your website is accessible to everyone is essential, especially given our challenging new circumstances.

In this, the first of two articles on the topic of accessibility, we will unpack the basics of web accessibility and explore who will benefit. In our second article on the topic of accessibility, we will discuss why we should be doing better, and how to get started.

So What is Web Accessibility?

Let’s start at the start. The term web accessibility refers to the practice of designing and building websites so that they can be accessed and operated by everyone - regardless of their ability or situation. This is a really important point to take in. It’s a human right in Australia (and around the world) to access information without exclusion - and it’s no different when it comes to the web.

We are going to look into what ‘accessed by everyone’ means in a moment, but first here is a shortlist of common misconceptions around web accessibility: 

• Accessibility is for only for blind people

• Disabled people are all in wheelchairs

• I don't know anyone with a disability

• We don’t have anyone like that using our website

• We don’t have enough time/budget for accessibility

• Accessibility is only for Government

On that note, let’s look at who accessibility is actually for.

Who Are We Talking About Here?    

People are different. So are their impairments. 1 in 5 Australians have a disability (more than four million people), and 1 in 3 of those people has a severe or profound disability.

‘People with disabilities’ refers to many groups of people who identify as having limited or impaired abilities - they may be cognitive, motor, hearing or vision-related, or a combination of these. They may be temporary or long-term, mild or severe. Impairments fall into these three groups: 

Physical

• Visual and hearing, including low vision, colour blindness and other forms of poor eyesight.

• Mobility, including difficulty or inability to use the hands, including tremors, muscle slowness, loss of fine muscle control, etc.

Cognitive

• Cognitive/intellectual, including developmental or learning disabilities (dyslexia, etc.), and cognitive disabilities affecting memory, attention, problem-solving and logic skills.

Situational

• Sometimes people are in situations that limit their ability to hear, see, use their hands, concentrate, understand instructions, etc. Sometimes they are using devices that have limitations in size, input interface, and so on. Think someone with a wrist injury, or watching video content on their phone on the train without sound.

In addition to those identifying as disabled, let’s consider the social, economic, cultural, language and age factors of our users as well. Nearly half (49%) of all Australians were either born overseas or had at least one parent who was born overseas. This means we all have vastly different experiences, access to technology and literacy levels.

To help us design and build accessible websites for the broad range of users above, we have a set of comprehensive guidelines - a benchmark for web accessibility best practice.

What Are the Web Content Accessibility Guidelines?

The Web Content Accessibility Guidelines, or WCAG (wi-cag) for short, are exactly that - a set of guidelines to help us build accessible web content. Web content in this instance is everything on the web, including visual design (look and feel), content (text, images and video) and functionality (how do page elements function, the underlying technology).

The guidelines are broken down into 4 overarching principles:

1. Perceivable

Perceivable is all about the senses people use when browsing the web. Some users may have difficulties with one or more of their senses, making them reliant on assistive technology to browse a website.

2. Operable

Operable is about the actions people take when browsing - how do they operate the website functionality, including navigation, forms, and so on. Some may have motor difficulties, which means they use their keyboard to navigate, and some users who have sight impairments often prefer to use a keyboard rather than a mouse too.

3. Understandable

Making a website understandable is different to the first two principles. Websites must use clear terms, have simple instructions and explain complex issues. You must also make your website function in a way that your users understand, by avoiding unusual, unexpected or inconsistent functions.

4. Robust

A robust website is one that third-party assistive technology (like web browsers and screen readers) can interact with. If these technologies can’t access your website, neither can the users who are relying on them.

WCAG Levels

Under the principles, there are guidelines (13), then testable success criteria (about 80 in total), which are then grouped into three levels of difficulty - A, AA and AAA.

• Level A (beginner) – the most basic web accessibility features

• Level AA (intermediate) – deals with the biggest and most common barriers for disabled users

• Level AAA (advanced) – the highest (and most complex) level of web accessibility

If that sounds a little complex, here’s a diagram to help visualise the WCAG breakdown. 

Who is Responsible?

Spoiler, it’s all of us. Firstly, let’s look at the people commonly involved in the digital design process, then we can look at where accessibility fits in.

• Decision-maker - a business owner, product owner or business analyst

• Strategy - customer experience (CX), user experience (UX) or researcher

• Creative - visual design, user interface (UI) designer, copywriter

• Technical - developers, front end or back end

• Test - testers, quality assurance (QA).

The scenario often goes something like this - a shiny new website has been through all the stages in the design cycle, and before it is launched it needs to be tested. The testers will find a (sometimes long) list of accessibility issues. That list of issues is then passed back to the developers to remedy. Some issues can be fixed by developers, but some relate to visual design or content. By this stage, we start to realise it’s a bit of a mess and will be costly to go back and undo some of the mistakes made early in the process.

Instead, let’s try this - web accessibility should be a key principle adopted in decision making throughout the entire design cycle, particularly right at the start. This means including our accessibility requirements in the discussion from the beginning - in design sprints, ideation and brainstorming sessions, technical solution discussions, and so on.

And not just ‘we will meet level AA’, but which criteria will you or won't you meet, how will you actually meet those criteria, what does success look like for each, and how will you test. This way clear requirements can be agreed on and included, and everyone in the team knows where they fit in and what they are aiming for.

In this article we have only covered the basics of web accessibility, who is impacted, the guidelines and who is responsible. Stay tuned for our second article about accessibility for our thoughts on why we should all be doing better and how to get started - including further learning, audits and testing, the importance of an accessibility strategy and the concept of low hanging fruit.

Written by Chris Burke - Consulting Web Accessibility Lead - LinkedIn