Introduction to accessibility

Reading time 13 minutes

Contents

What is accessibility?

At its simplest, accessibility when it comes to the digital aspect means that functionality and content can be operated and understood by as many people as possible. This was one of the founding principles of the web.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Founding Director and inventor of the World Wide Web

This means if a user has physical or cognitive conditions, they can have the equivalent experience and perform the same tasks as those who do not.

A11y

You may see “accessibility” shortened to “a11y”. This is a numeronym where the first and last letters of the word are used and the letters in the middle are replaced with a number showing how many letters were omitted.

Avoid using this yourself where possible as it can be confusing for people who haven't come across it before - ironically placing a barrier to understanding.

Accessible by default?

Another way of looking at accessibility is that we state that every website is accessible by default at inception. As we build the site, adding code, design and content, we can unfortunately create barriers to specific groups of users. The user is not disabled on the web until we make them so.

Just as we wouldn't dream of excluding other protected characteristics (such as gender, race or sexual orientation) from using a site, we should feel the same about excluding users with access needs.

Poor accessibility happens when we place a barrier in front of any user. We can avoid doing this by understanding how and when this happens, recognising it and putting practices in place to stop it happening in the future.

It's the job

With this in mind we should recognise that ensuring this doesn't happen is part of all of our jobs. Whether you are a product manager, business analyst, part of the design team, a developer or tester this is an essential part of your role. Read more about team responsibility

The digital divide

Whilst most barriers are related to the user's disability or condition (for example missing alt text or poor colour contrast), we can also create other barriers which are not directly related.

For example disabled users are more likely to have a lower disposable income, so may be using older or lower-powered devices. This can lead to a digital divide where poor website performance has an impact. Similarly a website with a poorly coded interface can have an impact on screen-reader performance, even on newer devices.

Effects vs condition

It can be helpful to think about the effect an accessibility issue can have on the user - rather than the actual disabilities or conditions. The user's access need - for example a user with an eye condition may need to increase the font size - is what affects how we design and built our products. People may use a screen-reader for a range of different conditions, what we need to cater for is ensuring that screen-reader is supported so they can use it in a way which suits them.

The actual conditions (and it is common for users to have multiple conditions) which the user has could be caused by different things. For example vision impairment might be caused by a condition from birth, a physical injury or an infection. However the outcome may be similar in terms of the impact on how they percieve content on the web.

Conditions might also sit on a spectrum and could even vary for the same user from day to day. Hearing loss may be full or partial for example; the same cognitive condition might be heavily impactful for one user but much less so for another; a user's motor impairment might be slight but increase when the user is tired or stressed.

Types of conditions and access needs

When we talk about digital accessibility we often use the example of blind users, but as we have seen there are a lot of conditions which can be affected by poor design or code.

Vision

This can range from colour blindness to full vision loss. It includes a wide variety of vision impairment such as cataracts, macular degeneration, astigmatism and tunnel vision.

These users might use some assistive technology such as screen-readers or screen-magnifiers, but may also get by using browser zoom or just taking their time to read content.

There are a wide range of things we can do which can cause barriers from these users. Poor page layout can affect how people using screen magnification understand content, poor code can impact screen-reader users and poor design can have wide-ranging consequences.

Hearing and speech

Hearing loss can be partial or full. The obvious impact will be with media such as audio or video where there is no text alternative or captions.

For both users with either hearing or speech difficulties we also need to be mindful of designing in barriers such as how we contact them or ask them to contact us as phone-only can be an issue.

From-birth hearing loss can also impact reading and writing as the user may use sign-language as their first language. As this does not have the same grammar and vocabulary as English it can make both understanding and composing written copy more difficult.

Physical

Examples of this are complete or partial loss of a limb or neurological conditions which reduce the dexterity with which the individual can interact, such as a condition which causes tremors. It can also be a physical injury or condition which causes knock-on effects such as exhaustion or distracting pain.

These users may prefer to use a keyboard rather than a mouse and may need more time to complete actions.

Cognitive

This is the largest and most diverse group. Some examples of types of impact include memory loss, difficulty in reading and understanding content, difficulty with task focus, and conditions triggered by animations.

How many people are we talking about?

The World Health Organisation states that there are an estimated 1.3 billion people worldwide who experience significant disability. That's around 1 in 6 people.

In the UK, the Department for Work and Pensions states that 16 million people had a disability (2022) which is 24% of the population. When we just look at pension age adults that figure climbs to 45%.

So we are looking at a significant portion of the population.

It is worth also noting that a large proportion of users who are impacted by poor accessibility will not consider themselves disabled and so will not figure in the above numbers. So when we are talking about accessibility we need to think of a wider definition.

Why should we care?

With those figures it is quite likely that you know someone affected or are yourself. Could you imagine telling them they can't use the new website you just launched because they didn't matter? Of course not, as it is the right thing to do.

We should also remember that at any time anyone can become disabled via an accident or develop a condition which affects how they interact online. If you had this happen would you be prevented from doing your job or using your favourite sites because of inaccessible code or designs?

However when it comes to organisations good intentions can often get lost in the deadlines and financial constraints. In the UK accessibility is a legal requirement, explicitly for public services, but implicitly for all organisations due to the Equality Act.

Poor accessibility is discrimination.

Aging

We are all getting older. As we do we take longer to process information and our visual acuity diminishes. Even if we avoid other conditions, these are two certainties.

Aging is one of the largest groups of conditions which affect online users. There is an assumption that the older population does not use the internet which is not only untrue, but as time progresses the digital awareness of this sector becomes more pronounced as they will have been using it all their lives.

Temporary disabilities

Not all disabilities or conditions are permanent. Loss of visual acuity might be caused by an eye infection which lasts for just a few weeks. Loss of fine motor control might be caused by a physical injury sustained in an accident.

These are classed as temporary disabilities and whilst they cannot be directly compared to those with permanent versions (which are often more severe and have other monetary or mental impacts and which can cause knock-on conditions), they can have similar effects on how a user is affected online.

New condition - high impact

One difference is that these users, in common with users with new permanent conditions, is that they have not learned any coping or alternate strategies for dealing with poor design or code online. This can mean the effects may be even more impactful in the short term.

Situational “disabilities”

These are caused by the user's surroundings.

For example a user on a bus may not be able to tap accurately on a link in a similar way to a user with a neurological condition causing hand tremors.

In a bright sun a phone screen becomes much harder to read in a similar way to how poor contrast affects users with poor eyesight.

Exhaustion can lead to difficulty in understanding articles in a similar manner to those with some cognitive disabilities.

Whilst the impact is short-term and the user can sometimes extracate themselves from the situation this demonstrates that designing and coding our products well can improve the experiences of a wide range of users.

Better designs for all

Whilst it should not be our driving force for implementing accessibility, a by-product of making a product more accessible is often that it produces an even better product for all users. This is not always the case however, sometimes we need to implement accessibility purely to help a specific group of users.

However by forcing ourselves to review a design from all perspectives it encourages more thoughtful processes.

For example by making a page easier to understand for screen-reader users and for those with cognitive disorders we might make it simpler for all users and remove areas of confusion or uncertainty. By adding text labels to button icons for speech-recognition users we help all users understand functionality.

Standards, guidelines and legalities

Accessiblity is not just a nebulous thought. There are sets of guidelines and standards for us to follow which can help in decision-making.

You may have heard of the Web Accessibility Guidelines (WCAG) and possiblly Accessible Rich Internet Applications (ARIA). But there are others covering specific use-cases like content editors or cognitive disabilities.

But these are just specifications and sometimes things don't always match specs in the real world. So we need to test what we build.

There are also laws around accessibility all around the world which point to these specs.

In the UK public sector websites are legally required to adhere to the latest WCAG guidelines.

In Europe this is being extended to the commercial sector too.

Outside of this specific legislation there are other more general laws around disability rights and discrimination which can also be used where a product or company fails to take accessibility seriously.

Compliance is not accessibility

It is all too easy to get caught up in the drive to become “WCAG-compliant” and forget that WCAG is only the first step, the baseline requirement, not a target. There are aspects of accessibility which are not covered by WCAG.

No-one wants to shout that they have done the “least possible work towards accessibility”, but that is what WCAG is. We need to look beyond WCAG and look at all the ways a user might struggle with our interfaces and journeys. Compliant does not equate to accessible.

Read more about guidelines and legalities.

The cost of ignoring accessibility

Users might be unable to complete a task on your site.

This can have deep repercussions for them - both in having to find an alternate way to do the task (if one even exists), but also the time and fatigue induced which trying to get through the task unsuccessfully imparts and the mental pressure which means they feel excluded from society.

Other knock-on effects can be:

  • less users - if your product has bad accessibility the community will share this
  • unhappy users - whilst you may hear this in feedback it is just as likely users will just leave silently
  • bad press - no matter what the product, news stories about unhappy users are never good
  • loss of business - less users or bad press is not good for any business
  • legal action - a real prospect, especially as more legislation is coming in to enforce accessiblity
  • poorer security - if an interface makes it difficult for a user to login or manage their account, they may request someone helps them which weakens security for them and for your site
  • more cost - fixing accessibility issues after they have been coded is much more costly than not having them in the first place
  • delays to feature launches - if you have to dedicate time to retrospectively fixing accessibility issues this can have an impact on other deadlines

Accessibility is inherently a human test

What I mean by this is that testing the accessibility of a component or product is not something which can be fully automated.

There are aspects which can be automated and this can also be used to help avoid regression failures.

There is often a pressure within a team to automate away all accessibility tests just like business logic tests or performance tests. However the inherent complexity of at least some accessibility issues, the context-driven nature of others and the variables introduced by different assistive technology stacks means that a human test will always need to be applied.

Do not just rely on automated or push-button solutions. Accessibility needs more detailed examination than that.

Wrap-up

Accessibility is still overlooked in many places. It might be that you are the only person fighting for it at the table in a project.

  • work at your area, it is not just down to you to make everyone think about accessibility but you can spread awareness by making your area of responsibility a good example
  • tell people about the accessibility wins you are getting
  • make things better a little at a time

Yes accessibility can be complex, but there are also some very simple things which you can do to improve accessibility right now.

If you are in a position to affect the team processes to include accessibilty this is often the best way to improve accessibility across the whole team.

Put up some posters to encourage conversations around accessibility:

Some of the GOV.UK accessibility posters showing some do and don't advice for teams building digital services.
GOV.UK has posters with guidance for service teams on how to improve accessibility.

You might not be able to make your product fully accessible right away but you can make it a little better today than it was yesterday.

Further reading