Talk: How to Approach Accessibility Testing within an Agile Scrum Team
Speakers directory
Speaker:
David Brownhill
Talk description
Title:
How to Approach Accessibility Testing within an Agile Scrum Team
Short synopsis:
My current project is a Digital Programme which must therefore comply with a set of both functional and non-functional standards and regulations defined by the Government Digital Service ( GDS ). I will explain how a set of cross-functional agile engineering teams working 2-week SCRUM sprints planned for, tested and fixed accessibility issues with our published content and services in addition to engaging with our users.
Max size: 500 chars
Long synopsis (optional):
A number of feature specific non-functional requirements are set that apply to accessibility. At a minimum it was necessary that WCAG level AA and the four main principles - perceivable, operable, understandable and robust - were all met. Compliance with the Public Sector Bodies ( Websites and Mobile Applications ) Accessibility Regulations 2018 is also required in addition to publishing a website accessibility statement. The talk will focus on explaining how we ensured that our engineered solution met all these regulations and how the Government Digital Service ( GDS ) supported us. During a three amigos meeting each story within the upcoming sprint is reviewed regards how testing will be approached. This will include assessing whether there is a requirement for a non-functional test approach and what actions will be required as part of this strategy. Any new or modified front-end affecting code will be tested in sprint using recommended tooling. In our case this was WAVE - a Chrome extension. Manual accessibility testing working against a prescribed checklist helps cover the shortfall from relying solely upon tooling. All defects are raised within JIRA with accessibility errors labelled as <sortsite>, <manual>, <wave> or <assitiveTech>. This enables accessibility specific problems to be directed to our accessibility dashboard and filtered according to these four labels. The priority for the project is for all A and AA defects on SortSite to be addressed. WAVE will report errors in addition to alerting upon HTML and ARIA features but it is the responsibility of the engineer to assess whether these are additional errors. Prior to a major release we ensure that assistive technology test coverage is adequate. A checklist will act as a guide to our agile testers and will cover aspects such as (1) content is read in order (2) we have IMG alternatives (3) text is pronounced correctly At end of each SCRUM sprint the Test Lead will run SortSite which is a tool that scans applications and reports on issues regarding accessibility, browser compatibility, usability and web compliance. These defects will then be reviewed by a tester and web designer / developer with JIRA issues raised where appropriate. There is no substitute for testing with real users and we provide the opportunity for testers to sit with UX analysts and end-users with a full range of disabilities such that we can see how our solutions are being engaged with in reality. These insights will then feedback into how we engineer future iterative releases.
Max size: 5000 chars
Tags:
Speaker directory:
Listed in directory
Not listed
Speakers directory