Getting Started with Web Accessibility

Accessibility is a confusingly rare topic of conversation when learning about web development and design. Many developers enter into workplaces, or start projects, without having considered aspects of web accessibility before.

This is my quick introduction to the importance and implementation of accessible development for the web.

What is Web Accessibility?

Web Accessibility is defined by Laura Kalbag [1] as:

‘the degree to which a website is accessible by as many people as possible’

We need to consider users which rely on assistive technologies to interact with websites, those who’s first language is not the language your company works in, and those who will have difficulty seeing or comprehending the information your are attempting to provide.

The topic of accessibility encompasses product development, design and implementation, and therefore involves all members of a web development team.

Every team member needs to understand their role in ensuring accessibility, and comprehend the importance of developing for the entire user base. To make a site accessible we need to consider all demographics of our target audience, including their desires, use cases, needs and limitations.

For accessible development to be successful, accessibility needs to be embedded in the development processes, as well as in the minds of the developers and managers. We should not consider accessibility to be something ‘extra’, or something you can ‘add on’ to your web site or application at the end, but instead as an integral part of an ethical and empathetic development process.

As web development becomes increasingly complex, with frameworks such as React.js and Vue.js dominating ‘modern’ sites, we need to be increasingly aware of how we can still keep accessibility a priority.

When approaching accessibility, we need to think not only about what our product or site is aiming to deliver to users, or enable users to do, we also need to try to understand our target audience, and put effort into defining what we may need to learn about and implement in order to ensure as many of those people can access and use our site as possible.

Empathy can be extremely lacking in the tech industry. Due to this, convincing the majority on the importance of topics such as accessibility, can be left to the those who see it as a priority. There is so much information out there which, when coupled with some empathy, makes a huge case for why we should be considering accessibility at every stage of development.

Why is Web Accessibility Important?

There are over 11 million people in the United Kingdom with a disability [3], with the most common forms of reported disability being those affecting motor abilities. Almost 2 million people in the UK are blind, and nearly 1 million people have a learning disability in England Alone [2]. It is also important to note that there is a relationship between disability and socioeconomic standing.

“A substantially higher proportion of individuals who live in families with disabled members live in poverty, compared to individuals who live in families where no one is disabled.”

The UK Equality Act was introduced in October 2010 to replace the Disability Discrimination Act 1995, with the aim to ‘harmonise discrimination law’ [2]. The Act prohibits discrimination by providers of good, services and facilities, and the reference ‘provision of a service’ is including commercial web services as well as traditional services.

The Act also gives a duty to providers to make ‘reasonable adjustments’ to enable disabled persons to access their given services. This means that if a providers fails to make their service accessible to disabled users, they are expected to make reasonable adjustments to rectify this.

“[when relating to] provision of information, the steps which it is reasonable for [a company] to have to take include steps for ensuring that in the circumstances concerned the information is provided in an accessible format.” — Equality Act 2010

Your company or organisation, therefore, could face legal action on the grounds of discrimination if you fail to make your services accessible.

Where to Start

When reading all of this, it could be easy to feel overwhelmed with the work, time and money that may be involved with making a service accessible. To help with this, there are guidelines in place to help with prioritising and measuring the changes needed.

The UK Government released guidelines in the form of a document known as BD 8878:2010, which outlines the decisions needed to be made when designing or commissioning web-based products, and provides guidelines for meeting the EQA requirements.

A global standard for web accessibility can be found in the Web Content Accessibility Guidelines (WCAG), which have been developed through the W3C process. They aim to explain how to make web content more accessible to those with disabilities, and is targeted towards developers.

Web Content Accessibility Guidelines

The current stable and reference-able version of WCAG is 2.0, and WCAG 2.1 is in development (https://www.w3.org/TR/WCAG21/). They operate under the POUR principles: Perceivable, Operable, Understandable and Robust.

There are three levels of conformance for these guidelines:

  • Level A: The lowest level of conformance. Some examples of the criteria include: providing text alternatives for non-text content, not using colour as the only means of conveying information, users being able to navigate the site using only a keyboard.
  • Level AA: Your web page satisfies the Level AA and Level A criteria. Examples include: having a high contrast ratio for text, ensuring users are able to zoom in up to 200% without losing functionality, consistent identification of functional components.
  • Level AAA: The highest level of conformance- your web page satisfied the level A, AA and AAA requirements. This level is not required generally, due to the fact that it’s not possible to conform to AAA for all content types. Includes requirements such as: providing sign language interpretation for prerecorded audio content, having low or no background audio on your site, ensuring the user can easily find their location within a set of web pages.

The upcoming WCAG 2.1 guidelines have more guidelines focused around task forces, and they extend upon the existing guidelines. Additions include: users should be able to zoom to 400% without losing functionality, ensuring contextual information for controls in markup languages can be programatically determined, making sure that authentication doesn’t rely on recalling and transcribing information. [6]

What Can I Do Right Now?

There are a few easy steps you can take right now to improve the accessibility of any site you created, or work on.

  1. Alternative Text

Use the alt attribute for non-text content, such as images. This text is what will be displayed when users cannot load the content, or rely on screen-readers to interpret web content.

<img src="cows.png" alt="A group of cows grazing in a field.">

This is supported in all major browsers. Ideally, the text alternative provided should describe the image if the information is important, or adds to the experience. If the image is used as a link, inside an <a> tag, then the text should explain where the link goes.

If the image doesn’t convey any information, and is used purely for aesthetics, use blank text in the alt attribute:

<img src="banner.jpeg" alt="">

This means that screen readers or other assistive technologies would skip the content, rather than attempting to convey information via the file name or something similar.

2. Use ARIA Landmarks

ARIA landmarks allow developers to provide programatic access to sections or ‘landmarks’ of a webpage. You can give ‘roles’ to elements of a page to identify sections of your page. This is useful for users reliant on Assistive Technologies, as it can provide some orientation within the page, as well as easing navigation.

Using these landmarks, you can convey a structure of a page to a user using a screen reader, and allow them to skip over content.

You can insert a landmark using the role attribute on an element. Examples of landmarks include: banner , form , main ,search .

<div id="header" role="banner"> Welcome </div>

3. Don’t Rely on Colour

It is a Level A WCAG guideline that ‘colour is not used as the only visual means of conveying information’ [4]. A good example of this is for error messages, especially for user input.

Highlighting or outlining input boxes in red is a common behaviour when a user fails to fill in a required field. However, if you aren’t using a visual display, or you have certain forms of colour blindness, this is not an obvious way of conveying the error, or how to rectify it.

Instead, asterisks can be used to indicate that a field is required or, as Laura Kalbag [1] suggests, use the text (required) next to an input label to clearly show any user the necessity of the field.

4. Accessible Forms

Alongside the changes made regarding colour and error messages, there are a few simple steps that can be taken to ensure that forms are accessible.

Firstly, we should ensure our form is appropriately structured. You can use <fieldset> elements to group widgets, and add a title to this section by using the <legend> element. <label> elements and <input> elements should be paired well, using their for and id attributes respectively.

<label for="bio">Biography:</label> 
<input type="text" id="bio" name="biography">

Secondly, the formatting of the input should be the developer’s burden, not the users. If, for example, you are asking for a number in the format XX-XXXX X the user should be able to input the numbers without doing any formatting. And, if they do attempt to format it by adding spaces and dashes, the input field should be able to handle this either immediately or upon submission.

If this isn’t possible, then the field should be constructed in a way that makes it obvious what the desired format is, and also makes it easy to enter it this way.

This could also be in the format of appropriately defining your input field so that users, especially on mobile, are shown the appropriate keyboard (e.g. number input pad when the input field is a phone number).

Input validation (displaying whether an input is correct as the user types) can also help the user through the process, and waste less of their time.

Written by

computer science student at ucl, feminist, cheese fan, vue / react, looking forward to the future 🌏

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store