Accessibility Built-In, Not Bolted On

In today's digital age, accessibility has become a crucial aspect of software development. Designing websites, applications and digital products that can be used by as many people as possible, including people with disabilities, is not only a legal requirement but also a moral imperative.

But accessibility is frequently treated as an afterthought, a box-ticking compliance exercise to avoid legal issues, and that’s if it’s even thought about at all. In this blog post, we will explore the importance of building accessibility into the software development lifecycle and discuss practical steps to achieve it.

Too often, accessibility is something that’s left to the end of the product life cycle, sometimes even post-release. This approach has significant drawbacks:

Retrofitting accessibility features into a product that has already been developed can be time-consuming and costly, due to long feedback loops. It may involve revisiting code, redesigning elements and retesting functionality. The additional effort and resources required can impact project timelines and budgets.

Accessibility fixes implemented at the end may not consider the overall user experience, resulting in solutions that feel disjointed and disconnected from the product's design and flow.

Approaching accessibility as an afterthought hampers the potential for innovation. Embracing accessibility constraints can spur creative solutions that enhance the user experience for everyone. By deferring accessibility, organisations miss out on these opportunities.

Addressing accessibility issues as a rushed, last-minute effort often leads to superficial fixes without understanding the underlying principles. This approach fails to provide the necessary education and awareness for teams to incorporate accessibility effectively, leading to recurring issues in subsequent releases and projects.

If we shift the traditional approach and think about accessibility earlier in the software development lifecycle, we can deliver solutions that are more elegant, robust and accessible by default. This approach is often called ‘shift-left’, and it requires us to make smaller, more frequent investments in accessibility.

We should start thinking about accessibility as early as possible in a project lifecycle. The discovery and requirements-gathering phase of a project is an excellent place to start considering accessibility.

Personas are fictional representations of typical users. They’re often used in user experience (UX) design and serve as a guide for creating experiences that resonate with the target audience.

By ensuring these personas are inclusive and reflect a diverse range of abilities, including various disabilities, we gain valuable insights into the challenges and requirements of different user groups. It allows us to spot potential barriers early and come up with elegant solutions that benefit everyone.

Microsoft approaches this by using persona spectrums . This is a flexible, realistic approach that caters for the fact that any person could have a disability at a point in time, whether that be permanent, temporary or situational.

Identify target user groups, their specific needs and any accessibility standards or regulations that apply to your project. The laws and regulations vary from country to country and from private to public sector, make sure you know what these regulations are before getting started.

Educate your team about the importance of accessibility and its impact on user experience. Create awareness within the team and use role-based accessibility guidelines and best practices, ensuring that all team members understand the benefits and requirements of inclusive design.

It’s best to prioritise literacy over expertise, Not everybody has to be an expert, but they should have a good understanding of what’s relevant to their own role. The Accessibility Roles and Responsibilities Matrix (ARRM) project is an initiative to help digital teams assign responsibility for certain accessibility tasks to different roles. The ARRM project is a good reference point for designers, developers and other roles to work out which areas they should focus on upskilling.

Hire your own accessibility specialists  and involve them in the discovery process. Their knowledge can help identify potential accessibility barriers and guide appropriate solutions.

Include users with disabilities in your user testing  and feedback sessions during the discovery phase. Get invaluable first-hand insights and validate the accessibility of your concepts and prototypes, enabling early identification and resolution of potential issues.

A recent case study conducted by Deque , a leading accessibility company, revealed that approximately 67% of accessibility issues can be traced back to the design phase. This highlights the critical importance of considering accessibility from the very beginning of the design process. To integrate accessibility into the design phase, there are a few things we can do:

While a range of accessibility experience decisions can be made during design, many of those are not normally visible in prototypes. Annotations are a way of documenting those decisions inside prototypes, so that the information is available to developers and other members of the team. This includes adding descriptive alt text to images, specifying meaningful labels for form fields and buttons, structuring content using proper heading hierarchy, or specifying focus order like in the following screenshot:

These annotations serve as a bridge between the design and development phases — designers can collaborate with developers to annotate designs that help guide the desired accessible features and interactions.

There are annotation kits available for most of the popular design tools that can help bring consistency to annotations. A great example of these kits is the A11y Annotation Kit for Figma .

Where possible, solve the problem once at the lowest level and reuse these patterns across your designs. Keep in mind that this is not a silver bullet, new problems can arise when components are used and combined within different contexts.

Accessibility plugins can be a great addition to a designer’s workflow. For example, Stark  provides checks and guidance for things like colour contrast, vision simulation, focus order and alternative text. By leveraging these tools, designers can more efficiently consider and address accessibility concerns.

Accessibility is a team sport, and designers shouldn’t be expected to know everything. By involving accessibility specialists during the design phase, designers can benefit from their insights and recommendations to ensure that accessibility considerations are appropriately addressed and knowledge is shared.

Specialists can identify potential barriers, offer alternative solutions and provide guidance on best practices for creating an inclusive user experience. The earlier accessibility issues are discovered the easier they are to fix. It means that catching issues at this phase is much cheaper than waiting until the designs have been developed, as the feedback loop is much shorter.

It can be a useful knowledge-sharing and educational exercise to make these reviews collaborative. A regular sync between design, development and an accessibility specialist is a great way to increase the overall knowledge of accessibility in the team.

It’s crucial to integrate accessibility into the development phase of a project. This should be a consideration for every feature we build, with a combination of manual and automated testing.

While manual testing plays a crucial role in ensuring the accessibility of our website or application, automation can greatly assist in handling repetitive tasks. Tasks such as testing each state of a page or component for semantic HTML, accurate ARIA attributes and compliant colour contrast ratios can be laborious and time-consuming.

By automating these processes, we can save valuable time that we can repurpose to focus on exploratory testing that relies on human intuition, such as keyboard focus management, screen reader compatibility and the overall user experience when using assistive technology.

Using accessibility testing tools like axe and Wave  can help to identify many accessibility violations in an automated way, which is a huge time-saver.

Axe covers ~30-40% of WCAG 2.1 criteria, but Deque claims that this is more like 60-70% of issues by volume. The tool is open source, powered by the axe-core  engine, and provides detailed reports and suggestions for fixing issues.

This enables developers to make targeted improvements and ensure compliance with accessibility guidelines, whilst learning why the fixes are a necessary part of the process. The axe tool can be used during development in numerous ways, some of which are:

Here is the full list of projects using axe-core .

Automation has come a long way and is improving all the time, but there is always going to be some level of human intervention required to ensure that the product you're making is accessible. This is what you need to do:

Using accessibility tools in Continuous Integration, we can ensure that no detectable accessibility violations end up in production.

Use linters such as eslint-plugin-jsx-a11y  to run accessibility checks against your source code and flag issues and regressions.

Run checkers like axe against your components and pages and block pipelines if new violations are detected. It’s important to check multiple levels — just because a component is accessible in isolation, doesn’t mean it will be in the context of a full page.

You can integrate axe into most modern web testing frameworks fairly seamlessly with a few lines of code. For example, jest-axe can be plugged into a @testing-library/react test in the following way:

Automated checks won't catch everything. We can use end-to-end and component testing frameworks to add additional tests for keyboard mechanics and interactions. Here’s an example Playwright test snippet that uses the Keyboard API  to tab and ensure that the page’s skip link is focused.

By using some of the above techniques and shifting accessibility considerations earlier in the development lifecycle, product teams can:

Overall, ‘shifting left’ with accessibility fosters a proactive and inclusive mindset throughout the development process. It not only helps organisations meet legal requirements but also helps to foster a culture where creating products that are accessible, inclusive and a joy to use for as many users as possible is the default.