Digital product management is a balancing act between meeting the needs of users and navigating pressure to deliver new features on time and on budget. Digital accessibility spans across this divide. To serve the broadest possible user base and maximize revenue, product teams need to prioritize accessibility. But too often, product teams only address accessibility after new features are built. This reactive approach takes more effort, drains development hours, and delays features for all users.
Here’s the good news: there’s a much more sustainable approach to digital accessibility that will save your team time and resources. By taking an agile approach to accessibility—that is, proactively embedding it in the existing agile life cycle for your product—you can drastically reduce the number of bugs caught in regression, accelerating time-to-market for releases and driving down development costs.
In this post, we’ll provide practical tips for product leaders to align accessibility with the development and release of new features, improving the efficiency and predictability of processes and expanding the market for your product.
Four steps to embed accessibility in your agile life cycle
Most product teams today rely on agile methodologies like scrum to build user-centric products. Agile accessibility draws on key principles of these philosophies, inviting teams to address accessibility early, often, and iteratively throughout the software development life cycle (SDLC). As a result, this approach aligns well with agile teams’ existing workflows. Let’s explore four best practices for proactively incorporating accessibility into your sprints.
1. Advocate for embedding accessibility in your definition of “done”
Building accessibility testing and documentation into your Definition of Done (DoD) for all new components and features is one of the simplest and most impactful steps you can take to maintain a consistent level of accessibility across your digital experiences. Of course, most agile teams align on DoD together—so you’ll want to ensure all product managers and engineers are aligned on why accessibility is essential to your product’s success. (If coming to this agreement takes time, individual product leaders can still make meaningful progress by taking the next three actions covered in this section.)
Once your team agrees to include accessibility requirements in your DoD, it’s time to define these requirements. For example, you’ll need to determine which version and level of the Web Content Accessibility Guidelines (WCAG) your product needs to meet, and when in the SDLC you’ll test for conformance with these standards. As a best practice, organizations should aim for Level AA conformance with the most recent version of WCAG and incorporate automated accessibility testing in development as well as in QA.
2. Make accessibility part of the acceptance criteria for user stories
When creating the acceptance criteria for user stories, teams need to consider diverse use cases. For example, not all people navigate digital experiences with a mouse, so stories should account for how users of keyboard-only navigation and assistive technology (e.g., screen readers, dictation software) will perform tasks.
To reduce accessibility bugs in development (and prevent costly delays), ensure that accessibility-related acceptance criteria are written before designs are passed off to development. Because UX teams often have the best understanding of how users should interact with a digital experience, it’s smart to hold designers accountable for drafting accessibility requirements. Then, product managers should check their work to ensure these criteria reflect the full range of possible use cases.
Once accessibility is embedded in the design and development of user stories, you can improve the agility of your QA process by encouraging QA analysts to test individual stories for accessibility, rather than waiting to test entire features.
3. Set sprint goals that reinforce the importance of accessibility
To keep accessibility top-of-mind for your team, set sprint goals directly related to digital accessibility. For example, you might set a goal that no new accessibility bugs will be introduced during your sprint cycle, or that every developer will test their code for accessibility—and proactively fix flagged issues—prior to submitting it to QA. While these goals should align with work that your team is already doing, rather than introduce new objectives, they can help to keep the team focused on accessibility and its importance throughout the agile life cycle.
4. Treat issues that emerge as opportunities for iteration
No process is perfect, and even with a proactive, agile approach to accessibility, some new bugs will likely slip through the cracks. It’s crucial to recognize, and communicate, that everyone on the software team is learning to improve the accessibility of their work. As a leader, frame these mistakes as opportunities to reinforce your team’s knowledge and processes, and equip team members with additional education or tooling to prevent the same bugs from emerging in the future. For instance, if your team consistently struggles to make radio buttons accessible to keyboard navigation users, you might schedule a team-wide training session focused on best practices for form accessibility.
Some of the roadblocks that your team faces might not stem from gaps in tooling and technical training. Often, product leaders also need to take a proactive role in changing the culture around accessibility at their organization. It’s important to be sensitive to misunderstandings that may be holding your team back, and work to gradually improve awareness and empathy through ongoing education.
Start where you are
There’s no one-size-fits-all approach to incorporating accessibility into your agile life cycle. And as you weave accessibility into your sprints, you’ll need to apply the best practices outlined above in a way that aligns with the maturity of your existing SDLC.
If your SDLC is still unpredictable, which is common at start-ups, establishing team-wide processes around inclusion may feel challenging. But it’s never too early (or too late) to ensure your product works for the widest possible audience. You can make it easier for individuals to address accessibility by:
- Using plug-ins and browser extensions to integrate accessibility into your existing processes for testing code in development and QA
- Investing in role-specific accessibility training for team members
If your organization’s SDLC is more mature, you can take a more comprehensive approach. Build accessibility checkpoints into every stage of the SDLC, starting with ideation. These might include:
- Including people with disabilities in your focus groups for UX research
- Enlisting a third-party accessibility expert to review all new designs
- Setting up quality gates to ensure developers are effectively addressing issues prior to QA
- Investing in an accessible design system
Streamline accessibility and innovation with a trusted partner
No matter the scale and structure of your SDLC, with the right tools and support, you can adopt a faster, smarter approach to accessibility—better serving both your users and your organization.
Level Access’ suite of digital accessibility solutions equips software teams with the tooling, training, and guidance needed to tackle accessibility early, often, and iteratively throughout the SDLC. Our automated testing tools enable developers and QA teams to test code in any environment—pre-production, staging, or live—to proactively identify and fix accessibility issues. Plus, our experts will provide detailed accessibility feedback on new designs through our Design Evaluations, helping you address potential barriers before features are in development.
And to help you ensure long-term success, we’ll educate and upskill every member of your team through live and self-paced role-specific training and offer strategic support with prioritization. If you’re ready to make the shift to more sustainable and effective accessibility, engage with our team today.
eSSENTIAL Accessibility has changed its name to Level Access! Read More