Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Toward amazing accessibility!

Toward amazing accessibility!

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

matthewdeeprose

November 09, 2021
Tweet

More Decks by matthewdeeprose

Other Decks in Education

Transcript

  1. Towards amazing accessibility! Introduction to accessibility testing and “shifting left”

    to operationalise amazing accessibility throughout the development life cycle. https://matthewdeeprose.github.io/amazing.html 1
  2. 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
  3. 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!
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. COVID guidance page 3 INC1847426 raised 13 March 2020. No

    response to user. https://matthewdeeprose.github.io/amazing.html 31 iSolutions real world example
  22. COVID guidance page 4 More than 12 months later, no

    activity within ticket. https://matthewdeeprose.github.io/amazing.html 32 iSolutions real world example
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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.
  34. 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
  35. 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
  36. 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!
  37. 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.”
  38. 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.
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. 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
  45. Maximise the potential of the University’s digital estate for all

    stakeholders. https://matthewdeeprose.github.io/amazing.html 58 Microsoft Design
  46. 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
  47. 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
  48. Occupational Health Most common issues related to IT are: Vision

    https://matthewdeeprose.github.io/amazing.html 62
  49. 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
  50. 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
  51. 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
  52. What does the strategy say? “[enable] the exploitation of digital

    technology by the University” https://matthewdeeprose.github.io/amazing.html 66
  53. 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
  54. 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.
  55. 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
  56. 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.
  57. 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
  58. What does the strategy say? (2) “We will: • Get

    the basics right •Continually [improve] our services” https://matthewdeeprose.github.io/amazing.html 73
  59. 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.
  60. 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
  61. 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
  62. 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
  63. 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
  64. Multimedia Development Team Lead / Multimedia Developer “Knowledge of accessibility

    issues relating to multimedia design.” Person Specification - Desirable https://matthewdeeprose.github.io/amazing.html 79
  65. Expertise in digital accessibility will be required by companies who

    do business around the world. https://matthewdeeprose.github.io/amazing.html 80
  66. 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/
  67. 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
  68. 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
  69. 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
  70. 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.
  71. 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
  72. 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
  73. 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.
  74. 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
  75. 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
  76. 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
  77. 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
  78. 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
  79. 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
  80. 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
  81. 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
  82. 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
  83. 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
  84. 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.
  85. 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
  86. 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
  87. 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
  88. Case study: what does a professional accessibility audit look like?

    https://matthewdeeprose.github.io/amazing.html 103
  89. 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
  90. 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
  91. 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
  92. 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
  93. 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
  94. 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
  95. 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
  96. 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
  97. 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
  98. CDDO 2 • How do automated accessibility checkers compare? •

    Deep dive comparison • Example inaccessible web page. https://matthewdeeprose.github.io/amazing.html 113
  99. 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
  100. 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
  101. Lighthouse Lighthouse •Built into Chrome •Accessible from within Dev Tools.

    •Uses axecore. https://matthewdeeprose.github.io/amazing.html 119
  102. 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
  103. 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.
  104. 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
  105. 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
  106. 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
  107. 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
  108. 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
  109. 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
  110. 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
  111. 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
  112. 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
  113. 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
  114. 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
  115. 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
  116. 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
  117. 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
  118. 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
  119. What automated tests won’t find .ext-webkit *:focus { outline: none

    !important; } https://matthewdeeprose.github.io/amazing.html 166 <a href="PGR_Induction_StartofYear_2 021.pptx">Click Here</a> $(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
  120. 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
  121. 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
  122. 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
  123. 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
  124. 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
  125. 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
  126. 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.
  127. 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
  128. Text spacing? Avoid overlaps, and horizontal / vertical cut offs.

    Understanding Success Criterion 1.4.12: Text Spacing https://matthewdeeprose.github.io/amazing.html 177
  129. 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
  130. 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
  131. 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
  132. 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
  133. 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
  134. 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
  135. 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
  136. 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
  137. 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
  138. 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
  139. 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
  140. 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
  141. 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
  142. 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
  143. 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/
  144. 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
  145. 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
  146. 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
  147. 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
  148. 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.
  149. 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
  150. 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/
  151. 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/
  152. 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/
  153. 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/
  154. 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
  155. 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
  156. 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
  157. 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
  158. 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
  159. 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
  160. 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
  161. 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
  162. 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
  163. 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
  164. Accessibility Insights C https://accessibilityinsights.io/ • Report can be exported to

    an HTML file. https://matthewdeeprose.github.io/amazing.html 230
  165. 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.
  166. 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
  167. 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
  168. 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
  169. 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
  170. 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
  171. 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
  172. 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.
  173. 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
  174. 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
  175. 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
  176. 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
  177. 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
  178. 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
  179. 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
  180. 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
  181. Source Control Axe Linter analyses changed or added code of

    pull requests, reports issues https://matthewdeeprose.github.io/amazing.html 251
  182. Source Control (2) Automatically requests changes to resolve common issues.

    https://matthewdeeprose.github.io/amazing.html 252
  183. 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
  184. 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
  185. 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
  186. 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
  187. 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
  188. 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
  189. 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
  190. OneWeb 5 The OneWeb Team has done some excellent work

    on involving users within the design process. https://matthewdeeprose.github.io/amazing.html 268
  191. 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
  192. 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
  193. 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
  194. 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
  195. 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
  196. 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
  197. 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
  198. How can we ensure accessibility is considered from the beginning?

    https://matthewdeeprose.github.io/amazing.html 276
  199. 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
  200. 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.
  201. 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.
  202. 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.
  203. 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.
  204. 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
  205. Note PSBAR = Public Sector Bodies (Websites and Mobile Applications)

    (No. 2) Accessibility Regulations 2018 https://matthewdeeprose.github.io/amazing.html 284
  206. 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.
  207. 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.
  208. 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”
  209. 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”
  210. 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
  211. 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”
  212. 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”
  213. 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”
  214. 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.
  215. 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.
  216. 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
  217. 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.
  218. 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
  219. 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
  220. 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
  221. 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
  222. 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
  223. Accessibility Statement 8 Should be based on a template provided

    by CDDO. https://matthewdeeprose.github.io/amazing.html 303
  224. 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
  225. 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
  226. 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
  227. 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”.
  228. 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
  229. 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
  230. 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
  231. 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
  232. 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
  233. 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
  234. 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)
  235. 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
  236. 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
  237. 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
  238. 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
  239. 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
  240. 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
  241. 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
  242. 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
  243. 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
  244. 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
  245. 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
  246. 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
  247. 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.
  248. 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
  249. 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
  250. 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
  251. 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.
  252. 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.
  253. 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.
  254. 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
  255. 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
  256. 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
  257. 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.
  258. 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