Evaluating Your Website for Accessibility Compliance and WCAG 2.1

Cynthia Ng
@TheRealArty
October 4, 2018

Brief Overview

Web Accessibility
Types of Disabilities
Assistive Technology
Policy & Legislation
WCAG 2.x
Auditing Your Website
Accessibility Statement
Take Away

What is Web Accessibility?

Web accessibility means that people with disabilities can use the Web.
- W3C Web Accessibility Initiative (WAI)

W3C Web Accessibility Initiative. (2005). What is Web Accessibility. Introduction to Web Accessibility. http://www.w3.org/WAI/intro/accessibility.php

Types of Disabilities

visual
auditory
physical/motor
touch
learning

Assistive Technology

screen readers
text-to-speech, speech-to-text
mouse alternatives (e.g. joysticks)
screen magnifiers
keyboard only
touch screen
and more

Policy & Legislation

Accessible Canada Act, C-81

First Reading: June 20, 2018

Parliament of Canada. (2018). C-81: An Act to ensure a barrier-free Canada House Government Bill.https://www.parl.ca/LegisInfo/BillDetails.aspx?billId=9990870&Language=E

Legislation in Canada

Accessibility for Ontarians with Disabilities Act (AODA) (2005)
Canadian Human Rights Act (1977)
Standard on Web Accessibility (2011) for Government of Canada

Policy

organization
grants
sponsorship

AODA requires Web Content Accessibility Guidelines (WCAG) 2.0 Level AA with a couple of exceptions by 2021 for all public institutions and large private and non-profit organizations. Canadian Human Rights Act which ensures equal opportunity but applies only to organizations with federally regulated activities. All other organizations fall under provincial or territorial law. Though due to a court case, the Standard on Web Accessibility came into effect for all department and agencies in the Government of Canada in 2011, which also outlines the requirement to meet WCAG 2.0 Level AA with a couple of exceptions.

Beyond legislation itself, there may be policies at particular organizations, and as requirements of grants or sponsorships for specific projects, also often requiring WCAG.

Web Content Accessibility Guidelines (WCAG)

by World Wide Web Consortium (W3C)

2.0 (Dec 2008)
2.1 (Jun 2018)

So we know that the Web Content Accessibility Guidelines aka WCAG is the standard to follow, but what is it?

WCAG are a set of guidelines meant to make content more accessible without being technology specific.

The guidelines have actually been around for a long time, but version 2.0 released in Dec 2008 was a major revision and started gaining more ground as the standard for legislation and regulation. Recently, the World Wide Web Consortium (W3C) released version 2.1. 2.1 included some additional guidelines and guidance from W3C, especially around conformance. It is highly recommended to have websites and applications meet the new 2.1 guidelines, since 2.1 is backwards compatible with version 2, meaning that by meeting the 2.1 guidelines, you automatically meet the 2.0 guidelines.

Nevertheless, being so new, there isn't wide adoption yet.

Sections of WCAG

Perceivable
Operable
Understandable
Robust
Conformance

Some Notes on WCAG

Level: A, AA, AAA
Level AA recommended
WCAG Quick Ref makes life easier
Elements and Guidelines Overlap

Before we move on, I want to cover a few important points about WCAG.

The first is that each guideline is classified by level, with A being the basic and minimal level up to AAA with the strictest guidelines.
Legislation and other policies will sometimes ask you to meet Level A, but most including Section 508 require you to meet Level AA. I've never seen anyone requiring Level AAA, and it is often considered impractical, though not impossible.
When trying to view which guidelines are required for a specific level and their related techniques for success, try using the quick ref version of the WCAG document since you can filter out what you need.
One of the complex parts of understanding WCAG and how it applies when auditing your website is that elements on your website will almost always overlap with multiple guidelines.

Understanding Web Accessibility & WCAG

A Practical Guide to Improving Web Accessibility (WeaveUX, Issue 7, October 2017)
A Practical Starter Guide on Developing Accessible Websites (Code4Lib Journal, Issue 37, July 2017)
WCAG Blog Post Series
Accessibility Tag Blog Posts

Unfortunately, we have limited time for this session and web accessibility is a big topic. Since I will be focusing on how to audit a website for web accessibility, I will not actually be covering general techniques on creating accessible web content or websites. So I highly recommend taking a look at some of the articles I've written, which cover making digital content and websites accessible.

While most of the posts are a bit older, my WCAG blog post series covers best practices around content and website creation for all Level A and AA guidelines by explicitly referring to them, and you can also check out other blog posts with the accessibility tag.

There are lots of general resources as well, so I encourage you to search and read on any particular aspect that may be unclear to you.

Auditing and Evaluating Your Website

Simulation

Colorblind Web Page Filter

side by side comparison of original and colour filtered site

Fangs (Firefox Add-on)

Evaluation

W3C validator

HTML Codesniffer (bookmarklet)

example report overview from HTML Codesniffer

WCAG Contrast Checker (Firefox Add-on)

WAVE Toolbar

Manual Tests with Devices

Mouse

Touch screen

Keyboard

Some things must be tested manually. For example, you may need to test mouse usage, especially on hover, or how specific behaviour on a touch screen. Similarly, keyboard accessibility is often tested manually.

Websites should always be fully accessible by a keyboard. Interactive elements should be navigable and controllable by keyboard, keyboard shortcuts should not override default behaviour, and users should always know where they are.

For example, visual cues for input focus help your users regardless of whether they only use a keyboard or not, but are necessary for keyboard only users.

And if you have hidden links, such as skip links, they should show up when there is focus on it.

If you want to conform to the new guidelines introduced in WCAG 2.1, you may need to do them manually as well since many of the tools are still using version 2.0.

Automated Testing Frameworks

Demo: HTML Codesniffer

Report with errors and showing dropdown of different guidelines

Demo: WAVE Toolbar

Demo: Keyboard Accessibility

What's New in WCAG 2.1

Non-Text Contrast 1.4.11

Responsive Design

Orientation 1.3.4, Reflow 1.4.10, Text Spacing 1.4.12

Form Fields Extended

Identify Input Purpose 1.3.5: Use autocomplete for autofill
Label in Name 2.5.3: Visible labels = Accessible names
Status Messages 4.1.3: Use appropriate role without changing focus

User Input Extended

Character Key Shortcuts 2.1.4: Only on focus, can disable, or remap
Motion Actuation 2.5.4: Can disable, provide equivalent non-motion interaction
Pointer Gestures 2.5.1: Single pointer alternative to complex gestures
Pointer Cancellation 2.5.2: Use default up-event behaviour, and allow abort/undo
Content on Hover or Focus 1.4.13: Make persistent, hoverable, and dismissable

The rest of the guidelines have to do with adding to the existing criteria on dealing with user input. Single key keyboard shortcuts are often used when a specific element has focus, such as video controls with focus on a video, but will normally not be implemented in other cases. If for some reason your site or app needs it, then a user should be able to disable the shortcuts or remap them.

The motion actuation guideline simply states that if functionality is based on moving a device, a user should be able to do the same thing using on-screen components and the motion response can be disabled.

Similarly, if there is functionality requiring complex gestures, such as multiple fingers at the same time, then a single point alternative is available as well.

The pointer cancellation guideline is not the easiest one to understand, especialy on first read, but it essentially boils down to not changing the default up-event behaviour and allowing the user to abort or undo actions.

This last one should be easy to understand, but may actually be one of the more difficult ones to implement. Basically, whenever new content is shown due to a hover or focus on an element, the new content should stay showing as long as the user has hover or focus on either the triggering element or the new content until they move off either one or they dismiss the new content, which they should be able to do without moving off. The main thing that is different from what most sites already do is that a lot of hover elements use CSS and cannot be dismissed using the ESC key. If this is considered necessary for accessibility, hopefully browsers will actually implement this functionality instead of having to code it into all websites.

Okay, I know I went through those quite quickly, but there is enough content to do probably a half or whole session just on the new guidelines, so hopefully this will give you a start. If you'd like to know more, I suggest searching for articles specifically on WCAG 2.1 and there are lots of excellent resources out there already.

Ask Your Users

Accessibility Statement

WCAG Conformance Claims
Partial Conformance Claim with 3rd Party Content

Take Away

Make it easy to contact you.

Thanks!

Contact

Cynthia Ng
@TheRealArty
about.me/cynthiang