01273 830331

What are the WCAG (Web Content Accessibility Guidelines)?

Posted on 7 October 2020 by Bradley Taylor

Suppose you are involved in the production, maintenance or development of websites. In that case, you may have heard of the Web Content Accessibility Guidelines (WCAG), but may be unsure of how they affect your website. Accessibility should be considered an essential requirement and the WCAG compliance can help you meet these obligations. But first, it’s important to understand what web accessibility means.

A blind person reading braille and two people communicating in sign language

Intro to accessibility on websites and web applications

Web accessibility refers to the practice of making a website or webapp usable by the widest audience as possible, regardless of disability or circumstance. An important aspect of web accessibility is considering how people with disabilities will use a site.

Still, it’s important not to think too closely about any individual class of disability – the requirements for a blind user can be very different from the requirements for a deaf user, which can be very different from the requirements for a cognitively impaired user. Good WCAG accessibility relies on meeting the needs of each of these impairment types and countless more diverse types of user.

The Web Content Accessibility Guidelines are a set of guidelines and associated success criteria which must be met for a website to be considered accessible. Each guideline is associated with several accompanying “techniques” which demonstrate how the guidelines can be met. The WCAG are a W3C standard, which means they have the backing of the main standards organisation which oversees the web. Multiple international governments and non-governmental organisations endorse the WCAG guidelines, and as such they are considered the de-facto accessibility standards.

The best way to get to grips with the WCAG is through the WCAG Quick Reference. Each guideline shows a description of the requirement, alongside pages detailing the how and why for meeting the guideline. Be aware though, that some of the guidance can be technical and so may not be approachable to a non-developer.

The WCAG compliance guidelines are broken down into four overarching principles:

  1. Perceivable
    Content must be presented to all users in a format they can perceive and understand. For
    example, by presenting text alternatives for audio and visual content for users with visual or hearing impairments, respectively
  2. Operable
    Users must be able to operate the interface. An essential part of this is ensuring that all interface components can be managed with a keyboard, as not all users can use a mouse or touchscreen.
  3. Understandable
    The content provided on a page must be understandable by users. This is largely about considering the wording of content, and about ensuring interface controls are predictable.
  4. Robust
    The website should be developed in a way that isn’t tied to specific accessibility aids. It should be robust to future technologies and developments in the browser and assistive technology space.

You will also find the Web Content Accessibility Guidelines are broken down into levels – single, double or triple A. These determine the level of accessibility – single A should be considered the bare minimum, whilst AA or AAA conformance means a better level of accessibility. Level AAA can be somewhat restrictive, and so most organisations aim for AA conformance. The W3C suggests that a web content developer must meet level A, should meet level AA and may meet level AAA.

I’m a site owner, where should I start?

If you have an existing site start by reviewing it for WCAG compliance. Online tools like WAVE can give you a good overview, but beware they can have false-positives and also cannot test every WCAG guideline. Talk to your existing developers, and find out their approach to accessibility – they may understand how to resolve any problems, but some
web developers may need to get help from an accessibility specialist.

Your approach will depend on your audience. If you are a charity or governmental organisation, or if you have a large number of users, then accessibility is even more important. In the UK, public sector websites and applications have a particular legal duty to ensure they are accessible. If this sounds like your organisation, then you may want to consider an independent accessibility audit.

If you are in the planning stage of a new web development, think about WCAG accessibility early on. Make accessibility a firm requirement, and ensure this is understood by your design and development team. Be open to the fact that accessibility may put in place restrictions, for example, around what colours you can use, and embrace these challenges. It’s difficult to retrofit accessibility to a project where accessibility was not originally considered, so it’s best to get this right from the start.

I’m a designer, where should I start?

Accessibility starts with design, and so at the very least be aware of the basics – ensure that colour contrast matches the minimum requirements, make sure colour isn’t the only way information is conveyed, and ensure your layout is well laid out and consistent.

Talk to any developers you work with and make it clear you are open to feedback on the accessibility of your designs – they will often have extra tools for checking WCAG compliance at the development stage. Simplicity is usually best, so if you are working on anything particularly fancy, think about what implications this will accessibility have.

Special keys for impaired people on a keyboard

I’m a developer, where should I start?

There are dozens of accessibility tools available for developers today, and so now is a good time for approaching the subject. The a11y Project has a useful development checklist to follow, and various tools exist to check the accessibility of your project: WAVE, AXE and Lighthouse are good ones.

Accessibility is a big area, and it’s easy to focus on the advanced subjects and miss the basics. Focus on using semantic HTML, adding good alt text and ensuring each webpage is keyboard navigable. You may come across the concept of aria attributes – be aware that the use of ARIA can make accessibility worse if not used correctly, and often straightforward semantic HTML is all that is required for an accessible codebase.

Conclusion

Here at BrightMinded, we believe that all websites should meet a basic level of accessibility – there is the legal obligation to do so, but we also think that it’s simply the right thing to do.

By being aware of accessibility, and specifically the WCAG, you can start to ensure that your service is accessible. Regardless of where in the web development cycle you sit, by being aware of accessibility principles, you can become the driving force to make your site usable by everyone, and help make the internet a more accessible place.