1 of 349

Towards �amazing accessibility!

Introduction to accessibility testing and “shifting left” to operationalise amazing accessibility throughout the development life cycle.

https://matthewdeeprose.github.io/amazing.html

1

2 of 349

Handout

All notes and links are available at:

https://matthewdeeprose.github.io/amazing.html

2

3 of 349

Accessibility is a journey

https://matthewdeeprose.github.io/amazing.html

3

4 of 349

Current state

https://matthewdeeprose.github.io/amazing.html

4

Current state

Amazing accessibility

Baseline accessibility / Legal compliance

5 of 349

Cost of accessibility bugs

https://matthewdeeprose.github.io/amazing.html

5

Cost

Requirements Design Build Test Release

Source: Glenda Sims, Deque

Cost of accessibility bugs

6 of 349

When should we consider accessibility?

https://matthewdeeprose.github.io/amazing.html

6

Cost

Requirements Design Build Test Release

Source: Glenda Sims, Deque

The earlier we consider accessibility the better!

7 of 349

Shifting left through the process (4)

https://matthewdeeprose.github.io/amazing.html

7

Shift left

Requirements

Design

Build

Test

Release

Include accessibility within project documentation.
TAG Non Functional Requirements.
Accessible procurement

Involve users (including with impairments) in co-design.
Accessible component library and atomic design elements.
Annotate wireframes with accessibility details.

Linters and IDE plugins.
Framework extensions (e.g. Bootstrap accessibility plugin)
Git actions.

Browser based test tools.
Checklists / checking sheet.
Command line tools.
CI tools.
Automated tests with Selenium etc.
Gherkin tests.

Publish Accessibility statement as part of go-live checklist.
Accessibility testing as part of Change Management.
Dashboards.
Review accessibility statements annually.

Shift left

8 of 349

Agenda

What accessibility barriers might users experience?

Examples from our own services.

How we can “shift left” to start our journey toward amazing accessibility.

Examples from across the IT sector.
Links to find out more.

Practical steps in accessibility testing you can use.
Digital Accessibility and the Law.

https://matthewdeeprose.github.io/amazing.html

8

Note: Almost half the slides in this deck are hidden, view the full deck for all the information.

9 of 349

Why should we care? 0

https://matthewdeeprose.github.io/amazing.html

9

https://web.microsoftstream.com/video/ae24ab7b-32ac-489c-bf51-5c937cd60f06

10 of 349

What barriers might users experience? 0

https://matthewdeeprose.github.io/amazing.html

10

11 of 349

What barriers might users experience?

https://matthewdeeprose.github.io/amazing.html

11

Following accessibility guidelines removes such barriers.

Unusable with keyboard

Poor text colour contrast, or only using colour to express meaning.

When a screen reader cannot make sense of an interface.

Forms that hold key information within placeholders or are missing labels.

Timeouts without warning.

12 of 349

What barriers might users experience? (1)

https://matthewdeeprose.github.io/amazing.html

12

Following accessibility guidelines removes such barriers.

Unusable with keyboard

Poor text colour contrast, or only using colour to express meaning.

When a screen reader cannot make sense of an interface.

Forms that hold key information within placeholders or are missing labels.

Timeouts without warning.

13 of 349

What barriers might users experience? (3)

https://matthewdeeprose.github.io/amazing.html

13

Following accessibility guidelines removes such barriers.

Unusable with keyboard

Poor text colour contrast, or only using colour to express meaning.

When a screen reader cannot make sense of an interface.

Forms that hold key information within placeholders or are missing labels.

Timeouts without warning.

14 of 349

What barriers might users experience? (4)

https://matthewdeeprose.github.io/amazing.html

14

Following accessibility guidelines removes such barriers.

Unusable with keyboard

Poor text colour contrast, or only using colour to express meaning.

When a screen reader cannot make sense of an interface.

Forms that hold key information within placeholders or are missing labels.

Timeouts without warning.

15 of 349

What barriers might users experience? (5)

https://matthewdeeprose.github.io/amazing.html

15

Unusable with keyboard

Poor text colour contrast, or only using colour to express meaning.

When a screen reader cannot make sense of an interface.

Forms that hold key information within placeholders or are missing labels.

Timeouts without warning.

Following accessibility guidelines removes such barriers.

16 of 349

Colour Contrast / Colour as only meaning

https://matthewdeeprose.github.io/amazing.html

16

iSolutions real world example

17 of 349

When a screen reader cannot make sense of an interface. (2)

https://matthewdeeprose.github.io/amazing.html

17

Example from https://www.youtube.com/watch?v=0hqhAIjE_8I

“List with 3 items.

First item.

UI Design.

Button”

18 of 349

When a screen reader cannot make sense of an interface.

https://matthewdeeprose.github.io/amazing.html

18

“List with 3 items.

First item.

UI Design.

Button Collapsed”

Example from https://www.youtube.com/watch?v=0hqhAIjE_8I

19 of 349

Forms

https://matthewdeeprose.github.io/amazing.html

19

20 of 349

Timeouts

https://matthewdeeprose.github.io/amazing.html

20

21 of 349

Top 4 web frustrations: also accessibility issues. 1

The top 4 frustrations:

Unwanted interruptions: 28%
Poor user experience: 19%
Poor readability: 18%
Poor form usability: 15%

Interruptions and distractions:

https://matthewdeeprose.github.io/amazing.html

21

22 of 349

Top 4 web frustrations: also accessibility issues. 2

The top 4 frustrations:

Unwanted interruptions: 28%
Poor user experience: 19%
Poor readability: 18%
Poor form usability: 15%

Form usability:

https://matthewdeeprose.github.io/amazing.html

22

23 of 349

Top 4 web frustrations: also accessibility issues. 3

The top 4 frustrations:

Unwanted interruptions: 28%
Poor user experience: 19%
Poor readability: 18%
Poor form usability: 15%

Readability:

https://matthewdeeprose.github.io/amazing.html

23

24 of 349

Top 4 web frustrations: also accessibility issues. 4

The top 4 frustrations:

Unwanted interruptions: 28%
Poor user experience: 19%
Poor readability: 18%
Poor form usability: 15%

Form usability:

https://matthewdeeprose.github.io/amazing.html

24

25 of 349

What about our own systems?

https://matthewdeeprose.github.io/amazing.html

25

26 of 349

Eassignment system

https://matthewdeeprose.github.io/amazing.html

26

iSolutions real world example

27 of 349

Eassignment system 2

When browser zoom increased cannot scroll left or right or up or down.
Focus indicator has been hidden. Making use with keyboard almost impossible.

https://matthewdeeprose.github.io/amazing.html

27

iSolutions real world example

28 of 349

Eassignment system 3

When browser zoom increased cannot scroll left or right or up or down.
Focus indicator has been hidden. Making use with keyboard almost impossible.

https://matthewdeeprose.github.io/amazing.html

28

iSolutions real world example

29 of 349

COVID guidance page

University COVID information page used an accordion design pattern that could only be used with a mouse.

https://matthewdeeprose.github.io/amazing.html

29

iSolutions real world example

30 of 349

COVID guidance page 2

INC1847426 raised 13 March 2020.

Internal worklog “we'll see if we have the resources to fix”

https://matthewdeeprose.github.io/amazing.html

30

iSolutions real world example

31 of 349

COVID guidance page 3

INC1847426 raised 13 March 2020.

No response to user.

https://matthewdeeprose.github.io/amazing.html

31

iSolutions real world example

32 of 349

COVID guidance page 4

More than 12 months later, no activity within ticket.

https://matthewdeeprose.github.io/amazing.html

32

iSolutions real world example

33 of 349

COVID guidance page 5

I emailed Ayala about it on 16 March, it was then fixed within a day.

Thanks Ayala!

And thanks Graeme for implementing the fix!

https://matthewdeeprose.github.io/amazing.html

33

iSolutions real world example

34 of 349

OneWeb

By the way, the OneWeb team are will be working on further on UI patterns and components and their use with corporate comms and marketing.

https://matthewdeeprose.github.io/amazing.html

34

35 of 349

What might this tell us? 1

During the beginning of a pandemic UoS users who couldn't use a mouse or trackpad were blocked from accessing vital COVID information.

It will only get fixed if we know the right people.

https://matthewdeeprose.github.io/amazing.html

35

iSolutions real world example

36 of 349

What might this tell us? 3

During the beginning of a pandemic UoS users who couldn't use a mouse or trackpad were blocked from accessing vital COVID information.

It will only get fixed if we know the right people.

https://matthewdeeprose.github.io/amazing.html

36

iSolutions real world example

37 of 349

What might this tell us? 4

We did not test the accessibility of the accordion design pattern as implemented in our CMS.

https://matthewdeeprose.github.io/amazing.html

37

iSolutions real world example

38 of 349

This wasn’t due to lack of skill or knowledge

https://matthewdeeprose.github.io/amazing.html

38

39 of 349

Software Engineer

“Knowledge of modern HTML and CSS and the impact that high quality mark-up can have on performance, accessibility and discoverability.”

Person Specification – Essential

https://matthewdeeprose.github.io/amazing.html

39

40 of 349

Senior Software Engineer / Senior Software Engineer Team Lead

“Experience of modern HTML and CSS and the impact that high quality mark-up can have on performance, accessibility and discoverability.”

Person Specification – Essential

https://matthewdeeprose.github.io/amazing.html

40

41 of 349

What does this tell us? 9

Until the accordion component was fixed, any other content using that design pattern was inaccessible to those who could not use a mouse or track pad.

https://matthewdeeprose.github.io/amazing.html

41

42 of 349

What does this tell us? 95

Because it was a component within the CMS, once fixed, all content using that pattern was accessible.

https://matthewdeeprose.github.io/amazing.html

42

43 of 349

What might this tell us? 5

It wasn’t part of the requirements to ensure accessibility.

It wasn’t part of the release process to assure accessibility.

https://matthewdeeprose.github.io/amazing.html

43

44 of 349

What might this tell us? 6

It wasn’t part of the requirements to ensure accessibility.

It wasn’t part of the release process to assure accessibility.

https://matthewdeeprose.github.io/amazing.html

44

45 of 349

What else does this tell us?

We don’t know what other barriers we have constructed that may prevent users from fulfilling their ambitions at the University.

https://matthewdeeprose.github.io/amazing.html

45

46 of 349

Cost of accessibility bugs (again)

https://matthewdeeprose.github.io/amazing.html

46

Cost

Requirements Design Build Test Release

Source: Glenda Sims, Deque

47 of 349

When should we consider accessibility? 2

https://matthewdeeprose.github.io/amazing.html

47

Cost

Requirements Design Build Test Release

Source: Glenda Sims, Deque

The earlier we consider accessibility the better!

48 of 349

Using examples from

https://matthewdeeprose.github.io/amazing.html

48

49 of 349

Agile Accessibility Handbook

https://matthewdeeprose.github.io/amazing.html

49

https://www.amazon.co.uk/dp/164543477X/ref=cm_sw_r_tw_dp_CM86XQFQ4KKRZ04Z2Z3N

50 of 349

Shifting left through the process (10)

https://matthewdeeprose.github.io/amazing.html

50

Requirements

Design

Build

Test

Release

“Make sure it’s accessible”

“We have to make it accessible”.

“Only release when it’s accessible”

Shift left

“We have to test that it’s accessible.”

51 of 349

Why should we care? (1) Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.�

https://matthewdeeprose.github.io/amazing.html

51

Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.

It’s the law.

It saves money.

It’s the right thing to do.

Competitive advantage.

52 of 349

The number of students who disclose a disability at UoS is increasing. (1)

https://matthewdeeprose.github.io/amazing.html

52

The proportion of new entrants disclosing a disability increased by 41% this year (from 8.1% to 11.4%)*

13.1% of all students disclosed a disability in 2020/21.*

Students may be unwilling to disclose disabilities.**

Some students may come to understand they have an impairment during study or not at all.

Disclosures do not encompass all types of impairment or preference students may have.

* https://go.soton.ac.uk/dkr

** https://bit.ly/3gDtxyz

Removing barriers is important because the number of students who disclose a disability at Southampton is increasing.

Whilst authors such as Jacklin (2011), Riddell and Weedon (2014) and Shakespeare (2006) argue that students may not acknowledge disability as being part of their identity.

Madriaga (2007, p. 407) suggests that students do not disclose to their tutors because they do not want to be viewed negatively or to be perceived as a problem, which Madriaga concludes is a

“medical model of disability”, which assumes that individuals with a disability experience difficulties fitting in to “normal societal rules” because of their disability (Priestley, 2003, p. 12).

High achieving students may have developed coping mechnisms that mask a disability or impairment even from themselves.

53 of 349

The number of students who disclose a disability at UoS is increasing. (2)

https://matthewdeeprose.github.io/amazing.html

53

The proportion of new entrants disclosing a disability increased by 41% this year (from 8.1% to 11.4%)*

13.1% of all students disclosed a disability in 2020/21.*

Students may be unwilling to disclose disabilities.**

Some students may come to understand they have an impairment during study or not at all.

Disclosures do not encompass all types of impairment or preference students may have.

* https://go.soton.ac.uk/dkr

** https://bit.ly/3gDtxyz

54 of 349

The number of students who disclose a disability at UoS is increasing. (3)

https://matthewdeeprose.github.io/amazing.html

54

The proportion of new entrants disclosing a disability increased by 41% this year (from 8.1% to 11.4%)*

13.1% of all students disclosed a disability in 2020/21.*

Students may be unwilling to disclose disabilities.**

Some students may come to understand they have an impairment during study or not at all.

Disclosures do not encompass all types of impairment or preference students may have.

* https://go.soton.ac.uk/dkr

** https://bit.ly/3gDtxyz

55 of 349

The number of students who disclose a disability at UoS is increasing. (4)

https://matthewdeeprose.github.io/amazing.html

55

The proportion of new entrants disclosing a disability increased by 41% this year (from 8.1% to 11.4%)*

13.1% of all students disclosed a disability in 2020/21.*

Students may be unwilling to disclose disabilities.**

Some students may come to understand they have an impairment during study or not at all.

Disclosures do not encompass all types of impairment or preference students may have.

* https://go.soton.ac.uk/dkr

** https://bit.ly/3gDtxyz

56 of 349

The number of students who disclose a disability at UoS is increasing. (5)

https://matthewdeeprose.github.io/amazing.html

56

The proportion of new entrants disclosing a disability increased by 41% this year (from 8.1% to 11.4%)*

13.1% of all students disclosed a disability in 2020/21.*

Students may be unwilling to disclose disabilities.**

Some students may come to understand they have an impairment during study or not at all.

Disclosures do not encompass all types of impairment or preference students may have.

* https://go.soton.ac.uk/dkr

** https://bit.ly/3gDtxyz

57 of 349

Aims of UoS Access and Participation strategy

Reduce non-continuation rates of students with disability.

Close gap in attainment for students who disclose disability.

Close gap in progression for students who disclose a disability.

iSolutions services that meet accessibility guidelines can help the University toward this goal?

https://matthewdeeprose.github.io/amazing.html

57

58 of 349

Maximise the potential of the University’s digital estate for all stakeholders.

https://matthewdeeprose.github.io/amazing.html

58

Microsoft Design

59 of 349

Increasing need for assistive technology

https://matthewdeeprose.github.io/amazing.html

59

60 of 349

Discussions with Occupational Health

Informal feedback is referral form give the impression it’s “the beginning of the end of someone’s career”
Most common issues related to IT are:

Vision
Hearing
Dexterity

There is an opportunity to make clearer how to use assistive IT features.

https://matthewdeeprose.github.io/amazing.html

60

61 of 349

Most common issues OH related to IT are:

https://matthewdeeprose.github.io/amazing.html

61

Vision

Hearing

Dexterity

Opportunity:�

As part of delivering amazing accessibility, provide more information about how to use accessibility features such as:

Browser zoom
Change OS font size
Dictation (speech to text) features
Immersive reader
Reader mode
Text to speech (read aloud mode)
etc

62 of 349

Occupational Health�Most common issues related to IT are:

https://matthewdeeprose.github.io/amazing.html

62

Vision

Hearing

Dexterity

63 of 349

Do we know how accessible our services are? 3

Can all of our services by used with a keyboard?
Can all of our services be used at 400% zoom without scrolling?
Do our services have text and UI components with enough contrast?

https://matthewdeeprose.github.io/amazing.html

63

64 of 349

Do we know how accessible our services are? 2

Can all of our services by used with a keyboard?
Can all of our services be used at 400% zoom without scrolling?
Do our services have text and UI components with enough contrast?

https://matthewdeeprose.github.io/amazing.html

64

65 of 349

Do we know how accessible our services are? 1

Can all of our services by used with a keyboard?
Can all of our services be used at 400% zoom without scrolling?
Do our services have text and UI components with enough contrast?

https://matthewdeeprose.github.io/amazing.html

65

66 of 349

What does the strategy say?

“[enable] the exploitation of digital technology by the University”

https://matthewdeeprose.github.io/amazing.html

66

67 of 349

Occupational Health Referral Form Language

https://matthewdeeprose.github.io/amazing.html

67

“Currently fit for work?”

“Fit to fulfil their contracted duties?”

“Considered for redeployment on medical grounds”

“Health condition affecting their performance or attendance at work?”

68 of 349

Why should we care? (3) It saves money

https://matthewdeeprose.github.io/amazing.html

68

Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.

It’s the law.

It saves money.

It’s the right thing to do.

Competitive advantage.

69 of 349

It saves money

https://matthewdeeprose.github.io/amazing.html

69

Following accessible practices reduces page size and load time.*

Accessible mark up requires less maintenance to make compatible with future devices.**

Standardising with accessible user interface patterns and components means not reinventing the wheel.

Students who study at UoS with a disclosed disability are less likely to continue their programme of study***

* https://www.mightybytes.com/blog/digital-accessibility-series-part-one/

** https://www.w3.org/WAI/fundamentals/accessibility-principles/#robust

*** UoS Access and Participation Plan

70 of 349

Why should we care? (4) it’s the right thing to do

https://matthewdeeprose.github.io/amazing.html

70

Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.

It’s the law.

It saves money.

It’s the right thing to do.

Competitive advantage.

71 of 349

It’s the right thing to do

https://matthewdeeprose.github.io/amazing.html

71

Accessibility features in products and services often solve unanticipated problems. *

40% of households have at least 1 disabled person. **

We all will benefit from Assistive Technologies at some point in our lives. ***

* https://www.w3.org/WAI/business-case/

** https://www.scope.org.uk/media/disability-facts-figures/

*** https://www.who.int/news-room/fact-sheets/detail/assistive-technology

72 of 349

It’s the right thing to do 2

https://matthewdeeprose.github.io/amazing.html

72

73 of 349

What does the strategy say? (2)

“We will:

Get the basics right
Continually [improve] our services”

https://matthewdeeprose.github.io/amazing.html

73

74 of 349

Why should we care? (5) Competitive advantage

https://matthewdeeprose.github.io/amazing.html

74

Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.

It’s the law.

It saves money.

It’s the right thing to do.

Competitive advantage.

75 of 349

Your competitive advantage

Many roles in iSolutions already have accessibility within their job description or person specification.

(6 roles, 49 current posts)

https://matthewdeeprose.github.io/amazing.html

75

76 of 349

Software Engineer 2

“Knowledge of modern HTML and CSS and the impact that high quality mark-up can have on performance, accessibility and discoverability.”

Person Specification – Essential

https://matthewdeeprose.github.io/amazing.html

76

77 of 349

Senior Software Engineer / Senior Software Engineer Team Lead 2

“Experience of modern HTML and CSS and the impact that high quality mark-up can have on performance, accessibility and discoverability.”

Person Specification – Essential

https://matthewdeeprose.github.io/amazing.html

77

78 of 349

Team Manager – Digital Learning

“Contribute, and encourage others to contribute, to communities of best practice (e.g. training, accessibility, user experience) in the development of policies and procedures which aim to showcase best practice across different delivery streams.”

Key accountabilities

https://matthewdeeprose.github.io/amazing.html

78

79 of 349

Multimedia Development Team Lead / Multimedia Developer

“Knowledge of accessibility issues relating to multimedia design.”

Person Specification - Desirable

https://matthewdeeprose.github.io/amazing.html

79

80 of 349

Expertise in digital accessibility will be required by companies who do business around the world.

https://matthewdeeprose.github.io/amazing.html

80

81 of 349

Expertise in digital accessibility will be required by companies who do business around the world. (1)

https://matthewdeeprose.github.io/amazing.html

81

Country	Name
Australia	World Wide Web Access: Disability Discrimination Act
Brazil	e-MAG, Modelo de Acessibilidade de Governo Eletrônico
Canada	Standard on Web Accessibility
Israel	Israeli standard 5568
Italy	Stanca Act
Japan	Japanese Industrial Standards X 8341-3
Norway	Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger

https://en.wikipedia.org/wiki/Web_accessibility#Web_accessibility_legislation

https://www.lflegal.com/2013/05/gaad-legal/

82 of 349

ETSI EN 301 549 V3.2.1 (2021-03) (1)

“The EN 301 549 standards are being applied outside the European Union as countries like Australia are adopting it to improve accessibility for their citizens and ease trade with the EU. This is an example of the Brussels effect”*

* https://en.wikipedia.org/wiki/EN_301_549

https://matthewdeeprose.github.io/amazing.html

82

83 of 349

Accessibility for Ontarians with Disabilities Act (AODA)

https://matthewdeeprose.github.io/amazing.html

83

Websites and web content including mobile apps (web-based applications) must comply.

Larger entities must establish and maintain an accessibility policy and plan and make it publicly available on their website.

Accessibility training must be provided to employees, volunteers, and those who provide goods and services on behalf of the organization.

84 of 349

European Accessibility Act

https://matthewdeeprose.github.io/amazing.html

84

Covers products and services that have been identified as being most important for persons with disabilities while being most likely to have diverging accessibility requirements across EU countries.

Computers and operating systems
ATMs, ticketing and check-in machines
Smartphones
TV equipment related to digital television services
Telephony services and related equipment
Access to audio-visual media services such as television broadcast and related consumer equipment
Services related to air, bus, rail and waterborne passenger transport
Banking services
e-books
e-commerce

Directive (EU) 2019/882 �European Accessibility Act

85 of 349

An edge in the job market?

Less than 3 % of University tech programmes include accessibility. *

63% of tech companies cannot staff accessibility needs. **

93% say demand for accessibility skills will increase in the future **

https://matthewdeeprose.github.io/amazing.html

85

* Teach Access Institutions course list (coded), 2018

** Accessible Technology Skills Gap Report, PEAT, 2018.

86 of 349

What does the strategy say? 42)

We “empower people” by providing “the opportunity for both personal and professional development”

https://matthewdeeprose.github.io/amazing.html

86

87 of 349

What does the strategy say? (3)

We will:

“Put our people at the heart of our digital future and help the University use digital technologies to improve productivity and create a better student experience”

https://matthewdeeprose.github.io/amazing.html

87

88 of 349

What did SLT say? (3)

“…We are going to deliver amazing accessibility. Because it is the right thing to do”

Accessibility Situation Report: An intro and update.

Dave Key
18 December 2020
iSolutions All-staff meeting.

https://matthewdeeprose.github.io/amazing.html

88

89 of 349

Shifting left through the process (1)4

https://matthewdeeprose.github.io/amazing.html

89

Requirements

Design

Build

Test

Release

Browser based test tools.
Checklists / checking sheet.
Command line tools.
CI tools.
Automated tests with Selenium etc.
Gherkin tests.

Shift left

90 of 349

What recommendations are there?

https://matthewdeeprose.github.io/amazing.html

90

The Web Content Accessibility Guidelines provide guidelines, explanations, and example techniques that pass the test.

91 of 349

Levels of conformance: �A and AA

https://matthewdeeprose.github.io/amazing.html

91

A

Minimum level of conformance.

AA

More accessible / Recommended.

AAA

Legal requirement

92 of 349

Levels of conformance: �AAA

https://matthewdeeprose.github.io/amazing.html

92

A

Minimum level of conformance.

AA

More accessible / Recommended.

AAA

Even more accessible / Enhanced.

Legal requirement

“Amazing accessibility?”

93 of 349

Accessibility guidelines have four high-level principles.

https://matthewdeeprose.github.io/amazing.html

93

Perceivable

Cater to our senses.

Operable

We can use the site.

Understandable

Readable and predictable.

Robust

Compatible across devices - even those to come in the future.

94 of 349

Example: Success Criterion 1.4.10 Reflow

(Level AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

Vertical scrolling content at a width equivalent to 320 CSS pixels;
Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

https://matthewdeeprose.github.io/amazing.html

94

95 of 349

Example support resources

“Understanding” page

“How to meet” guide

Sufficient Techniques
Advisory Techniques
Failures

https://matthewdeeprose.github.io/amazing.html

95

96 of 349

Example ‘sufficient techniques’ for reflow

https://matthewdeeprose.github.io/amazing.html

96

97 of 349

Best starting point

https://matthewdeeprose.github.io/amazing.html

97

Full, filterable WCAG criteria.

Includes all links to explanations, techniques, and failures.

https://www.w3.org/WAI/WCAG21/quickref

98 of 349

What are we aiming for?

https://matthewdeeprose.github.io/amazing.html

98

Principle	Level A	Level AA	Level AAA	Total
Perceivable	9	11	9	29
Operable	16	5	13	34
Understandable	8	6	7	21
Robust	2	1	0	3
Total	58		29	87

Baseline

Some are simple to attain.

Based on WCAG 2.2

99 of 349

Examples of achievable AAA criteria

1.3.6 Identify Purpose: The purpose of all components must be clear and machine-readable.

1.4.6 Contrast (Enhanced): The contrast ratio between text and background is at least 7:1.

1.4.9 Images of Text (No Exception): Don’t use images of text.

https://matthewdeeprose.github.io/amazing.html

99

100 of 349

Example criteria that may not be relevant

1.2.1 Audio-only and Video-only (Prerecorded): Provide an alternative to video-only and audio-only content.

1.2.2 Captions (Prerecorded): Provide captions for videos with audio.

1.2.3 Audio Description or Media Alternative (Prerecorded): Provide a second alternative for video with sound.

1.2.4 Captions (Live): Add captions to live videos.

1.2.5 Audio Description (Pre-Recorded): Provide audio description for pre- recorded videos.

1.2.6 Sign Language (Pre-Recorded): Provide sign language translations for pre-recorded videos.

https://matthewdeeprose.github.io/amazing.html

100

101 of 349

Testing web only?

EN 301 549 has rules for web, non-web document, and software (used for mobile app testing)

9.1.1.1 Non-text content

Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text content.

10.1.1.1 Non-text content

Where ICT is a non-web document, it shall satisfy the WCAG 2.1 Success Criterion 1.1.1 Non-text Content.

11.1.1.1.1 Non-text content (open functionality)

Where ICT is non-web software that provides a user interface and that supports access to assistive technologies for screen reading, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text Content.

https://matthewdeeprose.github.io/amazing.html

101

102 of 349

Example Guidelines we should aim for outside of WCAG?

Avoid:

Centred text that runs over one line.
Italics, all-caps, underlines for non-links.

Ensure:

Modals can be exited with Escape.

https://matthewdeeprose.github.io/amazing.html

102

103 of 349

Case study: what does a professional accessibility audit look like?

https://matthewdeeprose.github.io/amazing.html

103

104 of 349

Case study: what does a professional accessibility audit look like? 2

Overview of Wordpress Gutenberg editor by Tenon.io

A 34-page Executive Summary
Tenon’s testing plan, which groups features of the editor into testing components
A 329-page long-form technical report describing the logged issues in detail
A summary document describing Tenon’s usability testing
A CSV file containing the issues logged during the technical audit

https://matthewdeeprose.github.io/amazing.html

104

105 of 349

Involving users with impairments

Tenon performed a usability study using 9 participants:

3 participants were blind.
2 participants were blind with motor impairments
1 participant had cognitive impairments
2 participants had mobility impairments
1 participant was visually impaired

Each participant was asked to perform 3 tasks:

Create new content
Edit content
Amend post options

https://matthewdeeprose.github.io/amazing.html

105

106 of 349

GUT-99 - Keyboard focus order doesn't match visual order at high browser zoom

Severity: Medium

Affected Populations: Low‑Vision, Motor Impaired, Cognitively Impaired

Platform(s): All/ Universal

Components affected: Block Editing, Block Options

Relevant standards

1.4.10 Reflow (Level AA)
2.1.1 Keyboard (Level A)
2.4.3 Focus Order (Level A)

“When users are zoomed‑in up to 400%, content is re‑arranged such that the focus order differs from the visual order, and focus is able to move to items which are covered by other content.”

https://matthewdeeprose.github.io/amazing.html

106

107 of 349

GUT-99 - Keyboard focus order doesn't match visual order at high browser zoom (1)

Severity: Medium

Affected Populations: Low‑Vision, Motor Impaired, Cognitively Impaired

Platform(s): All/ Universal

Components affected: Block Editing, Block Options

Relevant standards

1.4.10 Reflow (Level AA)
2.1.1 Keyboard (Level A)
2.4.3 Focus Order (Level A)

“When users are zoomed‑in up to 400%, content is re‑arranged such that the focus order differs from the visual order, and focus is able to move to items which are covered by other content.”

https://matthewdeeprose.github.io/amazing.html

107

108 of 349

GUT-99 - Keyboard focus order doesn't match visual order at high browser zoom (2)

Severity: Medium

Affected Populations: Low‑Vision, Motor Impaired, Cognitively Impaired

Platform(s): All/ Universal

Components affected: Block Editing, Block Options

Relevant standards

1.4.10 Reflow (Level AA)
2.1.1 Keyboard (Level A)
2.4.3 Focus Order (Level A)

“When users are zoomed‑in up to 400%, content is re‑arranged such that the focus order differs from the visual order, and focus is able to move to items which are covered by other content.”

https://matthewdeeprose.github.io/amazing.html

108

109 of 349

GUT-99 - Keyboard focus order doesn't match visual order at high browser zoom (3)

Severity: Medium

Affected Populations: Low‑Vision, Motor Impaired, Cognitively Impaired

Platform(s): All/ Universal

Components affected: Block Editing, Block Options

Relevant standards

1.4.10 Reflow (Level AA)
2.1.1 Keyboard (Level A)
2.4.3 Focus Order (Level A)

“When users are zoomed‑in up to 400%, content is re‑arranged such that the focus order differs from the visual order, and focus is able to move to items which are covered by other content.”

https://matthewdeeprose.github.io/amazing.html

109

110 of 349

GUT-99 - Keyboard focus order doesn't match visual order at high browser zoom (14

Severity: Medium

Affected Populations: Low‑Vision, Motor Impaired, Cognitively Impaired

Platform(s): All/ Universal

Components affected: Block Editing, Block Options

Relevant standards

1.4.10 Reflow (Level AA)
2.1.1 Keyboard (Level A)
2.4.3 Focus Order (Level A)

“When users are zoomed‑in up to 400%, content is re‑arranged such that the focus order differs from the visual order, and focus is able to move to items which are covered by other content.”

https://matthewdeeprose.github.io/amazing.html

110

111 of 349

What does CDDO do when checking compliance?

A Freedom of Information (FOI) request* resulted in CDDO sharing a document that includes their testing procedure.

* https://www.whatdotheyknow.com/request/CDDO_accessibility_monitoring#incoming-1597882

The pages are tested using automated tools (currently axe).

Errors found are correlated and checked manually.

Perform a keyboard, tab through and zoom check.

Tests are completed using a Google Chrome browser on Mac OSX.

https://matthewdeeprose.github.io/amazing.html

111

112 of 349

What does CDDO do when checking compliance? (1)

A Freedom of Information (FOI) request* resulted in CDDO sharing a document that includes their testing procedure.

* https://www.whatdotheyknow.com/request/CDDO_accessibility_monitoring#incoming-1597882

If a simplified test finds major accessibility issues with a site (meaning a user group is not able to use the site or service), the site is likely to have a detailed audit.

Detailed audits will test against the full range of WCAG 2.1 success criteria up to level AA. Assistive technology will be used to check compliance as well as the automated and manual methods used in simplified testing.

https://matthewdeeprose.github.io/amazing.html

112

113 of 349

CDDO 2

How do automated accessibility checkers compare?

Deep dive comparison

Example inaccessible web page.

https://matthewdeeprose.github.io/amazing.html

113

114 of 349

Types of test

https://matthewdeeprose.github.io/amazing.html

114

Automated

Manual

Guided

115 of 349

Accessibility Testing Coverage: Automation and Intelligent Guided Testing

Glenda Sims, Director, Accessibility Services - Deque Systems

Reviews three years of audit data to show the actual accessibility coverage percentages from various technologies.

https://matthewdeeprose.github.io/amazing.html

115

https://www.youtube.com/watch?v=7sK_5zKlqP8

116 of 349

How effective is automated accessibility testing?

https://matthewdeeprose.github.io/amazing.html

116

117 of 349

Automated testing possibilities

https://matthewdeeprose.github.io/amazing.html

117

Browser addon

Command line

Continuous integration

118 of 349

Browser plugins

https://matthewdeeprose.github.io/amazing.html

118

The full slide deck has details and advantages and disadvantages of each, along with links and further information.

119 of 349

Lighthouse

Built into Chrome
Accessible from within Dev Tools.
Uses axecore.

https://matthewdeeprose.github.io/amazing.html

119

120 of 349

Lighthouse 2

https://matthewdeeprose.github.io/amazing.html

120

121 of 349

Lighthouse 3

https://matthewdeeprose.github.io/amazing.html

121

https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/

122 of 349

Lighthouse pros and cons

Pros

Built into Chrome, so everyone has access.
Many other features like performance.
Most known tool.

Cons

Some missing features offered by others, e.g. check tab management or guided tests.

https://matthewdeeprose.github.io/amazing.html

122

123 of 349

Wave

https://wave.webaim.org/

Produced by WebAIM
Available for Firefox, Chrome as browser extensions or you can use it from the WAVE website as a online testing tool.

https://matthewdeeprose.github.io/amazing.html

123

124 of 349

Wave (1)

https://matthewdeeprose.github.io/amazing.html

124

125 of 349

Wave errors

https://matthewdeeprose.github.io/amazing.html

125

126 of 349

Explanation of errors

https://matthewdeeprose.github.io/amazing.html

126

127 of 349

Wave Structure

https://matthewdeeprose.github.io/amazing.html

127

128 of 349

Wave contrast checker

https://matthewdeeprose.github.io/amazing.html

128

129 of 349

Wave: pros and cons

Pros

Tests for possible headings that are missing heading tags.
Good explanations.
Not only errors but helps understand structure and landmarks.

Cons

Interface can be overly complex.
Other extensions provide more functionality such as guided tests.

https://matthewdeeprose.github.io/amazing.html

129

130 of 349

Arc Toolkit

https://www.tpgi.com/arc-platform/arc-toolkit/

Created by the Paciello Group
Based on ARC Platform
Chrome Only
Accessed from DevTools

https://matthewdeeprose.github.io/amazing.html

130

131 of 349

Arc Toolkit Example 1

https://matthewdeeprose.github.io/amazing.html

131

132 of 349

Arc Toolkit Example 2

https://matthewdeeprose.github.io/amazing.html

132

133 of 349

Arc Pros and Cons

Pros

Breaks issues down by warning / critical etc
Easy to filter by type of issue
Handy buttons to send to validators (HTML/DOM/ARIA)

Cons

Only Chrome supported

https://matthewdeeprose.github.io/amazing.html

133

134 of 349

ASLint

https://aslint.org/

Created by eSSENTIAL Accessibility
Bookmarklet

https://matthewdeeprose.github.io/amazing.html

134

135 of 349

ASLint (2)

https://matthewdeeprose.github.io/amazing.html

135

136 of 349

ASLint (1)

Pros

Covers useful non-WCAG related tips (e.g. avoid all caps).
Can create reports.
Can simulate some visual impairments.

Cons

Slightly confusing interface.
Not as clear as others in marking where on the page accessibility issues have been found.

https://matthewdeeprose.github.io/amazing.html

136

137 of 349

IBM Equal Access Checker

https://www.ibm.com/able/toolkit/

Chrome, Firefox, Node.js

https://matthewdeeprose.github.io/amazing.html

137

138 of 349

IBM Equal Access Checker 1

https://matthewdeeprose.github.io/amazing.html

138

139 of 349

IBM Equal Access Checker 2

https://matthewdeeprose.github.io/amazing.html

139

140 of 349

IBM Equal Access Checker 3

https://matthewdeeprose.github.io/amazing.html

140

141 of 349

IBM Equal Access Checker 5

https://matthewdeeprose.github.io/amazing.html

141

142 of 349

IBM Equal Access Checker Pros and Cons

Pros:

NodeJS Module allows integrated accessibility testing within a CI pipeline such as Travis CI. Works with parsing engines such as Selenium, Puppeteer, Playwright, and Zombie.
Create HTML / Excel report.
No false positives (by saying “needs review).
Includes additional best-practice recommendations

Cons:

Some missing features offered by others, e.g. check tab management or guided tests.

https://matthewdeeprose.github.io/amazing.html

142

143 of 349

Axe

https://www.deque.com/axe/

Chrome Extension
Toolset also available asnode.js
Pro version and other auditing and dashboard tools available as commercial licence.

https://matthewdeeprose.github.io/amazing.html

143

144 of 349

Axe 1

https://matthewdeeprose.github.io/amazing.html

144

145 of 349

Axe 21

https://matthewdeeprose.github.io/amazing.html

145

146 of 349

Axe Pros and Cons

Pros

Clear interface
Most tests
Frequent updates
Excellent help and documentation
Breaks issues down to critical, moderate etc.
No false positives (by saying “needs review”)

Cons

Need pro version to get the most out of it.

Free trial for 14 days.

https://matthewdeeprose.github.io/amazing.html

146

147 of 349

Accessibility Insights

https://accessibilityinsights.io/

Chrome / Edge extension
Also version to test Android apps (via Android Device Bridge)
Windows version for testing windows programs.

https://matthewdeeprose.github.io/amazing.html

147

148 of 349

Accessibility Insights 1

https://matthewdeeprose.github.io/amazing.html

148

149 of 349

Accessibility Insights 2

https://matthewdeeprose.github.io/amazing.html

149

150 of 349

Accessibility Insights 3

https://matthewdeeprose.github.io/amazing.html

150

151 of 349

Accessibility Insights 4

https://matthewdeeprose.github.io/amazing.html

151

152 of 349

Accessibility Insights 5

https://matthewdeeprose.github.io/amazing.html

152

153 of 349

Accessibility Insights 6

https://matthewdeeprose.github.io/amazing.html

153

154 of 349

Accessibility Insights 7

https://matthewdeeprose.github.io/amazing.html

154

155 of 349

Command line tools

https://matthewdeeprose.github.io/amazing.html

155

Mainly use node.js and NPM.

Axe and Pa11y are most popular.

156 of 349

Axe 2

https://matthewdeeprose.github.io/amazing.html

156

157 of 349

Pa11y

https://matthewdeeprose.github.io/amazing.html

157

158 of 349

Command line tools resources

https://matthewdeeprose.github.io/amazing.html

158

159 of 349

Continuous integration tools

https://matthewdeeprose.github.io/amazing.html

159

160 of 349

Continuous integration resources

https://matthewdeeprose.github.io/amazing.html

160

161 of 349

Automated Accessibility Testing in JavaScript Frameworks

Mark Steadman, Developer Consultant at Deque Systems

Demonstrates automated accessibility testing of JS frameworks in terms of component functional test using integration, end to end or critical flow techniques.

https://matthewdeeprose.github.io/amazing.html

161

https://www.youtube.com/watch?v=CqxfrrMwhaY

162 of 349

Practice: Leverage an Accessibility Automation Library

Goal:

Save time during development by eliminating all of the common accessibility defects that can be found through generic automation before the code makes it into the code base.

https://matthewdeeprose.github.io/amazing.html

162

163 of 349

Practice: Leverage an Accessibility Automation Library (1)

Practice description:

Require developers to test all changed or new user interface states prior to sub-mitting code to the repository.
Integrate the execution of these tests into the build process on the continuous integration server, and include checks in your source code repository that do not allow changes to be merged if the tests fail.

https://matthewdeeprose.github.io/amazing.html

163

164 of 349

Practice: Automate Device and Assistive Technology Testing

Goal:

To ensure that implementations work with the set of assistive technologies required to meet the “accessibility supported” WCAG 2 requirement, while also leveraging automation for regression testing.

This eliminates costly manual regression testing and allows faster, less expensive iterations that result in high quality, accessible code.

https://matthewdeeprose.github.io/amazing.html

164

165 of 349

Practice: Automate Device and Assistive Technology Testing (1)

Practice description:

During development, developers write specific tests to validate the conditions required to communicate name, role, value, and state to the assistive technologies, and ensure that these are correctly interpreted by the assistive technologies by performing tests using a representative set of assistive technologies, including at least one screen reader and a keyboard without a screen reader.

https://matthewdeeprose.github.io/amazing.html

165

166 of 349

What automated tests won’t find

.ext-webkit *:focus {

outline: none !important;

}

$(function() {

$('img:not([alt])').attr('alt','');

});

https://matthewdeeprose.github.io/amazing.html

166

<a href="PGR_Induction_StartofYear_2021.pptx">Click Here</a>

2.4.7: Focus Visible

2.4.4: Link Purpose (In Context)

1.1.1: Non-text Content

2.4.3: Focus Order

167 of 349

Practice: Automate Device and Assistive Technology Testing (2)

Of particular importance are tests for the alternative device interactions. A good example of this is the JavaScript handlers that are required to implement custom-component keyboard interactions. The tests should be written to include assertions on what happens as the user “interacts” with the UI. For example, if clicking a button should open a dialog and set focus into that dialog, then add assertions to test that. Write tests that make assertions on the ARIA attribute and other state changes that should occur as a user “interacts” with the UI. These state changes should have corresponding changes to attributes and/or off-screen text that allow assistive technologies to expose the changed state, value, or name to users of assistive technologies. Write tests that assert the expectations with respect to the order in which interactive components will be focused using TAB key navigation (Web) and write tests to assert the order in which content will be read by the user (Web and native mobile).

https://matthewdeeprose.github.io/amazing.html

167

168 of 349

Practice: Automate Device and Assistive Technology Testing (3)

EXAMPLE 1: One of the components of accessibility testing which requires humans is the validation that the meaning conveyed by the visual user interface corresponds with the meaning conveyed through other senses, like voice. A simple example of this is validating that the alternative text of an image matches the image visuals. Websites often contain standard symbols and logos that appear in different locations. Simple assertions can be written to validate that the alternative texts for these graphics match the resource location. Doing this will ensure that if either the resource locator or the text changes, the test will alert the developer to check whether the text is still relevant and update the test.

https://matthewdeeprose.github.io/amazing.html

168

169 of 349

Practice: Automate Device and Assistive Technology Testing (4)

EXAMPLE 2: The ARIA authoring guidelines provide a description of how widgets should behave when being used with different input devices. This includes keyboards. Much of this keyboard interaction can be tested in a fully automated fashion using keyboard event simulation.

When writing the code for a widget, developers are adding the appropriate markup and event handlers and writing assertions for these. At various points during this process, when testing with the mouse and/or touch, the developers should test the functionality using a screen reader and a keyboard to ensure that the state changes and other information are announced correctly and that the event handlers work correctly with a screen reader and without one. Changes are encoded into the tests. This functionality then only needs to be tested manually if the code changes, or the supported set of assistive technologies changes.

https://matthewdeeprose.github.io/amazing.html

169

170 of 349

Simple tests you can do now

https://matthewdeeprose.github.io/amazing.html

170

171 of 349

What will you test?

Representative pages from every kind of template on the site
Coverage of all components used across the site
An optional percentage of extra pages to test as a sanity check (e.g. pick pages that are popular according to analytics testing reports)
A list of “Positive / Negative Scenarios” to test (e.g. successful module choice, module choice with errors, etc.)

For each of the pages chosen:

Use an automated tool to highlight issues that can be caught by a machine.
Perform the manual tests.

For each of the “Positive / Negative Scenarios” provided:

Attempt to go through the flows with just your keyboard.
Then go through the flows with your keyboard and a screen reader. Really listen to ensure that users who are not sighted are being given enough context to understand the experience.

https://matthewdeeprose.github.io/amazing.html

171

https://lsnrae.medium.com/six-things-you-need-to-audit-your-site-for-accessibility-db6db13ad8bf

172 of 349

1. Run automated tests using a browser plugin or command line tool.

https://matthewdeeprose.github.io/amazing.html

172

Verify failures

Assess priority

Report to development team or vendor for assessment.

173 of 349

2. Validate pages

Use https://validator.w3.org

Covers 4.1.1 Parsing.

https://matthewdeeprose.github.io/amazing.html

173

174 of 349

3. Keyboard test

Test the website is operable using a keyboard. Ensure focus indicator has good contrast.

Refer to CoP session on keyboard navigation and accompanying slide deck.

This should cover:

2.1.1 Keyboard
2.1.2 No Keyboard Trap
2.1.3 Keyboard (No Exception)
2.1.4 Character Key Shortcuts
2.4.1 Bypass Blocks
2.4.11 Focus Appearance (Minimum)
2.4.12 Focus Appearance (Enhanced)
2.4.3 Focus Order
2.4.7 Focus Visible

https://matthewdeeprose.github.io/amazing.html

174

175 of 349

Keyboard test (2)

Navigate website using tab, enter/return, cursor keys

https://matthewdeeprose.github.io/amazing.html

175

Interaction	Keystrokes
Navigate to most elements	Tab Shift + Tab - navigate backward
Link	Enter (PC) / Return (Mac)
Button	Enter (PC) / Return (Mac) or Spacebar
Checkbox	Spacebar - check/uncheck a checkbox
Radio buttons	↑ / ↓ or ← / → = select an option. Tab - move to the next element.

https://webaim.org/techniques/keyboard/

Deque Systems

UX Collective

If you use a Mac and/or Safari, please make sure your settings allow for tabbing to interactive elements.

176 of 349

4. Test for reflow, text-resize and text-spacing

Set the browser window to 1280px wide (web developer helps.)
Zoom in to 400%.
Check content & functionality is available, and no horizontal scrolling.
Check text is at least 200% bigger.
Turn on text-sizing (e.g. with a bookmarklet).
Un-zoom through each media query, looking for overlaps / missing content.

The is covers

1.4.4 Resize text
1.4.10 Reflow
1.4.12 Text Spacing

https://matthewdeeprose.github.io/amazing.html

176

177 of 349

Text spacing?

Avoid overlaps, and horizontal / vertical cut offs.

Understanding Success Criterion 1.4.12: Text Spacing

https://matthewdeeprose.github.io/amazing.html

177

178 of 349

Overlaps and cut offs? 2

Avoid overlaps, and horizontal / vertical cut offs.

Understanding Success Criterion 1.4.12: Text Spacing

https://matthewdeeprose.github.io/amazing.html

178

iSolutions real world example: only happens using keyboard navigation.

179 of 349

5. Test in grey scale

Helps to test if colour has been used as the sole way to convey meaning.

Covers:

1.4.1: Use of Colour

https://matthewdeeprose.github.io/amazing.html

179

180 of 349

Example of why you should not use colour as the only means to convey meaning.

Ready to submit your final assignment?

https://matthewdeeprose.github.io/amazing.html

180

Example using simulated Deuteranopia rendering in Google Chrome

181 of 349

Is it understandable in black and white? (2)

https://matthewdeeprose.github.io/amazing.html

181

182 of 349

Accessibility Insights 51

https://matthewdeeprose.github.io/amazing.html

182

183 of 349

Example where colour is not the only means to convey meaning.

Ready to submit your final assignment?

https://matthewdeeprose.github.io/amazing.html

183

No

Yes

Example using simulated Deuteranopia rendering in Google Chrome

184 of 349

Examples using pie charts

https://matthewdeeprose.github.io/amazing.html

184

Insufficient contrast between colours.

Use of labels means colour is not the only way to understand the graph.

185 of 349

Examples using line graphs

https://matthewdeeprose.github.io/amazing.html

185

Insufficient contrast between colours.

Use of markers / dotted lines means colour is not the only way to understand the graph.

186 of 349

Is it understandable in black and white?

https://matthewdeeprose.github.io/amazing.html

186

187 of 349

6. Test with CSS disabled and images turned off.

Use web developer extension to turn off CSS and images.

Confirm that content is still in sequence, usable, and understandable.

Covers:

1.1.1 Non-text Content
1.3.2 Meaningful Sequence
1.4.5 Images of Text

https://matthewdeeprose.github.io/amazing.html

187

188 of 349

7. Test in High Contrast Mode

https://matthewdeeprose.github.io/amazing.html

188

Is all necessary content displayed?
Can you read all links, buttons, and controls?
Is important information communicated through images still apparent?
Are forms still understandable?

189 of 349

7. Test in High Contrast Mode (2)

https://matthewdeeprose.github.io/amazing.html

189

190 of 349

8. Test with screen reader

JAWS for Windows (£)
NVDA for Windows
Narrator for Windows
VoiceOver for Apple devices
Talkback for Android devices

“The best way to test things for screen reader usability is to hire someone who is blind who uses screen reader software and get them to access the content whilst you watch over their shoulder, you can learn an awful lot about how people access the content, and how difficult it is”

Dave Foord

A6 Training and Consultancy Ltd

https://matthewdeeprose.github.io/amazing.html

190

191 of 349

Nothing about us without us!

“The nothing-about-us-without-us principle expresses that persons with disabilities know what is best for them and their community, and that persons with disabilities must be valued as integral and essential contributors to every sector, industry and community worldwide.”

Dr Elizabeth Lockwood

CBM representative to the United Nations�https://www.futurelearn.com/info/courses/global-disability/0/steps/37575

https://matthewdeeprose.github.io/amazing.html

191

192 of 349

Screen Reader Resources

How screen reader usage differs from keyboard usage
3 Quick Tasks to Get Familiar with Screen Readers (VoiceOver on Mac)
Articulate CoP: Intro to screen readers

https://matthewdeeprose.github.io/amazing.html

192

193 of 349

9. Check colours used have sufficient contrast 0

https://matthewdeeprose.github.io/amazing.html

193

194 of 349

Revisiting hard to read contrast examples

https://matthewdeeprose.github.io/amazing.html

194

Hard to read

1.19:1

Hard to read

1.64:1

Hard to read

1.84:1

Hard to read?

2.71:1

Hard to read?

2.96:1

Hard to read?

4:1

Easy to read

7.58:1

Easy to read

15.27:1

Easy to read

21:1

195 of 349

9. Check colours used have sufficient contrast

Use WhoCanUse to check the contrast of colours used.
Are icons/non-text graphics above 3:1.
Are focus indicators ideally 4.5:1 or higher and double area of 1 CSS pixel perimeter?
Is text at least 4.5:1 or above colour compared with background?
If link text is not underlined is the contrast difference of link text at least 3:1 or higher compared with normal text while being 4.5:1 or higher with background?

https://matthewdeeprose.github.io/amazing.html

195

1.99:1FAIL

2.15:1

FAIL

2.49:1FAIL

4.19:1

PASS

1.8:1

FAIL

4.84:1

PASS

3.34:1PASS

3.23:1PASS

196 of 349

The ratios to remember

https://matthewdeeprose.github.io/amazing.html

196

3:1

4.5:1

7:1

Minimum for Graphical Objects / UI

AA

Minimum for Text

AAA

Enhanced level for Text

(not to scale)

1.4.11 Non-text Contrast (Level AA)

1.4.3 Contrast (Minimum) (Level AA)

1.4.6 Contrast (Enhanced) (Level AAA):

2.4.11 Focus Appearance (Minimum)

2.4.12 Focus Appearance (Enhanced)

197 of 349

Helpful tools

https://matthewdeeprose.github.io/amazing.html

197

https://buttonbuddy.dev/

https://webaim.org/resources/linkcontrastchecker/

198 of 349

Colour Matrix

https://matthewdeeprose.github.io/amazing.html

198

https://elearn.southampton.ac.uk/accessibility/colours

199 of 349

How to deal with text over images?

https://matthewdeeprose.github.io/amazing.html

199

Mitesh7587 / Wikimedia / CC BY-SA 4.0

200 of 349

Text with a background image

https://matthewdeeprose.github.io/amazing.html

200

This website allows you to upload your image and set the text colour you wish to use.

It calculates the optimum overlay to place over the image for the text to have sufficient contrast.

The overlay can then be created in Photoshop, PowerPoint, or using CSS etc.

https://css-tricks.com/nailing-the-perfect-contrast-between-light-text-and-a-background-image/

201 of 349

10. Turn off animations in the OS

Enable “no animations” or “reduce motion” within the OS.

Verify that animations are disabled, and videos do not auto start.

2.3.3 Animation from Interactions

https://matthewdeeprose.github.io/amazing.html

201

202 of 349

11. Use further quick tools 1

Use headingsMap browser extension to verify heading structure to test:

2.4.6: Headings and Labels

https://matthewdeeprose.github.io/amazing.html

202

203 of 349

11. Use further quick tools 2

Use 44x44 Pixel Cursor Bookmarklet to test:

2.5.5: Target Size
2.5.8: Target size (minimum)

https://matthewdeeprose.github.io/amazing.html

203

204 of 349

11. Use further quick tools 3

https://matthewdeeprose.github.io/amazing.html

204

https://chrome.google.com/webstore/detail/web-disability-simulator/olioanlbgbpmdlgjnnampnnlohigkjla

205 of 349

So far so good?

Those practical tests should cover at least 23 success criteria.
When screen reader testing is at a high level more will be covered.
But what about the rest?

https://matthewdeeprose.github.io/amazing.html

205

206 of 349

Manual Testing

https://matthewdeeprose.github.io/amazing.html

206

Only 20% to 50% of all accessibility issues can automatically be detected.

Manual testing is always required.

Comment at end of Axe automated test results.

207 of 349

Testing spreadsheet

https://matthewdeeprose.github.io/amazing.html

207

https://go.soton.ac.uk/acctesting

208 of 349

In the full slide deck…

I’ve added reviews and descriptions of a number of easy to follow checklists. There’s more in the handout.

https://matthewdeeprose.github.io/amazing.html

208

209 of 349

WAI Easy Checks

Simple checks with instructions and examples.

Page title
Image text alternatives ("alt text") (pictures, illustrations, charts, etc.)
Text:

Interaction:

Keyboard access and visual focus
Forms, labels, and errors (including Search fields)

General:

Also has an excellent “before / after” comparison of accessibility issues.

https://matthewdeeprose.github.io/amazing.html

209

https://www.w3.org/WAI/test-evaluate/preliminary/

210 of 349

Lexdis “quick checks”

Attempts to summarise a range of guidance from WCAG, Government Digital Services, Web2Access so that organisations can begin to understand what barriers disabled users may experience when using their digital estate

Not intended to replace an accessibility audit and these tests on their own are not sufficient to evaluate whether a website complies with web accessibility standards.

https://matthewdeeprose.github.io/amazing.html

210

https://www.lexdis.org.uk/digital-accessibility/testing/quick-accessibility-checks/

211 of 349

Lexdis “Introduction to auditing”

Provides basic overview of process.
Explains tools to use.
Describes how to determine scope of an audit.

https://matthewdeeprose.github.io/amazing.html

211

https://www.lexdis.org.uk/digital-accessibility/testing/introduction-to-auditing/

212 of 349

Lexdis Manual Auditing guide

“a more natural and efficient way of covering the audit checks than using Accessibility Insights”

“assumes a good existing knowledge of the WCAG 2.1 criterion and how their techniques can be applied on a website.”

https://matthewdeeprose.github.io/amazing.html

212

https://www.lexdis.org.uk/digital-accessibility/testing/performing-a-manual-audit/

213 of 349

NHS Accessibility audit checklist

https://matthewdeeprose.github.io/amazing.html

213

214 of 349

NHS Accessibility audit checklist (2)

https://matthewdeeprose.github.io/amazing.html

214

Does not cover all WCAG criteria, but links well to “sufficient techniques”.

Practical and achievable.

215 of 349

Alison Walden’s guide

1.3.1 (A) Info and Relationships:

Validate that changes in text presentation are not used to convey information without using appropriate mark-up (e.g. text styled as a heading but not marked up with heading tags).�

Tool: Web developer toolbar�

Method: Outline > Outline Headings (you can also check off “Show Element Tag Names” to see the heading level)�

— Validate that there is no heading on the page that has the appearance of a heading but no heading tag.

https://matthewdeeprose.github.io/amazing.html

215

Example extract

https://lsnrae.medium.com/six-things-you-need-to-audit-your-site-for-accessibility-db6db13ad8bf

Clear and repeatable tests.

Designed more for CMS page maintainers

216 of 349

A11y Project Checklist

https://matthewdeeprose.github.io/amazing.html

216

https://www.a11yproject.com/checklist

217 of 349

A11y Project Checklist (2)

Tick-able (but session not kept)
Easy to follow
Linked to WCAG
Sharable links

https://matthewdeeprose.github.io/amazing.html

217

https://www.a11yproject.com/checklist

218 of 349

CDDO: basic checks

Simple and readable guide.

Anyone can follow this guide.

https://matthewdeeprose.github.io/amazing.html

218

https://www.gov.uk/government/publications/doing-a-basic-accessibility-check-if-you-cant-do-a-detailed-one/doing-a-basic-accessibility-check-if-you-cant-do-a-detailed-one

219 of 349

WCAG success criteria can be complex

https://matthewdeeprose.github.io/amazing.html

219

220 of 349

Agile Accessibility Requirements at Scale

Ben Allen

PNC / Digital Product Manager, Senior Manager

Demonstrates how building a gherkin component acceptance criteria library helped create rapid accessibility tests.

https://matthewdeeprose.github.io/amazing.html

220

https://www.youtube.com/watch?v=j8ss3DLUmfA

221 of 349

Gherkin

Gherkin is a business readable language which helps you to describe business behaviour without going into details of implementation.

Given
When
Then
And, But

https://matthewdeeprose.github.io/amazing.html

221

222 of 349

Examples

Scenario: A sighted keyboard-only user with a motor disability can operate an interface by only using a keyboard.*

Given I am a sighted keyboard-only user with a user disability
When I navigate the page with the TAB key forwards and backwards
Then all interactive objects receive focus
And all interactive objects are operable
And all interactive objects receive focus in a logical order
And I can always visually tell what element has focus

Scenario: A screen reader user is aware of textbox behaviour and can operate a text box.*

Given I am a screen reader user
And the page contains text input
When I navigate to “{text}”
Then I hear its label with any helper text, error text, and warning text
And I hear the edit role (or similar)
And I can hear its current value (if it has one)

https://matthewdeeprose.github.io/amazing.html

222

*Taken from Ben Allen presentation from PNC.com

223 of 349

Examples 2

Scenario: A screen reader user can understand a select input*

Given I am a screen reader user
And the page contains a select input
When I navigate to the select input with the label of “{text}”
And I interact with it
Then I hear a label for the select with any helper text, error text, and warning text
And I hear the role of the select (can be announced as “combo box” or “popup button” depending on screen reader)
And I hear which option is currently selected
And I hear the name of each option

Scenario: As a developer of test analyst, I can confirm that no automated accessibility issues can be found, so that I know someone with a disability will be able to use the site.*

Given I am a developer or test analyst*
When I run AxE / Lighthouse / MS Accessibility Insights
Then no violations are returned
And no issues marked as “needs review” fail

https://matthewdeeprose.github.io/amazing.html

223

*Taken from Ben Allen presentation from PNC.com

224 of 349

Examples 3

Scenario: A sighted keyboard-only user with a motor disability can bypass repeated content in the navigation element of the page**

Given I am on any page of the application
When I select the ‘Skip to content’ link, which is the first tab stop of any page
Then the main content has keyboard focus
And I can always visually tell the first interactive element of the main content has focus
And all following interactive objects receive focus in a logical order

Scenario: A sighted hearing impaired user can view captions for a video located on a page**

Given I am on a page that contains a video
And I can navigate to the video using keyboard or mouse controls
When I select the ‘play’ button using keyboard or mouse
And I turn on captions (more detail required here depending on nature of player)
Then the correct closed captions display throughout the video
And I can disable the captions using a consistent mechanism using either keyboard or mouse

https://matthewdeeprose.github.io/amazing.html

224

** Adapted from blog post by Gemma Pitman of Hassel inclusion

225 of 349

Gherkin Library

https://matthewdeeprose.github.io/amazing.html

225

226 of 349

Guided Tests

https://matthewdeeprose.github.io/amazing.html

226

227 of 349

Axe Pro Guided Tests

https://matthewdeeprose.github.io/amazing.html

227

228 of 349

Accessibility Insights A

https://accessibilityinsights.io/

Has a very useful guided assessment tool.
Covers all WCAG 2.1 A and AA

https://matthewdeeprose.github.io/amazing.html

228

Coverage of:

WCAG 1.1.1

WCAG 1.2.1

WCAG 1.2.2

WCAG 1.2.3

WCAG 1.2.4

WCAG 1.2.5

WCAG 1.3.1

WCAG 1.3.2

WCAG 1.3.3

WCAG 1.3.4

WCAG 1.3.5

WCAG 1.4.1

WCAG 1.4.10

WCAG 1.4.11

WCAG 1.4.12

WCAG 1.4.13

WCAG 1.4.2

WCAG 1.4.3

WCAG 1.4.4

WCAG 1.4.5

WCAG 2.1.1

WCAG 2.1.2

WCAG 2.1.4

WCAG 2.2.1

WCAG 2.2.2

WCAG 2.3.1

WCAG 2.4.1

WCAG 2.4.2

WCAG 2.4.3

WCAG 2.4.4

WCAG 2.4.5

WCAG 2.4.6

WCAG 2.4.7

WCAG 2.5.1

WCAG 2.5.2

WCAG 2.5.3

WCAG 2.5.4

WCAG 3.1.1

WCAG 3.1.2

WCAG 3.2.1

WCAG 3.2.2

WCAG 3.2.3

WCAG 3.2.4

WCAG 3.3.1

WCAG 3.3.2

WCAG 3.3.3

WCAG 3.3.4

WCAG 4.1.1

WCAG 4.1.2

WCAG 4.1.3

229 of 349

Accessibility Insights 6 B

https://matthewdeeprose.github.io/amazing.html

229

230 of 349

Accessibility Insights C

https://accessibilityinsights.io/

Report can be exported to an HTML file.

https://matthewdeeprose.github.io/amazing.html

230

231 of 349

Accessibility Insights 4 D

https://accessibilityinsights.io/

https://matthewdeeprose.github.io/amazing.html

231

Probably most practical way to get started.

A full test of one page may take 30 mins to 1 hour depending on complexity.

232 of 349

Can I practice accessibility testing?

The “Inaccessible / accessible University” from University of Washington is a great resource for testing.

Accessible University

https://matthewdeeprose.github.io/amazing.html

232

233 of 349

What kind of details should we record when reporting accessibility issues?

Steps to repeat
Client details (OS, Browser, Screen Reader etc)
Component affected
Workflow or sequence affected.
WCAG violation
Priority

https://matthewdeeprose.github.io/amazing.html

233

234 of 349

Unblocking Backlog Jams with Multi Dimensional Audits

Dave Rupert, lead developer at Paravel

Shares strategies for categorising and organising accessibility problems.
Shares how to improve the accessibility audit hand-off and development processes.

https://matthewdeeprose.github.io/amazing.html

234

https://www.youtube.com/watch?v=p5DuapED88Y

235 of 349

How to prioritise issues?

https://matthewdeeprose.github.io/amazing.html

235

236 of 349

Practice: Manage Accessibility Defects Systematically 1

Goal:

Implement an accessibility defect management policy that allows for the consistent prioritization of accessibility issues in ways that mirror the prioritization of other classes of defects
Produce / maintain an accurate accessibility statement with each release in an agile manner.

https://matthewdeeprose.github.io/amazing.html

236

237 of 349

Practice: Manage Accessibility Defects Systematically 2

Practice description:

There are two components to this practice:

Creating and implementing a way to evaluate the impact of an accessibility issue and assigning it a priority that matches the equivalent defect priority for other functional and non-functional defects; and
Maintaining a defect management system where every accessibility defect is identifiable.

https://matthewdeeprose.github.io/amazing.html

237

238 of 349

Practice: Manage Accessibility Defects Systematically 3

Not all accessibility defects are created equal:

a missing alternative text for an image can be a blocker for a blind user if that image is part of an image button required to complete the main business flow of a Web application,
or it could be a minor inconvenience if it is a social icon in the footer of the page. This should underpin the priority system assigned to any accessibility defect.

https://matthewdeeprose.github.io/amazing.html

238

239 of 349

Critical issues

https://matthewdeeprose.github.io/amazing.html

239

Priority	Criteria	Action
Critical	The issue affects at least one disability such that a critical business function cannot be used by a user with an affected disability. Think about the impact from this perspective: If all users could not use this functionality, would we consider that critical?	Stop deployment/release of affected software until the defect is remediated. If the defect is discovered in production, implement a hot fix immediately. If the hot fix cannot be implemented immediately, create an alternative channel for achieving the functionality and train Service Desk staff on how to direct users to the alternative channel.

240 of 349

Serious issues

https://matthewdeeprose.github.io/amazing.html

240

Priority	Criteria	Action
Serious	The issue affects at least one disability such that critical business functionality can only be used with an acceptable workaround, or the issue affects functionality that is not essential, but prevents at least one disability from being able to use this functionality.	Fix the defect in the very next deployment/release. Update accessibility statement with the workaround and train Service Desk staff on how to deal with the issue.

241 of 349

Moderate

https://matthewdeeprose.github.io/amazing.html

241

Priority	Criteria	Action
Moderate	The issue affects functionality that is not essential and has an acceptable workaround.	Update accessibility statement with the workaround. Train Service Desk staff on how to deal with the issue. Assign defect fix priority in a similar way to defects that affect general site usability.

242 of 349

Minor issues

https://matthewdeeprose.github.io/amazing.html

242

Priority	Criteria	Action
Minor	The issue affects functionality in a distracting way (e.g., duplicate accessible names, presentational elements that are not marked as presentational, or inconsistent use of markup).	Assign defect fix priority in a similar way to defects that affect brand, consistency of use, and look-and-feel.

243 of 349

Institutionalizing Accessibility at one of the World’s Top 10 Largest Auto Makers

Alison Walden, Senior Director of Technology and Accessibility Lead - Publicis Sapient

Worked with Fiat Chrysler Automobiles (FCA) for three years.

https://matthewdeeprose.github.io/amazing.html

243

https://www.youtube.com/watch?v=6ruvSrGTAuE

244 of 349

Defining levels of severity for accessibility issues

https://matthewdeeprose.github.io/amazing.html

244

Priority level (severity)	Definition
P1	“Critical” Barriers that stop someone from using a site or feature successfully or not at all. Example: Interactive element not accessible by keyboard.
P2	“Serious” Problem that slows someone down, or forces them into work-arounds. Example: Flyout menu cannot be closed with the keyboard so it covers important content after being opened.
P3	“Moderate” issues that make the experience less pleasant. Example: Where minor issues are pervasive , causing an issue consistently across a site or workflow.
P4	“Minor” issues that damage credibility but are unlikely to cause problems. Example: A few redundant alt attributes

245 of 349

Shifting left through the process (15

https://matthewdeeprose.github.io/amazing.html

245

Requirements

Design

Build

Test

Release

Linters and IDE plugins.
Framework extensions (e.g. Bootstrap accessibility plugin)
Git actions.

Shift left

246 of 349

Integrated development environment plugins

Identify possible accessibility issues whilst coding.

https://matthewdeeprose.github.io/amazing.html

246

247 of 349

Visual Studio Code

https://matthewdeeprose.github.io/amazing.html

247

248 of 349

Atom

https://matthewdeeprose.github.io/amazing.html

248

249 of 349

For Frameworks

React

Vue

Accessibility auditing for Vue.js 3

Angular

Proctractor / Angular Accessibility testing

Bootstrap

Ember

ember-a11y-testing

https://matthewdeeprose.github.io/amazing.html

249

250 of 349

Bootstrap

https://matthewdeeprose.github.io/amazing.html

250

3.98:1

FAIL

3.13:1FAIL

12.9:1 PASS

16.9:1 PASS

4.69:1PASS

4.53:1

FAIL

3.04:1FAIL

11.5:1 PASS

4.02:1

FAIL

251 of 349

Source Control

Axe Linter analyses changed or added code of pull requests, reports issues

https://matthewdeeprose.github.io/amazing.html

251

252 of 349

Source Control (2)

Automatically requests changes to resolve common issues.

https://matthewdeeprose.github.io/amazing.html

252

253 of 349

Shifting left through the process (6)

https://matthewdeeprose.github.io/amazing.html

253

Requirements

Design

Build

Test

Release

Involve users (including with impairments) in co-design.
Accessible component library and atomic design elements.
Annotate wireframes with accessibility details.

Shift left

254 of 349

Auditing design systems for accessibility

Anna Cook, Senior Product Designer at Recurly

creating design systems with baked-in accessibility compliance

https://matthewdeeprose.github.io/amazing.html

254

https://www.youtube.com/watch?v=6PHTGHgCQig

255 of 349

Using concepts from “Atomic Design” by Brad Frost

https://matthewdeeprose.github.io/amazing.html

255

256 of 349

Design Tokens

https://matthewdeeprose.github.io/amazing.html

256

257 of 349

Example Atoms

https://matthewdeeprose.github.io/amazing.html

257

258 of 349

Example Molecule

https://matthewdeeprose.github.io/amazing.html

258

259 of 349

Example Organism

https://matthewdeeprose.github.io/amazing.html

259

260 of 349

Templates and pages

https://matthewdeeprose.github.io/amazing.html

260

Template

Page

261 of 349

Component Guides

https://matthewdeeprose.github.io/amazing.html

261

https://www.w3.org/TR/wai-aria-practices-1.2

262 of 349

Component Libraries

https://matthewdeeprose.github.io/amazing.html

262

https://inclusive-components.design/

https://www.digitala11y.com/accessible-ui-component-libraries-roundup/

263 of 349

OneWeb 2

The OneWeb Team audited all their components and patterns for accessibility and tested them with users.

https://matthewdeeprose.github.io/amazing.html

263

264 of 349

Benefits of using accessible, standard UI patterns and components

More efficient, and faster.

Accessibility work done already, but still requires testing.

https://matthewdeeprose.github.io/amazing.html

264

265 of 349

How designers forget to consider accessibility

Brandy Bora, Sr. Manager of Design, Verizon

Tactical, design-focused solutions to including accessibility within front-end design.

https://matthewdeeprose.github.io/amazing.html

265

https://www.youtube.com/watch?v=qqQeQdqsnAI

266 of 349

How Verizon defines what they mean by accessibility

Form elements

Keep the forms simple, direct, and required.

Forms must have a title and instructional text to orient the user.
Any placeholder text must meet contrast guidelines and be instructional.
All fields have labels.
All fields have specific, descriptive errors.
Screen level errors appear at the top and bottom of the screen or in persistent view.
All fields are required. Optional fields are rare and called out with an asterisk.

Experiences work for users with limited vision.

“We design text, buttons and navigational elements to the colour contrast ratio of 4.5:1 and use visual indicators with interactive elements.”

https://matthewdeeprose.github.io/amazing.html

266

Example component definition

Example brand guideline

267 of 349

Co-design

Involving users of all abilities can help to produce more accessible services.

“Our perspective is that the best way to assess accessibility is to include the end users and hear their perspectives”

Fable TechLabs

https://matthewdeeprose.github.io/amazing.html

267

268 of 349

OneWeb 5

The OneWeb Team has done some excellent work on involving users within the design process.

https://matthewdeeprose.github.io/amazing.html

268

269 of 349

Practice: Communicate Intent with Accessibility Design Annotation

GOAL: Communicate all of the necessary accessibility design intent to the team so that designs can be turned into accessible applications, and this accessibility can be tested and validated efficiently.

PRACTICE DESCRIPTION: Train all team members to expect user experience and user interface designers to provide them with all the following information for a new or modified user interface design:

The role of every element in the user interface, whether interactive or not. This includes communicating the role of regions of information and groups of controls. For example, if your design has a group of navigational controls at the top and some information in the footer, indicate where the main content begins and ends, then mark this up in a wireframe or design comp so that everyone knows what those regions are;
The states that every user interface element can take on and the text description of those states. For example, if your application has an order workflow with many steps, ensure that the states for the future steps, the current step, and the completed steps are identified and described;
All of the discrete values that the elements can take on and the text description of those values. For example, if a section of the user interface can be expanded and collapsed, describe these different states in text;
The name of every element, region, or group of controls in the user interface. For example, if your interface has a main section of content and then some supplemental content, identify the content regions and describe them in text;
A complete description of the interaction for each interactive element and its surrounding elements, including all inputs for all supported devices and how this affects the focus, the states, and the values of the interactive element and related elements;
The intended order in which elements should be encountered and read on the page (reading order/focus order); and
The minimum sizes of all interactive elements at all device or browser sizes.

https://matthewdeeprose.github.io/amazing.html

269

270 of 349

Practice: Communicate Intent with Accessibility Design Annotation 1

Goal: �Communicate all of the necessary accessibility design intent to the team so that designs can be turned into accessible applications, and this accessibility can be tested and validated efficiently.

https://matthewdeeprose.github.io/amazing.html

270

271 of 349

Practice: Communicate Intent with Accessibility Design Annotation 2

Practice Description:

Train all team members to expect user experience and user interface designers to provide them with all the following information for a new or modified user interface design:

https://matthewdeeprose.github.io/amazing.html

271

The role of every element in the user interface, whether interactive or not. This includes communicating the role of regions of information and groups of controls. For example, if your design has a group of navigational controls at the top and some information in the footer, indicate where the main content begins and ends, then mark this up in a wireframe or design comp so that everyone knows what those regions are;
The states that every user interface element can take on and the text description of those states. For example, if your application has an order workflow with many steps, ensure that the states for the future steps, the current step, and the completed steps are identified and described;
All of the discrete values that the elements can take on and the text description of those values. For example, if a section of the user interface can be expanded and collapsed, describe these different states in text;
The name of every element, region, or group of controls in the user interface. For example, if your interface has a main section of content and then some supplemental content, identify the content regions and describe them in text;
A complete description of the interaction for each interactive element and its surrounding elements, including all inputs for all supported devices and how this affects the focus, the states, and the values of the interactive element and related elements;
The intended order in which elements should be encountered and read on the page (reading order/focus order); and
The minimum sizes of all interactive elements at all device or browser sizes.

272 of 349

Communicating Intent with Accessibility Design Annotation

Interaction for the role=button

Keyboard SPACE or ENTER equals click
Disabled buttons cannot receive focus
Disabled buttons do not respond to a click/touch

https://matthewdeeprose.github.io/amazing.html

272

Source: Agile Accessibility Handbook

273 of 349

Communicating Intent with Accessibility Design Annotation (2)

Interaction for the entire component

When on first track: disable “previous track” button
When on last track: disable “next track” button and hide the “play” button
When not playing: display the “play” button and hide the “pause” button
After clicking “play,” place focus on the “pause” button
After clicking “pause,” place focus on the “play” button

https://matthewdeeprose.github.io/amazing.html

273

Source: Agile Accessibility Handbook

274 of 349

Practice: Create a User Interface Pattern Library 1

Goal: �Leverage accessible interaction designs, mark-up, and implementations across a large number of development teams while maintaining flexibility of implementation and look.

https://matthewdeeprose.github.io/amazing.html

274

275 of 349

Practice: Create a User Interface Pattern Library 2

Practice Description:

Making applications accessible consists of paying attention to four high-level aspects of user interface design and implementation.

The colour, font, iconography, and layout design choices that represent the roles, states, and values of the user interface elements across viewport sizes—the look;
The mark-up used to represent the names, roles, values, and states of the user interface elements—the mark-up;
The multi-input device interaction designs of the user interface components—the interaction; and
The implementation of the interactions and generation of the UI content—the implementation.

https://matthewdeeprose.github.io/amazing.html

275

276 of 349

How can we ensure accessibility is considered from the beginning?

https://matthewdeeprose.github.io/amazing.html

276

277 of 349

Shifting left through the proce8s

https://matthewdeeprose.github.io/amazing.html

277

Requirements

Design

Build

Test

Release

Include accessibility within project documentation.
TAG Non Functional Requirements.
Accessible procurement

Shift left

278 of 349

How can we add accessibility into projects? 1

https://matthewdeeprose.github.io/amazing.html

278

Add accessibility section to project brief, and business case documents.

Specify the production / updating of an accessibility statement as a deliverable.

Create a standard work-package for the creation of accessibility statements.

279 of 349

How can we add accessibility into projects? 2

https://matthewdeeprose.github.io/amazing.html

279

Add accessibility section to project brief, and business case documents.

Specify the production / updating of an accessibility statement as a deliverable.

Create a standard work-package for the creation of accessibility statements.

280 of 349

How can we add accessibility into projects? 5

https://matthewdeeprose.github.io/amazing.html

280

Add accessibility section to project brief, and business case documents.

Specify the production / updating of an accessibility statement as a deliverable.

Create a standard work-package for the creation of accessibility statements.

281 of 349

Why should we care? (2) It’s the law

https://matthewdeeprose.github.io/amazing.html

281

Maximise the potential of the University’s digital estate for all stakeholders by removing barriers.

It’s the law.

It saves money.

It’s the right thing to do.

Competitive advantage.

282 of 349

How does the law fit into this?

https://matthewdeeprose.github.io/amazing.html

282

283 of 349

It’s the law.

https://matthewdeeprose.github.io/amazing.html

283

Statutory Instrument 2018 No. 952

The Public Sector Bodies (Websites and Mobile Applications) No. 2 Accessibility Regulations 2018

Equality Act 2010

Does not apply in Northern Ireland

Disability Discrimination Act 1995

Applies to all UK

Standard - EN 301 549

Accessibility requirements suitable for public procurement of ICT products and services in Europe

REGULATION (EU) No 1025/2012 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL

WCAG 2.X Level AA

The “failure to make a reasonable adjustment” definition in the 2018 SI refers to the detail already determined in the above two acts.

Directive (EU) 2016/2102

On the Accessibility of the websites and mobile applications of public sector bodies

284 of 349

Note

PSBAR =

Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018

https://matthewdeeprose.github.io/amazing.html

284

285 of 349

PSBAR (1)

The regulations set testable standards for web sites, documents, and mobile apps to meet in order to prove their accessibility, and a way for organisations to report on their compliance.

https://matthewdeeprose.github.io/amazing.html

285

286 of 349

PSBAR (2)

The regulations set testable standards for web sites, documents, and mobile apps to meet in order to prove their accessibility, and a way for organisations to report on their compliance.

https://matthewdeeprose.github.io/amazing.html

286

287 of 349

PSBAR (3)

Public sector bodies must comply with the accessibility requirement:

“accessibility requirement means the requirement to make a website or mobile application accessible by making it perceivable, operable, understandable and robust”

https://matthewdeeprose.github.io/amazing.html

287

288 of 349

PSBAR (4)

Public sector bodies must comply with the accessibility requirement:

“accessibility requirement means the requirement to make a website or mobile application accessible by making it perceivable, operable, understandable and robust”

https://matthewdeeprose.github.io/amazing.html

288

289 of 349

POUR

https://matthewdeeprose.github.io/amazing.html

289

Perceivable

Cater to our senses.

Operable

We can use the site.

Understandable

Readable and predictable.

Robust

Compatible across devices - even those to come in the future.

290 of 349

PSBAR (5)

“A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

https://matthewdeeprose.github.io/amazing.html

290

291 of 349

PSBAR (6)

“A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

https://matthewdeeprose.github.io/amazing.html

291

292 of 349

PSBAR (7)

“A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

https://matthewdeeprose.github.io/amazing.html

292

293 of 349

PSBAR (8)

A website of a public sector body will be presumed to be in conformity with the accessibility requirement to the extent that—

it fulfils the relevant requirements of the European standard on the accessibility requirements suitable for public procurement of ICT products and services in Europe.

https://matthewdeeprose.github.io/amazing.html

293

294 of 349

PSBAR (9)

A website of a public sector body will be presumed to be in conformity with the accessibility requirement to the extent that—

it fulfils the relevant requirements of the European standard on the accessibility requirements suitable for public procurement of ICT products and services in Europe.

https://matthewdeeprose.github.io/amazing.html

294

295 of 349

ETSI EN 301 549 V3.2.1 (2021-03)

Chapter 9: Web
Chapter 10: Non-web documents
Chapter 11: Software (mobile apps)

Version History

https://matthewdeeprose.github.io/amazing.html

295

296 of 349

PSBAR timeline

https://matthewdeeprose.github.io/amazing.html

296

23 September 2019

Websites published on or after 23 September 2018.

Office file formats*

Extranets and intranets**

23 September 2020

Websites published before 22 September 2018.

23 June 2021

Mobile apps.

*Office file formats published from 23 September 2018, and any published before 23rd September 2018 which are needed for active administrative processes relating to the tasks performed by the public sector body.

**Content of extranets and intranets published on or after 23rd September 2019, and any content published before 23rd September 2019 that has been substantially revised.

297 of 349

Full summary

https://matthewdeeprose.github.io/amazing.html

297

Out of scope	In scope	When
	Websites published on or after 23 September 2018.	After 22nd September 2019.
	Websites published before 22 September 2018.	After 22nd September 2020.
	Mobile apps.	After 22nd June 2021.
Office file formats published before 23rd September 2018, unless such content is needed for active administrative processes relating to the tasks performed by the public sector body.	Office file formats published from 23 September 2018, and any published before 23rd September 2018 which are needed for active administrative processes relating to the tasks performed by the public sector body.	After 22nd September 2019.
Pre-recorded time-based media published before 23rd September 2020.�	Pre-recorded time-based media published on or after 23rd September 2020.	After 23rd September 2020.
Live time-based media.	Recordings of live time-based media that are used on or after 23rd September 2020.	After 23rd September 2020.
Content of extranets and intranets published before 23rd September 2019, or until such time as the website undergoes a substantial revision, whichever is sooner.	Content of extranets and intranets published on or after 23rd September 2019, and any content published before 23rd September 2019 that has been substantially revised.	From 23rd September 2019.
Content of websites and mobile applications qualifying as archives, except those that are needed for active administrative processes or have been updated or edited since 23 September 2019.	Content of websites and mobile applications qualifying as archives that are needed for active administrative processes or have been updated or edited since 23 September 2019.	After 22nd September 2020.
Maps.	An accessible alternative to maps should be provided.	Depends on publishing date of host website (see above).
Reproductions of items in heritage collections that cannot be made fully accessible.	Some accessibility requirements for websites or mobile applications should still be complied with as regards the metadata linked to the reproduction of items in heritage collections.	Depends on publishing date of host website (see above).

298 of 349

Accessibility Statement 0

https://matthewdeeprose.github.io/amazing.html

298

299 of 349

Accessibility Statement 1

What is not accessible, and why.
Accessible alternatives.
Contact process.
Enforcement procedure.

https://matthewdeeprose.github.io/amazing.html

299

300 of 349

Accessibility Statement 3

What is not accessible, and why.
Accessible alternatives.
Contact process.
Enforcement procedure.

https://matthewdeeprose.github.io/amazing.html

300

301 of 349

Accessibility Statement 4

What is not accessible, and why.
Accessible alternatives.
Contact process.
Enforcement procedure.

https://matthewdeeprose.github.io/amazing.html

301

302 of 349

Accessibility Statement 7

What is not accessible, and why.
Accessible alternatives.
Contact process.
Enforcement procedure.

https://matthewdeeprose.github.io/amazing.html

302

303 of 349

Accessibility Statement 8

Should be based on a template provided by CDDO.

https://matthewdeeprose.github.io/amazing.html

303

304 of 349

Accessibility Statement 5

Should be based on a template provided by CDDO.

An opportunity to provide more information.

https://matthewdeeprose.github.io/amazing.html

304

305 of 349

What else might be in an Accessibility Statement?

Link to other statements

More information about using assistive technology with the site.

Links to other accessibility information.

https://matthewdeeprose.github.io/amazing.html

305

306 of 349

Maintaining accessibility statements for our services will…

https://matthewdeeprose.github.io/amazing.html

306

Build a culture of removing barriers to the use of our services.

Encourage reporting of accessibility defects, helping us to find new ways to improve our services and remove barriers.

307 of 349

Want to find good Accessibility Statement examples?

kent.ac.uk have 35 accessibility statements for their service

https://matthewdeeprose.github.io/amazing.html

307

308 of 349

Want to find good Accessibility Statement examples? 2

Kent also has a statement written by their DVC Education and Student Experience asking staff and students to “help the University meet accessibility standards”.

https://matthewdeeprose.github.io/amazing.html

308

309 of 349

Procurement

https://matthewdeeprose.github.io/amazing.html

309

310 of 349

Procurement 1

Require vendors to produce an Accessibility Conformant Report (ACR) for their product based on the Voluntary Product Accessibility Template (VPAT).
Ask about their accessibility roadmap.
Lobby current providers to improve accessibility and provide updates to their ACRs as products are upgraded.

https://matthewdeeprose.github.io/amazing.html

310

311 of 349

Procurement 2

Require vendors to produce an Accessibility Conformant Report (ACR) for their product based on the Voluntary Product Accessibility Template (VPAT).
Ask about their accessibility roadmap.
Lobby current providers to improve accessibility and provide updates to their ACRs as products are upgraded.

https://matthewdeeprose.github.io/amazing.html

311

312 of 349

Procurement 3

Require vendors to produce an Accessibility Conformant Report (ACR) for their product based on the Voluntary Product Accessibility Template (VPAT).
Ask about their accessibility roadmap.
Lobby current providers to improve accessibility and provide updates to their ACRs as products are upgraded.

https://matthewdeeprose.github.io/amazing.html

312

313 of 349

What does an ACR / VPAT look like?

https://matthewdeeprose.github.io/amazing.html

313

Criteria	Conformance level	Remarks and explanations
1.1.1 Non-text Content	Partially supports	The Blackboard Original Learn 9.1 web application provides text alternatives for most non-text items, with some exceptions: Some images lack a text alternative. Some images have an inadequate text alternative. Some decorative images are not hidden from assistive technologies.
1.3.3 Sensory Characteristics	Supports	The Blackboard Original Learn 9.1 web application does not rely on sensory characteristics for instructions.
2.1.4 Character Key Shortcuts	Not applicable	The Blackboard Original Learn 9.1 web application does not have single-letter character key shortcuts.

314 of 349

A useful poster

https://matthewdeeprose.github.io/amazing.html

314

Hassel Inclusion Poster (PDF)

315 of 349

Disability Equality Procurement Working Group

A new group to investigate this area is forming.

Dave Key and Tim Brody will represent iSolutions.

https://matthewdeeprose.github.io/amazing.html

315

316 of 349

Technical Architecture Group Non Functional Requirement for Cloud-based services

https://matthewdeeprose.github.io/amazing.html

316

Sub-Category	Requirement Description	Priority
Web accessibility	The solution complies with (or can be deployed to comply with) WCAG 2.0 AA and BS 8878:2010	Mandatory

317 of 349

What can happen when we customise commercial systems?

https://matthewdeeprose.github.io/amazing.html

317

‘Out of the box’ colour scheme. Focus indicator has AAA level contrast (7.36:1)

‘Marine 1’ colour for background.

Unchanged focus indicator would fail 2.4.12 Focus Appearance (Enhanced) (4.17:1)

318 of 349

Shifting left through the process (9)

https://matthewdeeprose.github.io/amazing.html

318

Requirements

Design

Build

Test

Release

Publish Accessibility statement as part of go-live checklist.
Accessibility testing as part of Change Management.
Dashboards.
Review accessibility statements annually.

Shift left

319 of 349

Including accessibility in the release process 1

Include the creation and publication of an accessibility statement within the “go-live checklist”.
Set date and ownership for reviewing the accessibility statement on an annual basis.

Accessibility Statement

https://matthewdeeprose.github.io/amazing.html

319

320 of 349

Including accessibility in the release process 2

Include the creation and publication of an accessibility statement within the “go-live checklist”.
Set date and ownership for reviewing the accessibility statement on an annual basis.

Accessibility Statement

https://matthewdeeprose.github.io/amazing.html

320

321 of 349

Including accessibility in the release process (1)

Add accessibility testing into the RFC template.
When creating an RFC add step for checking if accessibility statement requires an update.

https://matthewdeeprose.github.io/amazing.html

321

322 of 349

Including accessibility in the release process (1)12

Add accessibility testing into the RFC template.
When creating an RFC add step for checking if accessibility statement requires an update.

https://matthewdeeprose.github.io/amazing.html

322

323 of 349

Including accessibility in the release process (2)3

Add section to project closure / lessons learned reports?

Include accessibility within benefits realisation reviews?

https://matthewdeeprose.github.io/amazing.html

323

324 of 349

Including accessibility in the release process 2(2)3

Add section to project closure / lessons learned reports?

Include accessibility within benefits realisation reviews?

https://matthewdeeprose.github.io/amazing.html

324

325 of 349

Accessibility Dashboards

https://matthewdeeprose.github.io/amazing.html

325

326 of 349

Accessibility Dashboards (1)

https://matthewdeeprose.github.io/amazing.html

326

327 of 349

Who has responsibility for…

Accessibility testing
Writing and maintaining accessibility statements?
Putting accessibility into requirements.
Assessing benefits of accessible practices.

Prioritising and logging accessibility issues.
Informing users of benefits of using accessibility tools.

https://matthewdeeprose.github.io/amazing.html

327

328 of 349

Example from another Russell Group institution

https://matthewdeeprose.github.io/amazing.html

328

Policy area	Responsible
Approval of IT accessibility policy	Chief Information Officer
Accessibility Statements:
Creating, publishing and keeping up to date	Product Owner or Service Owner
Approving	Digital Accessibility Hub
Product testing:
Making accessibility part of Definition of Done (DoD)	Product teams
Prioritising accessibility remediation work	Product Owner/Manager

329 of 349

Example from another Russel Group institution 2

https://matthewdeeprose.github.io/amazing.html

329

Policy area	Responsible
Procurement:
Ensuring accessibility criteria as per IT policy are assessed as part of the procurement	Project Manager/Agile Delivery Manager
Producing accessibility exception report if criteria are not met	Project Manager/ADM
Authorising exceptions	One or more of: Applications Governance Group The relevant Domain Leader CIO or IT Leadership Team

330 of 349

Example from another Russel Group institution 3

https://matthewdeeprose.github.io/amazing.html

330

Policy area	Responsible
Lobbying suppliers on accessibility	Product Owner or Service Owner
Creating content: Producing accessible documents, web content, presentations, etc.	All staff

331 of 349

WCAG Levels of conformance

https://matthewdeeprose.github.io/amazing.html

331

A

Minimum level of conformance.

AA

More accessible / Recommended.

AAA

Even more accessible / Enhanced.

332 of 349

iSolutions ambitions

https://matthewdeeprose.github.io/amazing.html

332

A

The bare minimum.

AA

Required by law.

AAA

iSolutions delivering amazing accessibility.

333 of 349

Recommended Practices

Transformation Practices

Create a Central Accessibility Team
Obtain Executive Buy-In
Create and Enforce an Accessibility Policy
Report on Your Accessibility Transformation
Give the Teams Accessibility Coaches
Execute on an Ongoing Empathy Campaign
Publish Learning Resources and Bulletins

https://matthewdeeprose.github.io/amazing.html

333

334 of 349

Recommended Practices 2

Team Practices

Attend and Host Empathy Events
Include Disabilities in UX Design
Communicate Intent with Accessibility Design Annotation
Create a User Interface Pattern Library
Leverage an Accessibility Automation Library
Automate Device and Assistive Technology Testing
Manage Accessibility Defects Systematically
Measure Accessibility
Include Accessibility in Retrospectives and Sprint Planning

https://matthewdeeprose.github.io/amazing.html

334

335 of 349

What have we covered?

What barriers might users experience?

Examples from our own services

How we can “shift left” to start our journey toward amazing accessibility.

Examples from across the IT sector.
Links to find out more.

Practical steps in accessibility testing you can use.
Digital Accessibility and the Law.

https://matthewdeeprose.github.io/amazing.html

335

336 of 349

Shifting left through the process (11)

https://matthewdeeprose.github.io/amazing.html

336

Requirements

Design

Build

Test

Release

“Make sure it’s accessible”

“Only release when it’s accessible”

Shift left

“Test that it’s accessible.”

Use whatever techniques you prefer.

337 of 349

So what do we do now?

https://matthewdeeprose.github.io/amazing.html

337

338 of 349

So, what do we do now? 1

https://matthewdeeprose.github.io/amazing.html

338

Try some of the techniques

Discuss within your teams.

Share back your reflections within our community.

339 of 349

So, what do we do now? 2

https://matthewdeeprose.github.io/amazing.html

339

Investigate the accessibility of your services.

Show others the quick accessibility tests.

Build accessibility into your processes.

340 of 349

Digital Accessibility Community of Practice

Join our Digital Accessibility Community of Practice team using this join code ryprgyd
This guide explains how to join a team using a code.

https://matthewdeeprose.github.io/amazing.html

340

341 of 349

Learning more: mailing lists and teams

JISC Accessibility Mailing List

JISC Accessibility Community

Access Technology Higher Education Network Mailing List

WebAim Mailing List

https://matthewdeeprose.github.io/amazing.html

341

342 of 349

Want to learn more?

https://matthewdeeprose.github.io/amazing.html

342

343 of 349

Learning more

https://matthewdeeprose.github.io/amazing.html

343

http://bit.ly/10-days-of-a11y

https://dwcag.org/#sign-up-section

344 of 349

Blind Onion Tweet

https://matthewdeeprose.github.io/amazing.html

344

345 of 349

GAAD Pledge

https://matthewdeeprose.github.io/amazing.html

345

346 of 349

A wave of momentum toward accessibility

https://matthewdeeprose.github.io/amazing.html

346

347 of 349

A wave of momentum toward accessibility (2)

https://matthewdeeprose.github.io/amazing.html

347

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018

Blackboard Ally rollout

Common Framework for Online Education

Enhancing Academic Support and Delivery: Inclusion and Accessibility workstreams

Disability SAT IT strategy

Working from home – accessibility benefits/ Occupational Health

IT strategy

Worldwide momentum toward accessibility

Global Accessibility Awareness Day

UoS Disability Confident award

UoS Access and Participation Plan

Office for Students accessibility statement monitoring

Competitor institutions already ahead

Skills and Post-16 Education Bill

Student Disability and inclusion Strategy

iSolutions amazing accessibility

348 of 349

Current state 2

https://matthewdeeprose.github.io/amazing.html

348

Current state

Baseline accessibility / Legal compliance

Add to release process.

Add to requirements process.

Investigate automation and testing.

Automation and testing processes defined.

Publish accessibility statements.

Log and prioritise accessibility issues.

Amazing accessibility

Promote benefits for all of accessibility features.

Involve users of all abilities in codesign and testing.

Report on progress and demonstrate benefits.

Aiming for AAA compliance where possible.

A growing culture that values accessibility.

349 of 349

SWOT analysis

https://matthewdeeprose.github.io/amazing.html

349

PSBAR

Lack of accessibility statements
Lack of engagement
Who will be the first University sanctioned?

Competitors institutions far ahead.
Lower continuation rate of students who declare a disability.

Aligns

with reorg and new structure.
with strategy.
with UDL.

Access and Participation plan
Institutional hunger for leadership and advice.
Growing need for OH guidance, accelerated by remote working.
Assist Enabling to toward more specialist support.

No processes

Accessibility not part of change process.
Accessibility excluded from project management.
No accessibility training.
No accessibility testing.

Technical Architecture Group Non Functional Requirements Cloud based services WCAG 2.0.
Blackboard Ally Rollout.
Digital Accessibility Community of Practice.
Expertise elsewhere within institution (e.g. ECS, OneWeb)
Accessibility in some job descriptions.

Strengths

Weaknesses

Threats

Opportunities