1 of 104

Inspecting WCAG 2.2: accessible authentication

A GOV.UK Design System workshop

2 of 104

Welcome!

3 of 104

We’re recording the session today.

Feel free to take screenshots of slides, but not your fellow attendees.

GDS

4 of 104

This is a safe space for learning.

Please be kind, and feel free to speak openly.

GDS

5 of 104

Vibe check

GDS

6 of 104

Meeting hygiene:

Please stay on mute unless talking.

Use the ‘Raise Hand’ option in the Reactions menu during discussion times.

GDS

7 of 104

Find out about our GOV.UK Design System

events.

GDS

8 of 104

Our plan for today

9 of 104

  • About WCAG 2.2 and this workshop series
  • About ‘Accessible Authentication’
  • Demonstrating an example
  • Group activity in breakout rooms
  • Regroup and discuss!
  • Wrap-up and retrospective

GDS

10 of 104

All of today’s links and resources can be found in our workshop Google Doc.

GDS

11 of 104

Our facilitators today are:

  • Steve Messer (product manager)
  • David Cox (senior accessibility specialist)
  • Kelly Lee (delivery manager)

GDS

12 of 104

What is WCAG 2.2?

13 of 104

WCAG is an acronym for:

Web Content Accessibility Guidelines

GDS

14 of 104

Version 2.2

GDS

15 of 104

Basically, it’s an expansion pack!

  • More criteria to choose from
  • Updated glossary of definitions
  • A last-minute removal

GDS

16 of 104

What are the 9 new criteria?

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

GDS

17 of 104

WCAG 2.2 is now published as a full recommendation!

GDS

18 of 104

The UK Government’s accessibility monitoring body will start checking services and websites against WCAG 2.2 a year after the recommendation published.

So… October 2024!

GDS

19 of 104

Our team, the GOV.UK Design System, plan to update our codebase and guidance within 6 months of WCAG 2.2 being published.

So… by April 2024!

GDS

20 of 104

About this workshop series

21 of 104

This workshop series was developed for a few reasons.

GDS

22 of 104

Reason 1:

Some criteria in WCAG 2.2 can be complicated to test for.

GDS

23 of 104

Reason 2:

�Service teams in the UK Government will need to do more than just update to the latest version of GOV.UK Frontend.

GDS

24 of 104

Reason 3:

�We want to make sure we base our GOV.UK Design System updates on solid inspections and interpretations.

GDS

25 of 104

We’re covering 3 criteria.

Focus not obscured

Target size

Authentication

26 of 104

The ‘learning’ portions of the 3 workshops will be published to the Government Digital Service YouTube channel.

(...Once we clean up the captions and transcripts)

GDS

27 of 104

Today’s workshop will be interactive and involves:

  • Discussion
  • Note-taking
  • Hands-on inspection
  • Idea-sharing

GDS

28 of 104

Accessible Authentication explainer

Courtesy of the Accessibility Monitoring team

29 of 104

Accessible authentication (AA)

Logging in must not rely on a cognitive test.

GDS

30 of 104

Examples of inaccessible authentication:

  • remembering a password without autofill
  • manually entering a security code from another device
  • doing a maths problem
  • solving a puzzle

GDS

31 of 104

Examples of accessible authentication:

  • passwords with support for password managers
  • copy/pasting a security code from the same device
  • recognising objects
  • identifying images the user has provided

GDS

32 of 104

It’s OK to use a less accessible method as long as an accessible alternative is provided.

GDS

33 of 104

There’s also a AAA version of accessible authentication where object recognition and user-provided content aren’t allowed.

GDS

34 of 104

The quick-check for Accessible Authentication

Courtesy of me

35 of 104

WCAG 2.2 Success Criteria 3.3.8 and 3.3.9

Accessible Authentication

If there’s a login process with:

  • a ‘test’
  • something a user needs to ‘remember’
  • no autofill options for inputs

…Those are clues! It may be worth taking a closer look.

GDS

36 of 104

The deep-dive for Accessible Authentication

Courtesy of WCAG and me

37 of 104

The actual text from criterion 3.3.8:

“A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process…”

GDS

38 of 104

There’s 4 exceptions in criterion 3.3.8:

“...unless that step provides at least one of the following…”

GDS

39 of 104

Provide an alternative

“Another authentication method that does not rely on a cognitive function test.”

GDS

40 of 104

Provide an assistive mechanism

“A mechanism is available to assist the user in completing the cognitive function test.”

GDS

41 of 104

Use object recognition (won’t pass AAA)

“The cognitive function test is to recognize objects.”

GDS

42 of 104

Use personal content (won’t pass AAA)

“The cognitive function test is to identify non-text content the user provided to the Web site.”

GDS

43 of 104

WCAG 2.2 includes two ‘understanding’ documents for Accessible Authentication.

They explain some of the intent and other potentially helpful information for the ‘minimum’ and ‘enhanced’ success criteria.

GDS

44 of 104

The tragic reveal:

‘Accessible Authentication’ in WCAG is strictly limited to logins.

GDS

45 of 104

Just because you can apply the word ‘authentication’, that doesn’t mean WCAG 2.2 ‘Accessible Authentication’ applies.

GDS

46 of 104

As far as I can tell…

And correct me if I’m wrong…

It does not appear to apply in many cases.

GDS

47 of 104

The Accessible Authentication (minimum) understanding document says:

GDS

48 of 104

“ Goal

Make logins possible with less mental effort.

GDS

49 of 104

“ What to do

Don’t make people solve, recall, or transcribe something to log in.

GDS

50 of 104

“ Why it's important

Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes.

GDS

51 of 104

Those 3 points pretty much sum it up.

But what does this mean?

Many non-login processes could potentially remain ‘out of scope’ and inaccessible.

GDS

52 of 104

It’s still worthwhile and important to make logins accessible, but does this leave out?

GDS

53 of 104

Sign-up and registrations don’t count. 😞

  • Creating a new account
  • Signing a petition
  • Applying to join a private beta

GDS

54 of 104

CAPTCHAs outside of logins don’t count. 😿

  • Uploading a file
  • Submitting a form
  • DDoS and other protective measures

GDS

55 of 104

IDs for ‘authentication’ don’t count. 😔

  • National Insurance numbers (SIN, SSN)
  • Passport details
  • Driving licences

GDS

56 of 104

According to both the AA and AAA levels of ‘Accessible authentication’, we only need to make logins more accessible.

GDS

57 of 104

So we could leave it at that…

Or break the rules a bit. 😉

GDS

58 of 104

Let’s break the rules a bit. 🔨

  • Revisit use of CAPTCHAs everywhere
  • Make the sign-up process accessible
  • Recognise how difficult it can be to find, read and enter official ID numbers

GDS

59 of 104

Okay but also,

make logins accessible.

GDS

60 of 104

There’s generally 4 areas where accessible authentication comes up in login processes:

  • Entering credentials into inputs
  • Verifying it’s a legitimate human request
  • Verifying it’s a request from a specific human
  • Multi-factor authentication

GDS

61 of 104

1. Entering credentials into inputs

  • Don’t block copying and pasting
  • Allow people to autofill
  • Provide a method to show password characters
  • Allow password managers to access fields
  • Add proper HTML autocomplete attributes

GDS

62 of 104

2. A legitimate human request

  • Try alternatives before adding CAPTCHA
  • Look for CAPTCHA with accessible controls
  • Offer multiple sensory formats (audio, visual)
  • Don’t rely on maths or logic puzzles
  • Provide alternative verification options (

GDS

63 of 104

Some alternatives to CAPTCHA include:

  • Human or automated review of submissions
  • Honeypot form fields for robots to fill out
  • ‘Non-interactive’ confidence scores
  • Multi-factor authentication
  • Spam filtering

GDS

64 of 104

3. A request from a specific human

  • Consider whether it’s necessary in each case
  • Don’t ask to recall transactions or details
  • Avoid asking to identify personal content
  • Don’t ask for transcription; present options
  • Don’t present sensitive info before login

GDS

65 of 104

4. Multi-factor authentication

  • Check if there’s value in requiring 2+ factors
  • Verification code input fields need to allow paste
  • Avoid a journey that requires transcribing
  • Second factors that are generally good to go:
    • Hardware-based
    • Biometric, from operating systems

GDS

66 of 104

Notes on CAPTCHA 🤖

GDS

67 of 104

Warning: mild spice ahead 🌶️

GDS

68 of 104

Both the AA and AAA levels do technically allow the use of CAPTCHAs…

…but most of the common CAPTCHA tools aren’t going to meet the AAA level.

GDS

69 of 104

“Recognizing objects, or a picture the user has provided is a cognitive function test; however, it is excepted at the AA level.”

GDS

70 of 104

Also, the allowance of CAPTCHAs at all within ‘accessible authentication’ doesn’t mean that CAPTCHAs are inclusive.

They, by design, create barriers for people with cognitive accessibility needs.

GDS

71 of 104

The main point:

Having a CAPTCHA sit inside a login process doesn’t make it any more or less inaccessible. So why treat logins differently?

GDS

72 of 104

In this case, I recommend not letting WCAG dictate how far your team goes in building accessible services.

Make the whole journey accessible.

GDS

73 of 104

A bonus CAPTCHA note from the ‘understanding’ document:

The criterion still applies to CAPTCHAs that only appear sometimes (like after entering a password incorrectly multiple times).

GDS

74 of 104

End of CAPTCHA thoughts.

GDS

75 of 104

Summing up:

‘Accessible Authentication’ makes login experiences better and more accessible.

But the lessons here extend beyond logins.

GDS

76 of 104

My personal plan:

Pretend ‘accessible authentication’ applies to all forms of authentication.

GDS

77 of 104

Why that’s my plan:

Authentication processes, wherever they are:

  • can be stressful
  • require increased cognitive effort
  • act as pass/fail barriers for real people

GDS

78 of 104

5 mins: Questions, clarification and knowledge-sharing

79 of 104

Inspection tips

80 of 104

Try out the full login process for yourself.

Make note of any points of increased effort or ‘ugh, now I have to think’.

GDS

81 of 104

Interact with inputs

  • Try copying and pasting
  • Look for show / hide options on passwords

GDS

82 of 104

Look for ‘cognitive tests’

  • Recognising objects
  • Maths and other skills-based questions
  • Interpreting from images or audio

GDS

83 of 104

Use the ‘inspector’ browser tools to see if inputs are built properly.

In particular, autocomplete= attributes.

GDS

84 of 104

Demonstration of an inspection

85 of 104

5 mins: Questions, clarification and knowledge-sharing

86 of 104

Today’s workshop breakout activity

87 of 104

Each team gets an example service

Each service has 1 sign-up and 1 login

GDS

88 of 104

I recommend also having the ‘Understanding’ document pulled up for reference

GDS

89 of 104

In your groups:

  • facilitate discussion
  • take notes in the doc
  • make sure everyone’s included
  • prepare to share what you’ve learned

GDS

90 of 104

Step 1:

Test out the sign-up process and determine if anything stands out as related to ‘accessible authentication’.

Record results of the sign-up test.

GDS

91 of 104

Example notes area

GDS

92 of 104

Step 2:

Inspect the login processes to see if it passes ‘Accessible Authentication (minimum)’, based on the success criterion language and the draft ‘understanding’ document.

Record results of the login inspection.

GDS

93 of 104

Step 3:

Check agreement in the group before moving on.

Consensus isn’t needed, but record any doubts and try to resolve them.

GDS

94 of 104

Time to break out and workshop it!

Take note of the link in the chat.

95 of 104

Regroup and share insights

96 of 104

Please stay on mute unless talking.

Use the ‘Raise Hand’ option in the Reactions menu.

GDS

97 of 104

Thank you so much for participating!

98 of 104

More resources

99 of 104

Web Accessibility Initiative:

What’s new in WCAG 2.2

GDS

100 of 104

Relevant blog post:

How we are improving inclusion for digital identity in government

“The very biggest government services have to cater for everyone in society and therefore can’t adopt an identity solution that isn’t inclusive.”

GDS

101 of 104

GOV.UK Design System GitHub tickets:

GDS

102 of 104

Final questions�and ideas

103 of 104

Wrap-up and retro

104 of 104

David Cox dav-idcox on LinkedIn

Steve Messer

Government Digital Service�