Why introduce Accessibility checks to SDLC?

We all agree that Accessibility is important, but without embedding regular checks into your company culture and processes, you run the risk of handling any identified Accessibility issues in a  "fire fighting" manner.

In the course of doing Accessibility audits, I find most issues could have been easily avoided, with some checks added to the SDLC (Software Development Life Cycle). Checks can be applied at each phase of design and development, and will not add much effort or time. 

One of the benefits of adding more checks to the SDLC, is that more testing-time can be invested in covering how accessible the user experience (UX) of an app is while still under test, rather than fire-fighting UI issues. Running into these numerous minor (and avoidable) issues can make testing an app for Accessibility very time consuming. 

So how to build a culture of accessibility checking to make the process of accessibility testing seamless?

1) Strategise

Firstly, define Accessibility goals and requirements. This includes understanding legal obligations and setting clear objectives for compliance with w3c WCAG guidelines. It is worth it to write a company Accessibility strategy, so that your aims and goals are clear.

Assess existing systems and content for Accessibility issues to identify areas needing improvement, and generate an Accessibility Statement. This can be done by requesting an audit from a third-party (generally recommended).

Include users with disabilities in your process to gather insights and requirements (surprisingly few do). Their feedback will be invaluable, as they have real world experience with assistive software and devices. From those discussions, you can start creating personas and user stories that reflect behavior expected from the app.

2) Employ good UI/UX Design Principles

Apply inclusive design principles following the WCAG POUR (Perceivable, Operable, Understandable, and Robust) principles, to create wireframes and prototypes. Read our previous blog for a more indepth view. Ensure that design elements such as color contrast, font sizes, and navigation structures are accessible. Most design tools have checking features for these areas. Or run a simple tool that will scan your design to pick up on sizing and color contrast.

Design, buttons, and other interactive elements can be easily made accessible by all users, including those relying on assistive technologies. There are many guides on the web to coding accessible HTML. No excuses!

3) Embed Accessibility good practices into development 

Use semantic UI code to ensure that content is structured in a way that is easily interpretable by screen readers and other assistive technologies. Implement ARIA roles and attributes to enhance the Accessibility of dynamic content, and ensure ALL elements on screen are uniquely labeled. Ensure that all functionality is accessible via keyboard, providing logical tab order and focus indicators.

Tools like Axe, Pa11y, WAVE, and Lighthouse help identify Accessibility issues early in the development process. Encourage your team to use these - they work!

4) Testing

In the testing phase, this is where you can be more focused on UX and user journeys through the app. There are ways to add Accessibility checks to UI Test frameworks, such as Playwright, Jest, Espresso and XCUTest. They all have plugins to run Accessibility checks of various kinds - from low level code checks to screen reader tests.

Test with assistive technologies such as screen readers (e.g., VoiceOver or NVDA), and voice recognition software. If possible, involve users with disabilities in usability testing to identify practical issues and gather feedback.

5) Deployment

Provide an Accessibility statement that outlines the Accessibility features of the product and offers contact information for reporting issues. Monitor Accessibility post-deployment to ensure ongoing compliance and address new issues as they arise. 

Keep your Accessibility statement updated - and avoid users finding issues that they could have known about to start with. No-one expects perfection on websites and mobile apps, but finding bugs is a common frustration for users.

6) Maintenance

With Accessibility checks integrated into your SDLC, your maintenance phase will be easier. Your checks are in place, ready for when any possible changes. You should continue to perform regular Accessibility audits to ensure that updates and new features continue to meet Accessibility standards, then update your Accessibility statement to match.  Provide channels for easy feedback from users with disabilities to continuously improve and stay on the cutting-edge of accessibility. 

Accessibility and DTAC

Embodying the good practices within this article will count a long way to helping you achieve a top score in the accessibility section of DTAC. For more information on accessibility for DTAC, have   look at our previous blog: Accessibility Matters: What You Need to Know

And remember, the DTAC Squirrel is here to help you understand what you need to do to become DTAC compliant! Check out our Squirrel plans and get started today!

Written by Paul Littlebury

Further resources

• Web Content Accessibility Guidelines (WCAG 2.2):  https://www.w3.org/TR/WCAG22/
• Apple's Accessibility Guidelines: https://developer.apple.com/design/human-interface-guidelines/accessibility
• Android's Accessibility Guidelines: https://developer.android.com/guide/topics/ui/accessibility
• Guides for developing accessible websites: https://webaim.org/articles/