In the Digital Learning Team, we have spent the last few months studying for the BCS Foundation Certificate in Agile. This covers topics such as:
- What is Agile?
- What is Agile working?
- How can I embed Agile into my organisation?
There is a common misconception that Digital Accessibility slows down and impedes IT development processes, making them less agile. In this post we cover six aspects we learned in our Agile training course and how they relate to accessibility.
- Simplicity – the art of maximizing the amount of work not done – is essential
- Pair programming
- Behaviour Driven Development
- Continuous integration and test automation
- Definition of Done
- Conclusion
Agile Principle: Simplicity – the art of maximizing the amount of work not done – is essential
Of the Twelve Agile Principles, maximising the amount of work not done is likely to be a welcome and attractive concept to most colleagues. It also maps to what we learn from Lean Six Sigma about reducing waste and maximising the value of our work. Agile tells us we should aim to do the minimum necessary to satisfy requirements in full. We increase efficiency and throughput by avoiding “gold plating”.
There is simple and elegant way that digital accessibility maps to this principle, Semantic HTML. As is often the case, there is a meme that can explain this in four panels.
A simple demonstration of the benefit of using semantic HTML is comparing a button set up using a div or using the button tag. If you make a button using a div, you would have to add additional JavaScript for keydown events to ensure it will be accessible for those who do not use a mouse.
Using Semantic HTML will almost always produce results with accessibility “baked in”. These elements will work correctly with keyboards, mice, switch devices, and screen readers, among other assistive technologies.
Want to learn more?
- Just use button — A11ycasts #05 7 Minute video (YouTube).
- What On Earth Is Semantic Markup? (And Why Should You Learn To Write It)
- The right tag for the job: why you should use semantic HTML
Agile Practice: Pair programming
Pair programming is an agile practice where two programmers, sometimes a more senior colleague with a newer colleague, work together on one computer. A great example of pair programming in the context of accessibility is in this tweet from Mark Streadman, Customer Success Engineer at Deque Systems.
Agile Practice: Behaviour Driven Development
Behaviour-driven development (BDD) is an Agile methodology where we document and design a deliverable around the behaviour a user anticipates. A method often used for this is Gherkin. Gherkin is a business readable language which helps to describe business behaviour without going into technical implementation details.
In his presentation Agile Accessibility Requirements at Scale [49 Minute YouTube video], Ben Allen talks about how he created a library of Gherkin tests that his team uses as prompts for checking that deliverables are accessible. Here is an example.
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)
Want to learn more?
Using Gherkin to Write Accessibility Tests
Agile Practices: Continuous integration and test automation
Continuous integration (CI) is when code changes from multiple authors are integrated within a software project. Automated testing is when automated tools execute software tests.
Digital Accessibility has a part to play here too. A number of services are available that can provide Github actions whereby commits or pull requests are automatically checked for accessibility issues as part of integration workflow. Some will even automatically suggest fixes to identified issues.
A wide range of automated accessibility tests can be integrated within tools such as Selenium or run via command line. Automated tests will not prove that a service meets accessibility guidelines in full, but they do allow us to pick the “low-hanging fruit” of accessibility defects that we can detect automatically.
Want to learn more?
- Automated accessibility testing: Leveraging GitHub Actions and pa11y-ci with axe
- Automating Your Accessibility Tests
- Automated Accessibility Testing in JavaScript Frameworks [1 hour YouTube video]
Agile Practice: Definition of Done
The Definition of Done (DoD) is where we agree that we have met all acceptance criteria and the customer is ready to accept the delivery of a “potentially shippable product increment”. At a minimum, conformance with Accessibility Guidelines should be part of the Definition of Done for all user stories.
Want to learn more?
Conclusion
Agile practices are easily aligned with digital accessibility. Ensuring our work is digitally accessible need not be seen as a hinderance or barrier. The best way to ensure our work is accessible is through embedding accessibility within our agile processes and through considering accessibility at all stages of a product lifecycle.
The Agile Accessibility Handbook is an excellent free resource that offers practical guidance on accessible development at scale.
Can you identify more ways that agile practices map to digital accessibility? Let us know in the comments.
Further reading
- UX in Agile: How to Ensure UX and Agile Work Successfully Together
- Integration of Web Accessibility into Agile Methods
- Accounting for User Research in Agile