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
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.
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.
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.
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.
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.
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.
(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
“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
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
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
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
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
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
the accessibility of the accordion design pattern as implemented in our CMS. https://matthewdeeprose.github.io/amazing.html 37 iSolutions real world example
impact that high quality mark-up can have on performance, accessibility and discoverability.” Person Specification – Essential https://matthewdeeprose.github.io/amazing.html 39
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
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
the requirements to ensure accessibility. It wasn’t part of the release process to assure accessibility. https://matthewdeeprose.github.io/amazing.html 43
the requirements to ensure accessibility. https://matthewdeeprose.github.io/amazing.html 44 It wasn’t part of the release process to assure accessibility.
other barriers we have constructed that may prevent users from fulfilling their ambitions at the University. https://matthewdeeprose.github.io/amazing.html 45
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.”
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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.
the impact that high quality mark-up can have on performance, accessibility and discoverability.” Person Specification – Essential https://matthewdeeprose.github.io/amazing.html 76
“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
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
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/
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
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
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
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.
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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.
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
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
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
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
meaning. 183 https://matthewdeeprose.github.io/amazing.html Ready to submit your final assignment? No Yes Example using simulated Deuteranopia rendering in Google Chrome
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
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
• 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
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
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
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
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
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/
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
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
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/
• 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/
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/
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
to describe business behaviour without going into details of implementation. •Given •When •Then •And, But https://matthewdeeprose.github.io/amazing.html 221
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
at Recurly •creating design systems with baked-in accessibility compliance https://matthewdeeprose.github.io/amazing.html 254 https://www.youtube.com/watch?v=6PHTGHgCQig
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
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
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
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
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
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
• 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
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
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
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
https://matthewdeeprose.github.io/amazing.html 277 • Include accessibility within project documentation. • TAG Non Functional Requirements. • Accessible procurement Shift left
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.
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.
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.
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.
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
the accessibility requirement: “accessibility requirement means the requirement to make a website or mobile application accessible by making it perceivable, operable, understandable and robust”
the accessibility requirement: “accessibility requirement means the requirement to make a website or mobile application accessible by making it perceivable, operable, understandable and robust”
the site. Understandable Readable and predictable. Robust Compatible across devices - even those to come in the future. https://matthewdeeprose.github.io/amazing.html 289
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.
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.
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.
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
other statements •More information about using assistive technology with the site. •Links to other accessibility information. https://matthewdeeprose.github.io/amazing.html 305
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
Kent also has a statement written by their DVC Education and Student Experience asking staff and students to “help the University meet accessibility standards”.
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
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
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
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
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
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
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
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
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
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
Dashboard • Setting up an Accessibility Dashboard from Scratch with Pa11y • A11ygato – accessibility dashboard for website monitoring https://matthewdeeprose.github.io/amazing.html 326
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
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
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
area Responsible Lobbying suppliers on accessibility Product Owner or Service Owner Creating content: Producing accessible documents, web content, presentations, etc. All staff
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
• 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
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.
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
JISC Accessibility Community Access Technology Higher Education Network Mailing List WebAim Mailing List 341 https://matthewdeeprose.github.io/amazing.html
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
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.
•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
matthewdeeprose
robinlee
cm_manaus
signer
irocho
matleenalaakso
uchinomasahiro
obzr
pnuslide
abap34
hachama
mansuy
keithpitt
pedronauck
danielanewman
orderedlist
mza
mojombo
3n
csswizardry
iamctodd
kevinliebholz
jlugia
garrettdimon
![What does the strategy say? “[enable] the exploitation of digital](https://files.speakerdeck.com/presentations/3efb12e98dc8402b9413811c2399e192/slide_65.jpg){kind=link}
