The key to agile accessibility: Effective measurement of what matters

Discover which accessibility KPIs your team should be tracking for a more effective and agile approach to digital accessibility.

Agile accessibility is the incorporation of accessibility principles and practices into the agile software development methodology.

Ensuring accessibility is an a constant and iterative process throughout the development cycle meaning making sure that software and web applications are designed and developed with accessibility in mind from the very beginning.

Tracking accessibility KPIs is a critical step in ensuring that your digital products are accessible to all users.

Why should you track the performance of your agile accessibility efforts?

Tracking the performance of your agile accessibility efforts is essential for measuring the quality, progress, and value of your accessibility development process. It helps to identify issues and bottlenecks, improve performance, and align your team with accessibility’s expectations.

Agile digital accessibility involves incorporating accessibility requirements into user stories, conducting iterative testing, and ensuring that accessibility is part of the development team’s definition of done.

Teams can ensure that accessibility is considered throughout the development lifecycle and that digital products are accessible to everyone by including accessibility into the agile development process.

What should you track to see if your agile approach to accessibility is effective?

Here are some key performance indicators (KPIs) that your team may monitor to guarantee an effective and agile approach to digital accessibility.

• Accessibility Audit Score: This KPI measures your website’s or application’s overall accessibility. It is determined by performing an automatic accessibility audit as well as manual testing. The score ranges from 0 to 100, with higher numbers suggesting more accessibility.
• Accessibility Bugs: This KPI measures the amount of bugs in your website or application that affect accessibility. Accessibility bugs are issues that prevent disabled users from accessing your content. Monitoring this KPI might assist you in identifying areas of your website or application that need improvement. The number of bugs determines the impact on the software development velocity. More bugs also mean more time spent fixing them.
• Accessibility Compliance: This KPI measures compliance with accessibility standards like WCAG 2.2. Compliance may be measured using both automated and manual technologies. Monitoring this KPI might assist you in ensuring that your website or application satisfies the required accessibility standards.
• Accessibility Training: This KPI measures how many team members have attended accessibility training. Accessibility training can help with ensuring your team is aware of the value of accessibility and has the skills needed to build accessible digital products.
• Accessibility User Testing: This KPI measures the number of users with disabilities who have tested the accessibility of your website or application. User testing may assist you in identifying areas of your website or application that require improvement and ensuring that your digital products are accessible to everybody.

Organizations may more successfully and efficiently accomplish their goals by implementing accessibility into all phases of the digital experience lifecycle, from design to development and quality assurance, by using an agile approach to accessibility. By using a proactive approach, it is possible to avoid the expensive and time-consuming process of fixing accessibility concerns in fully developed digital experiences, saving time, money, and energy.

What are some common myths about accessibility in agile development?

Common myths about accessibility in agile development include:

• Automated accessibility tests only cover 25% – 35% of the WCAG Success Criteria. This type of statement is a bit misleading, because not every WCAG Success Criteria is applicable to every case. So it may be that 50% of the WCAG Success Criteria are inapplicable to your case. In this case, you may find that the automated tests cover, e.g., 85% of the WCAG Success Criteria, which are applicable to your case.
• People with disabilities don’t use computers. That’s not the case. Even groups that previously couldn’t access information may now engage more completely with digital content and functionality because to innovations in assistive technology and web development.
• Accessibility only benefits blind people. Making websites accessible to as many people as possible, including those with vision, hearing, mobility, cognitive, and other disabilities, is the goal of the Web Content Accessibility Guidelines (WCAG). Enhancing usability for one group frequently improves usability for everyone.
• Only developers need to worry about accessibility. Digital accessibility is something that every employee of a company, from designers and content producers to project managers, can affect or should be aware of. Enhancing accessibility within an organization’s culture leads to increased efficiency and compliance.
• Accessibility is a cost with no benefit. Accessibility is seen as a cost because it is unknown territory, which is where the popular view of it as a cost comes from. In fact, knowing digital accessibility and having practical experience in its implementation, it turns out that it practically does not affect software development efficiency at all. Moreover, thanks to, for example, testing with a screen reader, you discover many things that may not be visible at first glance. For example, the content may not make sense in context to what we see.
• An accessible website is boring or ugly. This is not true. Accessible websites frequently have slick, eye-catching designs. Making something accessible does not imply removing its attractiveness; rather, it refers to making sure that a large number of individuals can access it. We can find ourselves in a situation in life when we suddenly need some functionality and only then we complain that something is not designed as we expect.
• Automated testing is enough to be compliant. Automated tests alone are not enough, as there are technological limitations that make it impossible to test every scenario. That’s why manual testing is needed. For example, to describe an image. However, automated testing allows for consistent, repeatable testing, ensuring that you will have a tested solution to some extent every time.
• Accessibility is one-time job. No, it is not a one-time job. This is a process that is part of the software development process.
• Digital Accessibility is only relevant for people with disabilities. This is one of the most popular myths. For example, we often complain that the application does not work when we want to navigate through the application using only the keyboard. In fact, everything that is happening in the field of accessibility affects us every day.
• Digital accessibility is too complicated, and technical. Accessibility guidelines and tools are available to make digital accessibility simple and easy to understand. Developers can integrate digital accessibility into existing design and software development pipeline. Employing companies or people experienced in accessibility greatly facilitates the implementation of digital accessibility.
• Digital accessibility is just a checkbox to meet legal requirements. Although companies may prioritize digital accessibility due to regulatory obligations, accessibility is more than just compliance with the law. It all comes down to making the web more accessible for all users, boosting an organization’s standing, and improving user satisfaction overall. In fact, by making the product fully digitally available, we open the door to a larger group of potential customers. The statement that disabled people are not my target group disappears when we find ourselves in such a situation.