I recently acquired a new project to build a website for a project run by my local authority, it's a small information led site for services on offer in the region, a portal if you wish linking to providers within their district.

This is pretty standard stuff, based on their reference material every local authority seems to have one, and I have worked on similar style projects numerous times before. What was most interesting about this particular project that suddenly made me sit up and look at this with renewed interest was a simple one line at the end of a three page brief, and it was that one little line that changed the very nature of this project in my eyes

The site must be accessible and meet WCAG 2.1 level AA standards

For those that don’t know WCAG is an acronym for Website Content accessibility Guidelines. It's a set of internationally recognised standards designed to improve the experience of and overcome the problems encountered by users with disabilities when accessing the web.

Now it shouldn’t surprise me that this line was in the brief, Government websites do have their own requirements for accessibility but in my experience, this is only strictly adhered to on .gov domains. These satellite sites rarely have the budget or content editors with the expertise willing to take on a project with these requirements.

The fact that this particular client included it illustrates to me that they are taking this project very seriously, have done their due diligence and are not looking for a cheap and cheerful end product.

So what is WCAG 2.1?

WCAG is the current specification for accessibility guidelines, version 1.0 was initially released in 1999 and focused on technique-based checkpoints to determine success but as technology improved the guidelines became less relevant and were replaced in 2008 with version 2.0 and a decade later 2.1, these second generation documents shifted focus away from the checkpoint approach to a principle led criteria.

These 4 principles are:

• Perceivable
• Operable
• Understandable
• Robust

Let's break down these principles

Perceivable

This principle is about actually experiencing the content, through our traditional senses, sight, sound and in some cases touch. Examples include:

• Do images have alternative text
• Is the text size large enough
• Do the colours offer enough contrast
• Do you provide a transcript or caption on a video interview
• Would your web content work if it had to be accessed through a braille device?
• Is your site responsive can it be accessed on all screen sizes and all orientations
• Don't rely on design choices alone (ie colour) to convey importance.

View the perceivable specification

Operable

Is focused on ensuring all users can use your site, many people have disabilities that prohibit the use of the typical keyboard and mouse combination so it is important to put mechanisms in place so that the site can be used by all. Examples include:

• Keyboard-only user input.
• To visually show when an item is selected via the keyboard ie form inputs so the user knows exactly where they are on the page.
• Correct use of labels and headers, this is important for screen readers
• The ability to ‘skip’ decorative content such as headers and banners and get directly to the page content.
• Not to have moving content auto-play, and have the ability to stop and pause any such content.

Whilst building for touch screen devices like phones has become an everyday practice and has forced developers to rethink the way people interact with sites which have helped address many of the initial accessibility obstacles there are still users that need to use more specialised devices, this principle is designed to address those issues.

View the operable specification

Understandable

Even when your content is perceivable and operable, it must still be understandable. Well-structured, well-written content with correct punctuation and typo-free may seem obvious to anyone publishing content and whilst these are the minimum we should expect there is a lot more to writing accessible content than just that. Issue such as:

• Identifying language in the code for example so that screen readers can correctly identify and read the website to the user.
• Consider the reading age of your audience not everyone reads at the same cognitive level so good content should be written in a way that is understandable by the largest audience, the younger the better. This is often confused with dumbing it down but that’s not it at all and is a failure of the author.
• Ensure forms have visible and appropriate labels, and clearly identify errors in forms on validation

View the understandable specification

Robust

This one is fairly self explanatory, the website needs to be as the name suggests robust enough to work on a wide variety of devices, its design and infrastructure should be inclusive and not exclusive and not reliable on anything in order to function at a base level. This could also be seen as future-proofing as much of the technology used in accessibility as well as every day life changes very quickly. Your site needs to be able to withstand these changes without failure.

• Can you turn off css or javascript and will the content still stand alone and be meaningful
• Ensure assistive technology know what the parts of your website are for and what state it is currently in, has the form been submitted, was there any errors or validation or stats messages that needs to be dealt with?
• Use mark up to identify and assign role and purpose to an element.

View the robust specification

So what is Level AA?

The WACG is structured into three tiers each progressively getting more in-depth. These are defined as

• Level A is a basic requirement for some users with disabilities to be able to access and use web content.
• Level AA indicates overall accessibility and removal of significant barriers to accessing content.
• Level AAA provides improvements and enhancements to web accessibility for some users with disabilities.

In order to achieve each new level, you must first complete and maintain the level before. Level 'AA' is as high as I have ever been asked to achieve in the UK and is the expected level set by the government for their sites. 'A' is largely considered a best practice guide and once aware of the fundamentals is very easy to build into any project.

Summary

United Nations Convention on Rights of Persons with Disabilities says that access to information including the web is a human right which means that it can have a legal consequence if we ignore it. This is extreme and is rarely an issue in anything but the most high-profile cases but roughly 15% of web users have some degree of disability, that is a huge percentage of potentially lost or disgruntled users. I can’t think of any online shop that would think it a good decision to alienate up to 15% of buyers before they even start browsing but that could very well be what’s at stake if their shop doesn’t consider these users and their needs.

So it makes sense that we as developers should do everything we can to make sure that these users are considered and catered for when designing a building a product. A good developer would never consider a technology that only had 85% browser support so why should we treat accessibility any differently?

Over the next few weeks, I aim to document in this series the practical applications of building a website to this specification and shed a little light on what we can do to overcome these obstacles.