Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Handout All notes and links are available at: https://matthewdeeprose.github.io/amazing.html https://matthewdeeprose.github.io/amazing.html 2

Slide 3

Slide 3 text

Accessibility is a journey https://matthewdeeprose.github.io/amazing.html 3

Slide 4

Slide 4 text

Current state https://matthewdeeprose.github.io/amazing.html 4 Current state Amazing accessibility Baseline accessibility / Legal compliance

Slide 5

Slide 5 text

Cost of accessibility bugs https://matthewdeeprose.github.io/amazing.html 5 C o s t Requirements Design Build Test Release Source: Glenda Sims, Deque Cost of accessibility bugs

Slide 6

Slide 6 text

When should we consider accessibility? https://matthewdeeprose.github.io/amazing.html 6 C o s t Requirements Design Build Test Release Source: Glenda Sims, Deque The earlier we consider accessibility the better!

Slide 7

Slide 7 text

Shift left Shifting left through the process (4) Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 7 • 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

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

Why should we care? 0 https://matthewdeeprose.github.io/amazing.html 9 https://web.microsoftstream.com/video/ae24ab7b-32ac-489c-bf51-5c937cd60f06

Slide 10

Slide 10 text

What barriers might users experience? 0 https://matthewdeeprose.github.io/amazing.html 10

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

What barriers might users experience? (5) 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. https://matthewdeeprose.github.io/amazing.html 15 Following accessibility guidelines removes such barriers.

Slide 16

Slide 16 text

Colour Contrast / Colour as only meaning https://matthewdeeprose.github.io/amazing.html 16 iSolutions real world example

Slide 17

Slide 17 text

When a screen reader cannot make sense of an interface. (2) Example from https://www.youtube.com/watch?v=0hqhAIjE_8I “List with 3 items. First item. UI Design. Button” https://matthewdeeprose.github.io/amazing.html 17

Slide 18

Slide 18 text

When a screen reader cannot make sense of an interface. “List with 3 items. First item. UI Design. Button Collapsed” Example from https://www.youtube.com/watch?v=0hqhAIjE_8I https://matthewdeeprose.github.io/amazing.html 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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: • 3.2.1 On Focus • 1.4.2 Audio Control • 2.2.2 Pause, Stop, Hide • 2.3.1 Three Flashes or Below Threshold https://matthewdeeprose.github.io/amazing.html 21

Slide 22

Slide 22 text

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: • 3.3.1 Error Identification • 3.3.2 Labels or Instructions • 3.3.3 Error Suggestion • 3.3.4 Error Prevention (Legal, Financial, Data) https://matthewdeeprose.github.io/amazing.html 22

Slide 23

Slide 23 text

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: • 1.4.1 Use of Colour • 1.4.3 Contrast (Minimum) • 1.4.4 Resize text • 1.4.5 Images of Text • 1.4.10 Reflow • 1.4.11 Non-text Contrast https://matthewdeeprose.github.io/amazing.html 23

Slide 24

Slide 24 text

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: • 3.3.1 Error Identification • 3.3.2 Labels or Instructions • 3.3.3 Error Suggestion • 3.3.4 Error Prevention (Legal, Financial, Data) https://matthewdeeprose.github.io/amazing.html 24

Slide 25

Slide 25 text

What about our own systems? https://matthewdeeprose.github.io/amazing.html 25

Slide 26

Slide 26 text

Eassignment system iSolutions real world example https://matthewdeeprose.github.io/amazing.html 26

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

COVID guidance page 3 INC1847426 raised 13 March 2020. No response to user. https://matthewdeeprose.github.io/amazing.html 31 iSolutions real world example

Slide 32

Slide 32 text

COVID guidance page 4 More than 12 months later, no activity within ticket. https://matthewdeeprose.github.io/amazing.html 32 iSolutions real world example

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

This wasn’t due to lack of skill or knowledge https://matthewdeeprose.github.io/amazing.html 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

What might this tell us? 6 It wasn’t part of the requirements to ensure accessibility. https://matthewdeeprose.github.io/amazing.html 44 It wasn’t part of the release process to assure accessibility.

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Cost of accessibility bugs (again) https://matthewdeeprose.github.io/amazing.html 46 C o s t Requirements Design Build Test Release Source: Glenda Sims, Deque

Slide 47

Slide 47 text

When should we consider accessibility? 2 https://matthewdeeprose.github.io/amazing.html 47 C o s t Requirements Design Build Test Release Source: Glenda Sims, Deque The earlier we consider accessibility the better!

Slide 48

Slide 48 text

Using examples from https://matthewdeeprose.github.io/amazing.html 48

Slide 49

Slide 49 text

Agile Accessibility Handbook https://matthewdeeprose.github.io/amazing.html 49 https://www.amazon.co.uk/dp/164543477X/ref=cm_sw_r_tw_dp_CM86XQFQ4KKRZ04Z2Z3N

Slide 50

Slide 50 text

Shifting left through the process (10) Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 50 “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.”

Slide 51

Slide 51 text

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.

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

The number of students who disclose a disability at UoS is increasing. (5) 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://matthewdeeprose.github.io/amazing.html 56 * https://go.soton.ac.uk/dkr ** https://bit.ly/3gDtxyz

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Maximise the potential of the University’s digital estate for all stakeholders. https://matthewdeeprose.github.io/amazing.html 58 Microsoft Design

Slide 59

Slide 59 text

Increasing need for assistive technology https://matthewdeeprose.github.io/amazing.html 59

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Most common issues OH related to IT are: https://matthewdeeprose.github.io/amazing.html 61 Vision 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

Slide 62

Slide 62 text

Occupational Health Most common issues related to IT are: Vision https://matthewdeeprose.github.io/amazing.html 62

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

What does the strategy say? “[enable] the exploitation of digital technology by the University” https://matthewdeeprose.github.io/amazing.html 66

Slide 67

Slide 67 text

Occupational Health Referral Form Language “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?” https://matthewdeeprose.github.io/amazing.html 67

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

It saves money 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://matthewdeeprose.github.io/amazing.html 69 * https://www.mightybytes.com/blog/digital-accessibility-series-part-one/ ** https://www.w3.org/WAI/fundamentals/accessibility-principles/#robust *** UoS Access and Participation Plan

Slide 70

Slide 70 text

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.

Slide 71

Slide 71 text

It’s the right thing to do 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://matthewdeeprose.github.io/amazing.html 71 * 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

Slide 72

Slide 72 text

It’s the right thing to do 2 https://matthewdeeprose.github.io/amazing.html 72

Slide 73

Slide 73 text

What does the strategy say? (2) “We will: • Get the basics right •Continually [improve] our services” https://matthewdeeprose.github.io/amazing.html 73

Slide 74

Slide 74 text

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.

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Multimedia Development Team Lead / Multimedia Developer “Knowledge of accessibility issues relating to multimedia design.” Person Specification - Desirable https://matthewdeeprose.github.io/amazing.html 79

Slide 80

Slide 80 text

Expertise in digital accessibility will be required by companies who do business around the world. https://matthewdeeprose.github.io/amazing.html 80

Slide 81

Slide 81 text

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/

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

Accessibility for Ontarians with Disabilities Act (AODA) 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. https://matthewdeeprose.github.io/amazing.html 83

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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.

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

What did SLT say? (3) “…We are going to deliver amazing accessibility. Because it is the right thing to do” https://matthewdeeprose.github.io/amazing.html 88 Accessibility Situation Report: An intro and update. • Dave Key • 18 December 2020 • iSolutions All-staff meeting.

Slide 89

Slide 89 text

Shifting left through the process (1)4 Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 89 • Browser based test tools. • Checklists / checking sheet. • Command line tools. • CI tools. • Automated tests with Selenium etc. • Gherkin tests. Shift left

Slide 90

Slide 90 text

What recommendations are there? The Web Content Accessibility Guidelines provide guidelines, explanations, and example techniques that pass the test. https://matthewdeeprose.github.io/amazing.html 90

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

Levels of conformance: AAA A Minimum level of conformance. AA More accessible / Recommended. AAA Even more accessible / Enhanced. Legal requirement “Amazing accessibility?” https://matthewdeeprose.github.io/amazing.html 92

Slide 93

Slide 93 text

Accessibility guidelines have four high-level principles. 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. https://matthewdeeprose.github.io/amazing.html 93

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

Example support resources “Understanding” page • Intent • Benefits • Examples • Related Resources • Techniques • Test Rules • Key Terms “How to meet” guide • Sufficient Techniques • Advisory Techniques • Failures https://matthewdeeprose.github.io/amazing.html 95

Slide 96

Slide 96 text

Example ‘sufficient techniques’ for reflow • C32: Using media queries and grid CSS to reflow columns • C31: Using CSS Flexbox to reflow content • C33: Allowing for Reflow with Long URLs and Strings of Text • C38: Using CSS width, max-width and flexbox to fit labels and inputs • SCR34: Calculating size and position in a way that scales with text size • C34: Using media queries to un- fixing sticky headers / footers • C37: Using CSS max-width and height to fit images https://matthewdeeprose.github.io/amazing.html 96

Slide 97

Slide 97 text

Best starting point Full, filterable WCAG criteria. Includes all links to explanations, techniques, and failures. https://www.w3.org/WAI/WCAG21/quickref https://matthewdeeprose.github.io/amazing.html 97

Slide 98

Slide 98 text

What are we aiming for? 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 https://matthewdeeprose.github.io/amazing.html 98 Baseline Some are simple to attain. Based on WCAG 2.2

Slide 99

Slide 99 text

Examples of achievable AAA criteria https://matthewdeeprose.github.io/amazing.html 99 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.

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

Case study: what does a professional accessibility audit look like? https://matthewdeeprose.github.io/amazing.html 103

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

CDDO 2 • How do automated accessibility checkers compare? • Deep dive comparison • Example inaccessible web page. https://matthewdeeprose.github.io/amazing.html 113

Slide 114

Slide 114 text

Types of test https://matthewdeeprose.github.io/amazing.html 114 Automated Manual Guided

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

How effective is automated accessibility testing? https://matthewdeeprose.github.io/amazing.html 116

Slide 117

Slide 117 text

Automated testing possibilities https://matthewdeeprose.github.io/amazing.html 117 Browser addon Command line Continuous integration

Slide 118

Slide 118 text

Browser plugins The full slide deck has details and advantages and disadvantages of each, along with links and further information. https://matthewdeeprose.github.io/amazing.html 118

Slide 119

Slide 119 text

Lighthouse Lighthouse •Built into Chrome •Accessible from within Dev Tools. •Uses axecore. https://matthewdeeprose.github.io/amazing.html 119

Slide 120

Slide 120 text

Lighthouse 2 https://matthewdeeprose.github.io/amazing.html 120

Slide 121

Slide 121 text

Lighthouse 3 https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/ https://matthewdeeprose.github.io/amazing.html 121

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

Wave https://matthewdeeprose.github.io/amazing.html 123 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.

Slide 124

Slide 124 text

Wave (1) https://matthewdeeprose.github.io/amazing.html 124

Slide 125

Slide 125 text

Wave errors https://matthewdeeprose.github.io/amazing.html 125

Slide 126

Slide 126 text

Explanation of errors https://matthewdeeprose.github.io/amazing.html 126

Slide 127

Slide 127 text

Wave Structure https://matthewdeeprose.github.io/amazing.html 127

Slide 128

Slide 128 text

Wave contrast checker https://matthewdeeprose.github.io/amazing.html 128

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

Arc Toolkit Example 1 https://matthewdeeprose.github.io/amazing.html 131

Slide 132

Slide 132 text

Arc Toolkit Example 2 https://matthewdeeprose.github.io/amazing.html 132

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

ASLint https://aslint.org/ •Created by eSSENTIAL Accessibility •Bookmarklet https://matthewdeeprose.github.io/amazing.html 134

Slide 135

Slide 135 text

ASLint (2) https://matthewdeeprose.github.io/amazing.html 135

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

IBM Equal Access Checker https://www.ibm.com/abl e/toolkit/ •Chrome, Firefox, Node.js https://matthewdeeprose.github.io/amazing.html 137

Slide 138

Slide 138 text

IBM Equal Access Checker 1 https://matthewdeeprose.github.io/amazing.html 138

Slide 139

Slide 139 text

IBM Equal Access Checker 2 https://matthewdeeprose.github.io/amazing.html 139

Slide 140

Slide 140 text

IBM Equal Access Checker 3 https://matthewdeeprose.github.io/amazing.html 140

Slide 141

Slide 141 text

IBM Equal Access Checker 5 https://matthewdeeprose.github.io/amazing.html 141

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

Axe 1 https://matthewdeeprose.github.io/amazing.html 144

Slide 145

Slide 145 text

Axe 21 https://matthewdeeprose.github.io/amazing.html 145

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

Accessibility Insights 1 https://matthewdeeprose.github.io/amazing.html 148

Slide 149

Slide 149 text

Accessibility Insights 2 https://matthewdeeprose.github.io/amazing.html 149

Slide 150

Slide 150 text

Accessibility Insights 3 https://matthewdeeprose.github.io/amazing.html 150

Slide 151

Slide 151 text

Accessibility Insights 4 https://matthewdeeprose.github.io/amazing.html 151

Slide 152

Slide 152 text

Accessibility Insights 5 https://matthewdeeprose.github.io/amazing.html 152

Slide 153

Slide 153 text

Accessibility Insights 6 https://matthewdeeprose.github.io/amazing.html 153

Slide 154

Slide 154 text

Accessibility Insights 7 https://matthewdeeprose.github.io/amazing.html 154

Slide 155

Slide 155 text

Command line tools https://matthewdeeprose.github.io/amazing.html 155 Mainly use node.js and NPM. Axe and Pa11y are most popular.

Slide 156

Slide 156 text

Axe 2 https://matthewdeeprose.github.io/amazing.html 156

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

Command line tools resources • Axe core CLI • Automated Accessibility checking with axe • Axe-cli, pa11y, lighthouse guide • Axe Core NPM tutorial • NPM Projects using Axe • GhostJS Accessibility Helper • InternA11y • A11y-sitechecker • Pa11y: CLI and CI tools • Accessibility Testing With pa11y • More Accessibility Testing with pa11y • Using actions in Pa11y • A11y CLI Tools https://matthewdeeprose.github.io/amazing.html 158

Slide 159

Slide 159 text

Continuous integration tools https://matthewdeeprose.github.io/amazing.html 159

Slide 160

Slide 160 text

Continuous integration resources • Pa11y CI • Using Pa11y CI and Drone as accessibility testing gatekeepers • Automated accessibility testing with Travis CI • Jest with axe • Leveraging GitHub Actions and pa11y-ci with axe • Cypress Axe • Setting up Selenium, and Axe for automated testing • Accessibility Unit testing with Jasmine / QUnit https://matthewdeeprose.github.io/amazing.html 160

Slide 161

Slide 161 text

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://www.youtube.com/watch?v=CqxfrrMwhaY https://matthewdeeprose.github.io/amazing.html 161

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

What automated tests won’t find .ext-webkit *:focus { outline: none !important; } https://matthewdeeprose.github.io/amazing.html 166 Click Here $(function() { $('img:not([alt])').attr('alt',''); }); 2.4.7: Focus Visible 2.4.4: Link Purpose (In Context) 1.1.1: Non-text Content 2.4.3: Focus Order

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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

Slide 170

Slide 170 text

Simple tests you can do now https://matthewdeeprose.github.io/amazing.html 170

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

1. Run automated tests using a browser plugin or command line tool. Verify failures Assess priority Report to development team or vendor for assessment. https://matthewdeeprose.github.io/amazing.html 172

Slide 173

Slide 173 text

2. Validate pages Use https://validator.w3.org Covers 4.1.1 Parsing. https://matthewdeeprose.github.io/amazing.html 173

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

Keyboard test (2) Navigate website using tab, enter/return, cursor keys 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 https://matthewdeeprose.github.io/amazing.html 175 If you use a Mac and/or Safari, please make sure your settings allow for tabbing to interactive elements.

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

Text spacing? Avoid overlaps, and horizontal / vertical cut offs. Understanding Success Criterion 1.4.12: Text Spacing https://matthewdeeprose.github.io/amazing.html 177

Slide 178

Slide 178 text

Overlaps and cut offs? 2 Avoid overlaps, and horizontal / vertical cut offs. Understanding Success Criterion 1.4.12: Text Spacing iSolutions real world example: only happens using keyboard navigation. https://matthewdeeprose.github.io/amazing.html 178

Slide 179

Slide 179 text

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 •Greyscale the web •Accessibility insights has this feature too. https://matthewdeeprose.github.io/amazing.html 179

Slide 180

Slide 180 text

Example of why you should not use colour as the only means to convey meaning. 180 https://matthewdeeprose.github.io/amazing.html Ready to submit your final assignment? Example using simulated Deuteranopia rendering in Google Chrome

Slide 181

Slide 181 text

Is it understandable in black and white? (2) 181 https://matthewdeeprose.github.io/amazing.html

Slide 182

Slide 182 text

Accessibility Insights 51 https://matthewdeeprose.github.io/amazing.html 182

Slide 183

Slide 183 text

Example where colour is not the only means to convey meaning. 183 https://matthewdeeprose.github.io/amazing.html Ready to submit your final assignment? No Yes Example using simulated Deuteranopia rendering in Google Chrome

Slide 184

Slide 184 text

Examples using pie charts Insufficient contrast between colours. 184 https://matthewdeeprose.github.io/amazing.html Use of labels means colour is not the only way to understand the graph.

Slide 185

Slide 185 text

Examples using line graphs Insufficient contrast between colours. Use of markers / dotted lines means colour is not the only way to understand the graph. 185 https://matthewdeeprose.github.io/amazing.html

Slide 186

Slide 186 text

Is it understandable in black and white? 186 https://matthewdeeprose.github.io/amazing.html

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

7. Test in High Contrast Mode • 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? https://matthewdeeprose.github.io/amazing.html 188

Slide 189

Slide 189 text

7. Test in High Contrast Mode (2) • Assistive Technology Experiment: High Contrast • Quick Tips for High Contrast Mode https://matthewdeeprose.github.io/amazing.html 189

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

Screen Reader Resources • How A Screen Reader User Surfs The Web (video demo) • NVDA keyboard shortcuts • Testing accessibility using NVDA (also video guide). • Accessibility testing as a screen reader user •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

Slide 193

Slide 193 text

9. Check colours used have sufficient contrast 0 https://matthewdeeprose.github.io/amazing.html 193

Slide 194

Slide 194 text

Revisiting hard to read contrast examples 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 https://matthewdeeprose.github.io/amazing.html 194

Slide 195

Slide 195 text

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:1 FAIL 1.99:1 FAIL 2.15:1 FAIL 2.49:1 FAIL 4.19:1 PASS 1.8:1 FAIL 4.84:1 PASS 3.34:1 PASS 3.23:1 PASS

Slide 196

Slide 196 text

The ratios to remember 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) https://matthewdeeprose.github.io/amazing.html 196

Slide 197

Slide 197 text

Helpful tools https://matthewdeeprose.github.io/amazing.html 197 https://buttonbuddy.dev/ https://webaim.org/resources/linkcontrastchecker/

Slide 198

Slide 198 text

Colour Matrix 198 https://matthewdeeprose.github.io/amazing.html https://elearn.southampton.ac.uk/accessibility/colours

Slide 199

Slide 199 text

How to deal with text over images? 199 https://matthewdeeprose.github.io/amazing.html Mitesh7587 / Wikimedia / CC BY-SA 4.0

Slide 200

Slide 200 text

Text with a background image 200 https://matthewdeeprose.github.io/amazing.html 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/

Slide 201

Slide 201 text

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

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

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

Slide 204

Slide 204 text

11. Use further quick tools 3 https://matthewdeeprose.github.io/amazing.html 204 https://chrome.google.com/webstore/detail/web-disability-simulator/olioanlbgbpmdlgjnnampnnlohigkjla

Slide 205

Slide 205 text

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

Slide 206

Slide 206 text

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.

Slide 207

Slide 207 text

Testing spreadsheet https://matthewdeeprose.github.io/amazing.html 207 https://go.soton.ac.uk/acctesting

Slide 208

Slide 208 text

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

Slide 209

Slide 209 text

WAI Easy Checks Simple checks with instructions and examples. • Page title • Image text alternatives ("alt text") (pictures, illustrations, charts, etc.) • Text: • Headings • Contrast ratio ("color contrast") • Resize Text • Interaction: • Keyboard access and visual focus • Forms, labels, and errors (including Search fields) • General: • Moving, Flashing, or Blinking Content • Multimedia (video, audio) alternatives • Basic Structure Check 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/

Slide 210

Slide 210 text

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/

Slide 211

Slide 211 text

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/

Slide 212

Slide 212 text

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/

Slide 213

Slide 213 text

NHS Accessibility audit checklist https://matthewdeeprose.github.io/amazing.html 213

Slide 214

Slide 214 text

NHS Accessibility audit checklist (2) Does not cover all WCAG criteria, but links well to “sufficient techniques”. Practical and achievable. https://matthewdeeprose.github.io/amazing.html 214

Slide 215

Slide 215 text

Alison Walden’s guide Example extract 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 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

Slide 216

Slide 216 text

A11y Project Checklist https://matthewdeeprose.github.io/amazing.html 216 https://www.a11yproject.com/checklist

Slide 217

Slide 217 text

A11y Project Checklist (2) ✓ Tick-able (but session not kept) ✓Easy to follow ✓Linked to WCAG ✓Sharable links https://www.a11yproject.com/checklist https://matthewdeeprose.github.io/amazing.html 217

Slide 218

Slide 218 text

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

Slide 219

Slide 219 text

WCAG success criteria can be complex https://matthewdeeprose.github.io/amazing.html 219

Slide 220

Slide 220 text

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

Slide 221

Slide 221 text

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

Slide 222

Slide 222 text

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

Slide 223

Slide 223 text

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

Slide 224

Slide 224 text

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

Slide 225

Slide 225 text

Gherkin Library https://matthewdeeprose.github.io/amazing.html 225

Slide 226

Slide 226 text

Guided Tests https://matthewdeeprose.github.io/amazing.html 226

Slide 227

Slide 227 text

Axe Pro Guided Tests https://matthewdeeprose.github.io/amazing.html 227

Slide 228

Slide 228 text

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

Slide 229

Slide 229 text

Accessibility Insights 6 B https://matthewdeeprose.github.io/amazing.html 229

Slide 230

Slide 230 text

Accessibility Insights C https://accessibilityinsights.io/ • Report can be exported to an HTML file. https://matthewdeeprose.github.io/amazing.html 230

Slide 231

Slide 231 text

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.

Slide 232

Slide 232 text

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

Slide 233

Slide 233 text

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

Slide 234

Slide 234 text

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

Slide 235

Slide 235 text

How to prioritise issues? https://matthewdeeprose.github.io/amazing.html 235

Slide 236

Slide 236 text

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

Slide 237

Slide 237 text

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

Slide 238

Slide 238 text

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

Slide 239

Slide 239 text

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.

Slide 240

Slide 240 text

Serious issues 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. https://matthewdeeprose.github.io/amazing.html 240

Slide 241

Slide 241 text

Moderate 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. https://matthewdeeprose.github.io/amazing.html 241

Slide 242

Slide 242 text

Minor issues 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. https://matthewdeeprose.github.io/amazing.html 242

Slide 243

Slide 243 text

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

Slide 244

Slide 244 text

Defining levels of severity for accessibility issues 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 https://matthewdeeprose.github.io/amazing.html 244

Slide 245

Slide 245 text

Shifting left through the process (15 Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 245 • Linters and IDE plugins. • Framework extensions (e.g. Bootstrap accessibility plugin) • Git actions. Shift left

Slide 246

Slide 246 text

Integrated development environment plugins ✓ Identify possible accessibility issues whilst coding. https://matthewdeeprose.github.io/amazing.html 246

Slide 247

Slide 247 text

Visual Studio Code https://matthewdeeprose.github.io/amazing.html 247 • Web Accessibility Linter for VS Code • Axe Core Linter for VS Code • Bri11iant: a VSCode language extension for supporting web developers improve the accessibility of their websites. • Using Tenon Accessibility Checker in VS Code • WebHint – Accessibility testing + plugin for Visual Studio Code

Slide 248

Slide 248 text

Atom https://matthewdeeprose.github.io/amazing.html 248 • Atom accessibility plugin • Atom accessibility snippets

Slide 249

Slide 249 text

For Frameworks • React • React-a11y. • Static AST checker for accessibility rules on JSX elements. • Accessibility with React • Accessibility-Flavoured React Components • Storybook Accessibility Addon • Vue • Accessibility auditing for Vue.js 3 • Angular • Proctractor / Angular Accessibility testing • Bootstrap • Bootstrap accessibility plugin • Accessible bootstrap frameworks • Ember • ember-a11y-testing https://matthewdeeprose.github.io/amazing.html 249

Slide 250

Slide 250 text

Bootstrap https://matthewdeeprose.github.io/amazing.html 250 3.98:1 FAIL 3.13:1 FAIL 12.9:1 PASS 16.9:1 PASS 4.69:1 PASS 4.53:1 FAIL 3.04:1 FAIL 11.5:1 PASS 4.02:1 FAIL

Slide 251

Slide 251 text

Source Control Axe Linter analyses changed or added code of pull requests, reports issues https://matthewdeeprose.github.io/amazing.html 251

Slide 252

Slide 252 text

Source Control (2) Automatically requests changes to resolve common issues. https://matthewdeeprose.github.io/amazing.html 252

Slide 253

Slide 253 text

Shifting left through the process (6) Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 253 • Involve users (including with impairments) in co-design. • Accessible component library and atomic design elements. • Annotate wireframes with accessibility details. Shift left

Slide 254

Slide 254 text

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

Slide 255

Slide 255 text

Using concepts from “Atomic Design” by Brad Frost https://matthewdeeprose.github.io/amazing.html 255

Slide 256

Slide 256 text

Design Tokens https://matthewdeeprose.github.io/amazing.html 256

Slide 257

Slide 257 text

Example Atoms https://matthewdeeprose.github.io/amazing.html 257

Slide 258

Slide 258 text

Example Molecule https://matthewdeeprose.github.io/amazing.html 258

Slide 259

Slide 259 text

Example Organism https://matthewdeeprose.github.io/amazing.html 259

Slide 260

Slide 260 text

Templates and pages Template Page https://matthewdeeprose.github.io/amazing.html 260

Slide 261

Slide 261 text

Component Guides https://matthewdeeprose.github.io/amazing.html 261 https://www.w3.org/TR/wai-aria-practices-1.2

Slide 262

Slide 262 text

Component Libraries https://inclusive-components.design/ https://www.digitala11y.com/accessible-ui-component-libraries-roundup/ https://matthewdeeprose.github.io/amazing.html 262

Slide 263

Slide 263 text

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

Slide 264

Slide 264 text

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

Slide 265

Slide 265 text

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://www.youtube.com/watch?v=qqQeQdqsnAI https://matthewdeeprose.github.io/amazing.html 265

Slide 266

Slide 266 text

How Verizon defines what they mean by accessibility Example component definition Formelements 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. Example brand guideline Experiences workfor 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

Slide 267

Slide 267 text

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

Slide 268

Slide 268 text

OneWeb 5 The OneWeb Team has done some excellent work on involving users within the design process. https://matthewdeeprose.github.io/amazing.html 268

Slide 269

Slide 269 text

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

Slide 270

Slide 270 text

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

Slide 271

Slide 271 text

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

Slide 272

Slide 272 text

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

Slide 273

Slide 273 text

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

Slide 274

Slide 274 text

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

Slide 275

Slide 275 text

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

Slide 276

Slide 276 text

How can we ensure accessibility is considered from the beginning? https://matthewdeeprose.github.io/amazing.html 276

Slide 277

Slide 277 text

Shifting left through the proce8s Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 277 • Include accessibility within project documentation. • TAG Non Functional Requirements. • Accessible procurement Shift left

Slide 278

Slide 278 text

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.

Slide 279

Slide 279 text

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.

Slide 280

Slide 280 text

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.

Slide 281

Slide 281 text

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.

Slide 282

Slide 282 text

How does the law fit into this? https://matthewdeeprose.github.io/amazing.html 282

Slide 283

Slide 283 text

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

Slide 284

Slide 284 text

Note PSBAR = Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 https://matthewdeeprose.github.io/amazing.html 284

Slide 285

Slide 285 text

PSBAR (1) https://matthewdeeprose.github.io/amazing.html 285 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.

Slide 286

Slide 286 text

PSBAR (2) https://matthewdeeprose.github.io/amazing.html 286 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.

Slide 287

Slide 287 text

PSBAR (3) https://matthewdeeprose.github.io/amazing.html 287 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”

Slide 288

Slide 288 text

PSBAR (4) https://matthewdeeprose.github.io/amazing.html 288 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”

Slide 289

Slide 289 text

POUR 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. https://matthewdeeprose.github.io/amazing.html 289

Slide 290

Slide 290 text

PSBAR (5) https://matthewdeeprose.github.io/amazing.html 290 “A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

Slide 291

Slide 291 text

PSBAR (6) https://matthewdeeprose.github.io/amazing.html 291 “A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

Slide 292

Slide 292 text

PSBAR (7) https://matthewdeeprose.github.io/amazing.html 292 “A public sector body must provide an accessibility statement in accordance with the model accessibility statement, and keep that statement under regular review”

Slide 293

Slide 293 text

PSBAR (8) https://matthewdeeprose.github.io/amazing.html 293 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.

Slide 294

Slide 294 text

PSBAR (9) https://matthewdeeprose.github.io/amazing.html 294 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.

Slide 295

Slide 295 text

ETSI EN 301 549 V3.2.1 (2021-03) • Chapter 9: Web • Chapter 10: Non-web documents • Chapter 11: Software (mobile apps) Version History •V3.1.1 (2019-11) •V2.1.2 (2018-08) •V1.1.2 (2015-04) •V1.1.1 (2014-02) https://matthewdeeprose.github.io/amazing.html 295

Slide 296

Slide 296 text

PSBAR timeline 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. https://matthewdeeprose.github.io/amazing.html 296 *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.

Slide 297

Slide 297 text

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). https://matthewdeeprose.github.io/amazing.html 297

Slide 298

Slide 298 text

Accessibility Statement 0 https://matthewdeeprose.github.io/amazing.html 298

Slide 299

Slide 299 text

Accessibility Statement 1 1. What is not accessible, and why. 2. Accessible alternatives. 3. Contact process. 4. Enforcement procedure. https://matthewdeeprose.github.io/amazing.html 299

Slide 300

Slide 300 text

Accessibility Statement 3 1. What is not accessible, and why. 2. Accessible alternatives. 3. Contact process. 4. Enforcement procedure. https://matthewdeeprose.github.io/amazing.html 300

Slide 301

Slide 301 text

Accessibility Statement 4 1. What is not accessible, and why. 2. Accessible alternatives. 3. Contact process. 4. Enforcement procedure. https://matthewdeeprose.github.io/amazing.html 301

Slide 302

Slide 302 text

Accessibility Statement 7 1. What is not accessible, and why. 2. Accessible alternatives. 3. Contact process. 4. Enforcement procedure. https://matthewdeeprose.github.io/amazing.html 302

Slide 303

Slide 303 text

Accessibility Statement 8 Should be based on a template provided by CDDO. https://matthewdeeprose.github.io/amazing.html 303

Slide 304

Slide 304 text

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

Slide 305

Slide 305 text

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

Slide 306

Slide 306 text

Maintaining accessibility statements for our services will… 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. https://matthewdeeprose.github.io/amazing.html 306

Slide 307

Slide 307 text

Want to find good Accessibility Statement examples? https://matthewdeeprose.github.io/amazing.html 307 kent.ac.uk have 35 accessibility statements for their service

Slide 308

Slide 308 text

Want to find good Accessibility Statement examples? 2 https://matthewdeeprose.github.io/amazing.html 308 Kent also has a statement written by their DVC Education and Student Experience asking staff and students to “help the University meet accessibility standards”.

Slide 309

Slide 309 text

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

Slide 310

Slide 310 text

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

Slide 311

Slide 311 text

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

Slide 312

Slide 312 text

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

Slide 313

Slide 313 text

What does an ACR / VPAT look like? 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. https://matthewdeeprose.github.io/amazing.html 313

Slide 314

Slide 314 text

A useful poster https://matthewdeeprose.github.io/amazing.html 314 Hassel Inclusion Poster (PDF)

Slide 315

Slide 315 text

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

Slide 316

Slide 316 text

Technical Architecture Group Non Functional Requirement for Cloud-based services 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 https://matthewdeeprose.github.io/amazing.html 316

Slide 317

Slide 317 text

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)

Slide 318

Slide 318 text

Shifting left through the process (9) Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 318 • Publish Accessibility statement as part of go-live checklist. • Accessibility testing as part of Change Management. • Dashboards. • Review accessibility statements annually. Shift left

Slide 319

Slide 319 text

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

Slide 320

Slide 320 text

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

Slide 321

Slide 321 text

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

Slide 322

Slide 322 text

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

Slide 323

Slide 323 text

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

Slide 324

Slide 324 text

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

Slide 325

Slide 325 text

Accessibility Dashboards https://matthewdeeprose.github.io/amazing.html 325

Slide 326

Slide 326 text

Accessibility Dashboards (1) • Monitoring Web Accessibility Compliance With Pa11y Dashboard • Setting up an Accessibility Dashboard from Scratch with Pa11y • A11ygato – accessibility dashboard for website monitoring https://matthewdeeprose.github.io/amazing.html 326

Slide 327

Slide 327 text

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

Slide 328

Slide 328 text

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

Slide 329

Slide 329 text

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

Slide 330

Slide 330 text

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

Slide 331

Slide 331 text

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.

Slide 332

Slide 332 text

iSolutions ambitions https://matthewdeeprose.github.io/amazing.html 332 A The bare minimum. AA Required by law. AAA iSolutions delivering amazing accessibility.

Slide 333

Slide 333 text

Recommended Practices https://matthewdeeprose.github.io/amazing.html 333 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

Slide 334

Slide 334 text

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

Slide 335

Slide 335 text

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

Slide 336

Slide 336 text

Shifting left through the process (11) Requirements Design Build Test Release https://matthewdeeprose.github.io/amazing.html 336 “Make sure it’s accessible” “Only release when it’s accessible” Shift left “Test that it’s accessible.” Use whatever techniques you prefer.

Slide 337

Slide 337 text

So what do we do now? https://matthewdeeprose.github.io/amazing.html 337

Slide 338

Slide 338 text

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.

Slide 339

Slide 339 text

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.

Slide 340

Slide 340 text

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

Slide 341

Slide 341 text

Learning more: mailing lists and teams JISC Accessibility Mailing List JISC Accessibility Community Access Technology Higher Education Network Mailing List WebAim Mailing List 341 https://matthewdeeprose.github.io/amazing.html

Slide 342

Slide 342 text

Want to learn more? https://matthewdeeprose.github.io/amazing.html 342

Slide 343

Slide 343 text

Learning more http://bit.ly/10-days-of-a11y https://dwcag.org/#sign-up-section https://matthewdeeprose.github.io/amazing.html 343

Slide 344

Slide 344 text

Blind Onion Tweet https://matthewdeeprose.github.io/amazing.html 344

Slide 345

Slide 345 text

GAAD Pledge https://matthewdeeprose.github.io/amazing.html 345

Slide 346

Slide 346 text

A wave of momentum toward accessibility https://matthewdeeprose.github.io/amazing.html 346

Slide 347

Slide 347 text

A wave of momentum toward accessibility (2) 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 https://matthewdeeprose.github.io/amazing.html 347

Slide 348

Slide 348 text

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.

Slide 349

Slide 349 text

SWOT analysis •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 https://matthewdeeprose.github.io/amazing.html 349