Presentation: How to stay web accessible: Applying WCAG 2.1 & 2.2

This was presented at Code4libBC 2025. I knew what was added in WCAG 2.1 and 2.2 generally, but hadn’t yet looked at how they apply in a practical way yet, so it was a great opportunity to brush up my web accessibility knowledge.

Slides

https://speakerdeck.com/cynthiang/how-to-stay-web-accessible

Slides on GitHub (with interactive examples)

Introduction

I’m not going to give you a detailed bio, but I did want to briefly mention some relevant bits.

• 2012-2013 at Ryerson University Library & Archives (now TMUL)
  • Migrated website and ensured WCAG 2.0 compliance
• 2013-2014 at CAPER-BC (Centre for Accessible Post-secondary Education Resources BC)
  • Migrated website and ensured WCAG 2.0 compliance
  • Accessible book production
• 2014-2016 at National Network for Equitable Library Service (NNELS)
  • Accessible book production and website improvements
• 2018 at GitLab, assist with first Voluntary Product Accessibility Template (VPAT) report
• Web Accessibility advocate

Back in 2012, I worked at what was then called Ryerson University Library, now Toronto Metropolitan University Libraries, where I was tasked with migrating the website to a new platform. In Ontario, WCAG 2.0 compliance was going to be enforced through the Accessibility for Ontarians with Disabilities Act (AODA), so I decided to learn about WCAG and how to apply it in order to help future-proof the website. I did a few presentations and wrote a bunch of articles based on what I learnt as well.

After that, I went on to do similar work at CAPER-BC, where I also learnt about accessible book production, and a lot more about assistive technology. Then at NNELS, I continued to learn even more about accessibility.

While I haven’t done a lot of accessibility work in the past few years, I still try to keep up to date with any significant news, and consider myself an accessibility advocate.

And, an obligatory cute animal, because I like cute animals! This one is from a trip we took earlier this year to Tofino.

What is…?

Alright, to get started, let’s define a couple of terms.

Web accessibility

Here’s the Wikipedia definition of web accessibility, but essentially, we want to make sure that anyone can use websites.

“Web accessibility, or eAccessibility, is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed.” – Wikipedia

While in Canada, our legislation only covers federally regulated sectors, and in BC, legislation only applies to the provincial government¹, we obviously want our organizations to be accessible to everyone.

WCAG

The Web Content Accessibility Guidelines, or Web-CAG in short form, is a set of guidelines published by the World Wide Web Consortium (aka W3C), which is considered the standard for web accessibility.

“Web Content Accessibility Guidelines (WCAG) 2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.” – WCAG 2 Overview: Introduction

That’s not to say that meeting all the criteria will automatically make your website accessible, but it certainly helps identify things that should be done as part of the organization’s “best effort”.

WCAG timeline

Here’s a brief timeline on when the different versions of WCAG have been published, and as you can see, it’s been a number of years since 2.1 and 2.2 were published, but there’s definitely less resources covering the criteria from them.

• WCAG 1.0 : 1999 May
• WCAG 2.0 : 2008 December : 61 success criteria
• WCAG 2.1 : 2018 June : Added 17 new success criteria
• WCAG 2.2 : 2023 October : Added 9 new success criteria, removed 1 obsolete criterion (4.1.1 Parsing)
• WCAG 3.0 (future) : 2025 September (latest draft)

The important thing to know is that all WCAG 2 revisions build upon the previous version, and they are backwards compatible; meaning that meeting 2.1 automatically meets 2.0 requirements, and meeting 2.2 automatically meets 2.1 and 2.0.

What we’re (not) covering

Partly, I don’t really have time for it during a short talk, but mostly, there are a lot of resources out there that cover WCAG 2.0, now that it’s over 15 years old, so I’m not going to cover any of it. You shouldn’t need to be familiar with it to understand the 2.1 and 2.2 additions. Just keep in mind that what I’m covering is only a subset of the guidelines.

For 2.1 and 2.2, WCAG 2 splits conformance level into 3: A, AA, and AAA. Since most standards and legislation require only A or AA, I’ll mention where AAA criteria apply for completeness, but won’t be covering them in detail.

New Success Criteria in WCAG 2.1

New Success Criteria in WCAG 2.2

1.3.4 Orientation (AA) 1.3.5 Identify Input Purpose (AA) 1.3.6 Identify Purpose (AAA) 1.4.10 Reflow (AA) 1.4.11 Non-Text Contrast (AA) 1.4.12 Text Spacing (AA) 1.4.13 Content on Hover or Focus (AA) 2.1.4 Character Key Shortcuts (A) 2.2.6 Timeouts (AAA) 2.3.3 Animation from Interactions (AAA) 2.5.1 Pointer Gestures (A) 2.5.2 Pointer Cancellation (A) 2.5.3 Label in Name (A) 2.5.4 Motion Actuation (A) 2.5.5 Target Size (AAA) 2.5.6 Concurrent Input Mechanisms (AAA) 4.1.3 Status Messages (AA)

2.4.11 Focus Not Obscured (Minimum) (AA) 2.4.12 Focus Not Obscured (Enhanced) (AAA) 2.4.13 Focus Appearance (AAA) 2.5.7 Dragging Movements (AA) 2.5.8 Target Size (Minimum) (AA) 3.2.6 Consistent Help (A) 3.3.7 Redundant Entry (A) 3.3.8 Accessible Authentication (Minimum) (AA) 3.3.9 Accessible Authentication (Enhanced) (AAA)

Template & structure

I’m going to start with criteria that apply to a website as a whole, to its theme and structure, and ending with what applies to content created by individual authors.

Responsive design

WCAG 2.1 added guidelines focused around different screen sizes and orientation.

Orientation is about mobile devices, mostly phones and tablets, where a website should work whether it’s in portrait or landscape mode, unless the orientation is critical to the functionality, which may be the case for a game for example.

• Orientation – AA (1.3.4) – allow portrait and landscape
• Reflow – AA (1.4.10) – content readable/functional at 320px width (400% zoom)

The 320 pixel width for reflow is the guideline based on when content is viewed vertically, and the guidelines specify the minimum width for horizontally viewed content as well, since the goal of reflow is to allow users to zoom into content all the way up to 400%. Reflow also talks about how you should avoid horizontal scrolling, except where necessary such as interactive maps.

Visual design

In WCAG 2.0, there are guidelines around colour contrast ratio already, so the new 1.4.11 focuses on non-textual content, including components and objects, having a 3 to 1 contrast ratio.

• Non-Text Contrast – AA (1.4.11) – 3:1 contrast
• Text Spacing – AA (1.4.12) – stay readable/usable
  • Line height: 1.5× font size
  • Paragraph spacing: 2× font size
  • Letter spacing: 0.12× font size
  • Word spacing: 0.16× font size

Similar to reflow where a site needs to function at 400% zoom, the site needs to be functional, and text needs to stay readable when users adjust the text spacing. The numbers are the minimum scaling size that needs to be met.

Focus

WCAG 2.0 covers how the user needs to see what they’re focused on, such as when navigating a website entirely using a keyboard. WCAG 2.2 adds criteria around the size and contrast requirements, and that what the user is focused on shouldn’t be obscured or hidden.

• Focus Appearance – AAA (2.4.13) – minimum size and contrast requirements
• Focus Not Obscured (Minimum) – AA (2.4.11) – partially hidden is allowed
• Focus Not Obscured (Enhanced) – AAA (2.4.12) – nothing hidden

One of the most common “floating” objects on websites now are sticky headers, so the solution is to use scroll-padding-top.

Content on focus/hover

• Content on Hover or Focus – AA (1.4.13)
  • Dismissible: can be closed without moving pointer/focus (usually ESC key)
  • Hoverable: pointer can move over the new content without it disappearing
  • Persistent: stays visible until dismissed or no longer valid

Common examples of the type of content we’re talking about here are dropdowns, and tooltips.

Animation

WCAG 2.1 also adds

• Animation from Interactions – AAA (2.3.3)

which revolves around motion sensitivity, and providing an option to disable non-essential animations.

Input and pointer interactions

I mentioned that not everyone uses a mouse, and you’ve probably heard about or seen many assistive devices.

One of the goals of WCAG is to make sure that people can use just about any human-computer interfacing device to interact with websites.

Keyboard and input accessibility

WCAG 2.1 builds on this idea with some new criteria.

• Character Key Shortcuts – A (2.1.4) – don’t conflict; single-key off/remap option
• Concurrent Input Mechanisms – AAA (2.5.6) – allow multiple inputs
• Label in Name – A (2.5.3) – programmatic name has label text

The first is that keyboard shortcuts should not conflict with assistive technology, and for single-key shortcuts, the user should be able to remap (change) them or turn them off.

The second basically says not to restrict the input device or method the user wants to use unless it’s essential.

The third, “label in name”, may be difficult to understand without context. Input fields (typically form fields, including a site search) have names that are part of the code. These names can be different from the visible label that you see next to the field. For users that rely on speech recognition to navigate, they may not be able to go to the correct field if the programmatic name in the code differs from the visual text, because they tell their device to navigate to the label they see, and the device might not find the field if the name differs too much, or they might end up on the wrong field. The common solution is to have the name always match the label, or sometimes have the name be a combination of the field set and the specific field. Either way, the label is then a part of the name.

I’ll be talking more about forms later, but wanted to mention this here, because ideally, input components are programmed to derive the name from the label rather than being specified by the content creator.

Touch and pointer interaction

We say pointer, instead of mouse pointer, because people aren’t always using a mouse; but think of the screen cursor or pointer.

Target size

Here, we’re talking about the minimum size of an interactive element. Basically, whether it’s with a pointer or on a touch screen, you want anything users can interact with, such as buttons, to be big enough so they don’t trigger the wrong thing.

• Target Size (Minimum) – AA (2.5.8) – 24×24 px or 24px diameter spacing
• Target Size (Enhanced) – AAA (2.5.5) – 44×44 px

Pointer cancellation

Speaking of which, WCAG 2.1 introduced the pointer cancellation criterion.

• Pointer Cancellation – A (2.5.2)
  • down-event not used,
  • up-event and allow undo,
  • up reversal, or
  • essential

If you think about how you use a mouse, to click on something, you have to press the mouse button down, and then let the mouse button come back up. These actions are what we refer to as the down-event and up-event respectively.

So the criterion says if you’re using a single pointer interaction for anything, at least one of four things must be true:

1. The down-event is not used to trigger the action. Instead, you typically want to use the up-event so that the user has to press and let go again to trigger the action.
2. If you do use the up-event to trigger the action, then you have a way for the user to abort or undo the action.
3. The up-event reverses the down-event.
4. Triggering on the down-event is considered essential. For example, if you have an on-screen keyboard, the user expects letters to show up as they press the keys, not when letting go.

Dragging

When you click/tap and hold on something, you can often drag elements around.

• Dragging Movements – AA (2.5.7) – single-pointer alternative

Sometimes dragging is considered essential, say drawing a line in an image app. Otherwise, a single click or tap alternative, instead of dragging, should be available to achieve the same thing.

Gesture accessibility

I’m sure you’re seeing a pattern where a lot of the criteria revolve around allowing multiple ways for users to do things. The next set is no exception.

Motion Actuation says you need to provide alternative controls and the ability to turn off things triggered by moving a device, such as shake and tilt, unless of course, it’s necessary, such as a step-counter.

• Motion Actuation – A (2.5.4) – alternative & disable option
• Pointer Gestures – A (2.5.1) – provide simple alternatives

Similarly, Pointer Gestures says to provide alternatives to functionality that needs multiple pointers or path-based gestures. You can have them, but they shouldn’t be the only option. A common example is using two fingers to zoom in and out, where typically you have buttons as a single pointer alternative.

Site content

With site content, let’s start with something simple.

Consistent navigation

In WCAG 2.0, there’s already a criterion about making navigation consistent. In 2.2, they decided to explicitly call out making help options consistent.

• Consistent Help – A (3.2.6)

Regardless of the type of help option, be that chat, contact form, self-help, or whatever else, they need to be in the same relative order across all pages.

Forms and input fields

The rest of the new criteria revolve around things related to forms and input fields.

Identify purpose

• Identify Input Purpose – AA (1.3.5) – autocomplete
• Identify Purpose – AAA (1.3.6) – for all user interface components, icons, and regions

Basically, the idea here is that for form fields, in addition to a descriptive label and proper “type”, the “autocomplete” attribute should also be used to identify the purpose of a field.

<label for="user-phone">Phone Number</label>
<input type="tel" id="user-phone" autocomplete="tel">

1.3.6 takes this further to say all components, icons, and regions need to have their purpose identified, typically using the “role” attribute and ARIA tags.

Redundant Entry

Building on the autocomplete idea,

• Redundant Entry – A (3.3.7)

says to autocomplete or pre-fill form fields as much as possible with the information you already have.

Authentication

When asking users to authenticate, there’s often one or more “cognitive function test”, which is something that “requires the user to remember, manipulate, or transcribe information” (WCAG definition). Common examples include asking users for a password, or to solve a captcha.

To successfully meet the criteria, either don’t require a cognitive function test, or if you do, have one of the following:

• Accessible Authentication (Enhanced) – AAA (3.3.9)
  • alternative non-cft authentication method
  • mechanism to assist
• Accessible Authentication (Minimum) – AA (3.3.8)
  • object recognition
  • non-text personal content

an alternative authentication method that doesn’t require a cognitive function test, or a mechanism that can assist the user in doing what’s required. For example, allowing a password manager to autofill the password field is considered a satisfactory mechanism.

The minimum version additionally allows two other options:

1. the cognitive function test is recognizing objects, which is common for captchas these days, where you have to identify a common thing (like stairs or cars) in a set of images, and
2. the test is identifying non-textual content provided by the user, which some social media sites have used where for example they ask you to identify who is in a photo you uploaded and tagged.

Status messages

A status message might be used for all sorts of things. For example, progress, errors, success, or failure.

• Status messages – AA (4.1.3)

What matters is that these messages and status changes must be announced to users through relevant assistive technology, such as screen readers, without taking focus away, which can be done using aria-live="polite".

Timeouts

In my experience, most websites where there’s a timeout already do this.

• Timeouts – AAA (2.2.6) – show time left

When a session has a time limit or is about to expire, show the amount of time left until it expires.

Testing and validation

Obviously, you’ll need to test your website and the content. There are lots of methods and tools available, including:

• Automated testing (covers 20-60%²): axe, WAVE, Lighthouse
• Browser/design tools: accessibility panel, responsive design mode
• Manual testing: screen readers, keyboard-only

These are just examples, and testing and validation is basically the same as the established practices for WCAG 2.0, so I encourage you to see what’s out there already, or even some of my previous presentations.

Takeaway

With all that, while WCAG is geared towards helping people with disabilities,

“WCAG covers a wide range of recommendations for making web content more accessible, [and f]ollowing these guidelines will also often make web content more usable to users in general.” – WCAG 2.2 : Abstract

That’s a lot of information in a very short time, but hopefully I’ve covered them in a way that helps you understand not only what they are, but which ones you may need to pay attention to depending on your role as developer, content creator, or somewhere in between. And that this presentation, which I’ll be posting online, can act as a reference.

Thank you. Questions?