The Hidden Nuggets of WCAG2: An Introduction

Gian Wild

WCAG2 – it’s complicated. But just like climate change, that doesn’t mean we can ignore it and hope it goes away. Just like climate change, there are proponents on both sides of the issue, and just like climate change, people are vehement about the subject.

But WCAG2 doesn’t need to be that complicated. Yes – it is a long series of documents. Yes – sometimes it isn’t clear exactly what is required. But I’m here to demystify the set of guidelines, and tell you the hidden bits and pieces that you really need to know about.

In this series of articles, I’ll be talking about all the big issues in accessibility: images and alt attributes, video, keyboard accessibility, forms, tables, skip links and many more. I’ll be including concrete examples, and actual code that you can implement as well as linking to useful how-to guides. I hope this series of articles serves to simplify some of the more confusing areas of WCAG2.

But First: An Introduction to Me

I’m Gian Wild and I’ve been an accessibility specialist all my career. People ask me what I used to do before I was in accessibility and the answer is: nothing (well, I was at Uni, which is the closest I’ve ever been to doing nothing!) I’ve been creating accessible websites since before the W3C released the Web Content Accessibility Guidelines Version 1.0 in 1999. I built the first Australian accessible website. I also spent six years on the W3C Web Content Accessibility Guidelines Working Group, working on WCAG2.

What Exactly is WCAG2?

Some of you may be new to accessibility. Some of you may have your own standards – for example, America has Section 508. In any case, WCAG2 might not be a familiar term for you.

WCAG2 is the current set of accessibility guidelines released by the W3C. In Australia and many other countries it is the standard that all websites need to meet in order to claim accessibility.

WCAG2 is broken up into four principles:

  • Perceivable
  • Operable
  • Understandable
  • Robust

Under each one of these principles are a number of guidelines. For example, the Perceivable principle requires that “information and user interface components must be presentable to users in ways they can perceive” (content can’t be invisible to all of their senses).

Under this principle is the Guideline 1.1: “Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language”.

Under each guideline is a success criterion, such as Success Criterion 1.1.1: “Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose”, except for certain situations.

Now, meeting this success criterion can mean many things: it can mean audio versions of CAPTCHAs, HTML versions of PDFs or it can mean alt attributes for images.

To further clarify what is meant by a success criterion, each one has a series of Techniques. One of the techniques for Success Criterion 1.1.1 is H37: “Using alt attributes on img elements”.

There are often multiple techniques for a particular success criterion, and it is the techniques that are most useful in WCAG2: they will tell you exactly what code, design or content is required.

Personally, I think that’s all fairly complicated. There’s a lot of information in WCAG2, and while I don’t necessarily believe there was an easier way to convey it, that doesn’t change the fact that it can be quite overwhelming to the average web developer or project manager.

So, that’s enough of WCAG2 for the moment. In this series of articles I’ll be talking occasionally about success criteria and also techniques, but I’m structuring the articles around more straightforward issues, like how to make forms accessible or how to write alt attributes for images.

This all seems like a lot of hard work. Why is this important again?

Well, accessibility is a passion of mine. I’ve devoted my life to it. More generally, I believe as web professionals the most important thing we can do is make our content accessible. And there’s a simple reason behind my belief: some people with disabilities have no other way of accessing information, other than through the web.

If your bank doesn’t offer internet banking, then sure, that’s annoying to you, but you can go into a bank and complete your transactions. That’s just not possible for some people with disabilities – or, it is possible, but extremely difficult. So accessible internet banking provides much more to a person with a severe disability than it does to someone without a disability.

There’s a whole article on why accessibility is important, but they say a picture is worth a thousand words. Therefore, a video must be worth more than that, right? So, if you are still unconvinced, I will leave you with this video: to demonstrate just how empowering technology can be to people with a severe disability.

See if this can leave you dry-eyed: One Thumb to Rule Them All, by AssistiveWare.

We’ll start getting to the nuggets in my next article.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • Matthijs

    Looking forward to what you’ll write about the subject. I think it’s a good idea to work out from the practical examples (instead from a long list of criterions)

    • http://www.AccessibilityOz.com.au Gian

      Matthijs – I’ll be taking suggestions too, so let me know if there’s anything specific you would like covered.
      Gian

  • http://accessibleweb.eu Richard – Accessibleweb

    Gian,

    Interesting and useful. Looking forward to seeing your future articles. One thing I would be really interested in is how you would deal with some of the more subjective areas of WCAG2.0, for example how easy is it to determine if a page title is sufficent to describe the purpose of the page?

    Also how rigid should we be with some of the guidelines (the word guideline itself implies some flexibility), for example when ensuring focus is visible, should a page fail this if a single focusable element has no visible focus? It’s even more of a grey area where the default focus for most browsers is a thin (single pixel?) dotted line which is hardly visible anyway.

    One question about your post – surely an audio version of a Captcha can’t meet success criterion 1.1?

    Richard

    • http://www.AccessibilityOz.com.au Gian

      Hi Richard
      Page titles are an interesting issue and one I’ll be sure to cover later on. Focus indicator is incredibly important and one I urge all my clients to implement- and one I’ll also be covering.
      As for an audio form of CAPTCHA – it technically passes WCAG2, but in practice they are almost always inaccessible. My next post is on Success Criterion 1.1.1 and I’ll be talking about CAPTCHA in more detail.
      Gian

  • http://www.seogarden.co.uk Carl

    Really great start and looking forward to reading more about it.
    The video you linked is really powerful too, I’ve always had a conscience for making websites accesible but never really had exposure to why it’s important!