Accessibility Built-In, Not Bolted On

It’s a moral imperative that websites, applications and digital products can be used by as many people as possible

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.

Bolted on: the traditional approach

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:

Increased cost and time

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.

Incoherent experience

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.

Missed opportunities

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.

Lack of education

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.

Built-in: the correct approach

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.

Discovery phase

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.

Inclusive personas

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.

Gather accessibility requirements

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 the team

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.

Involve accessibility specialists

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

User testing

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.

Design phase

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:

Annotate designs with semantics and accessibility decisions

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 .

Use design systems

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.

Use accessibility tools and plugins

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.

Get designs reviewed by an accessibility specialist

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.

Development phase

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.

Automated tools

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:

  1. Browser extension: Integrated into browser dev tools and can be used to scan whole web pages or parts of a web page. There's also a pro version that has guided tests that walk you through how to perform accessibility checks that need human intervention, such as whether image alt text makes sense or if the tab order of a page is logical.
  2. Storybook addon: Many modern projects use Storybook to work on UI libraries and components in isolation. The Storybook addon is a great way to run axe against your components and flag any violations in real-time as you build them.
  3. Google Lighthouse: Lighthouse uses a configured version of axe-core under the hood and is a great way to quickly run an automated accessibility check for a full web page.
  4. Linters: Linters run against your source code and can be used to detect any accessibility violations before the code has even been executed.
Manual testing

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:

  1. Use a checklist: WCAG 2.1 guidelines can be hard to interpret and it's not practical for everybody in the team to become an expert overnight. Checklists are a great way for the team to be able to work through the WCAG guidelines in an actionable way. A good example is the WCAG filter tool.
  2. Ensure keyboard operability: Every interactive element on the page should be reachable and actionable with a keyboard. Take the opportunity to put the mouse down and try to use your product with just a keyboard.
  3. Use the platform: Don't reinvent the wheel. Native elements have accessibility baked in by default. If the UI element looks like a button, use a button HTML element.
  4. Test with screen readers: MacOS, Windows and Linux all have screen readers built-in. Learn how to use them and test your products with them to help find the barriers that some of your users may come across.
  5. Browser extensions: There are many browser extensions that can help to guide, simulate and check for accessibility issues. Some great examples are Accessibility Insights, HeadingsMap, NerdeRegion and Colour Contrast Checker.

Continuous Integration (CI) phase

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

Linters

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

Automated checks

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:

JavaScript
import { render } from '@testing-library/react'
import { axe, toHaveNoViolations } from 'jest-axe'
expect.extend(toHaveNoViolations)

it('should have no detectable accessibility violations', async () => {
  const { container } = render(<App/>)
  const results = await axe(container)

  expect(results).toHaveNoViolations()
})
End-to-end tests

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.

Plain Text
await page.keyboard.press('Tab');
await expect(page.locator('#skip-link')).toBeFocused();

Conclusion

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

  1. Save time and resources: The earlier issues are caught, the cheaper they are to fix. Building accessibility features from the beginning avoids the need for costly retrofits and rework. This results in more efficient development processes and optimised project timelines and budgets.
  2. Deliver a cohesive user experience: Ensure that accessibility solutions are seamlessly integrated into the overall design and flow of the product from the outset, providing a consistent and inclusive user experience.
  3. Drive innovation: Treating accessibility as a core aspect of development encourages creative problem-solving and innovative solutions. By embracing accessibility constraints, organisations can enhance the user experience for all users and tap into untapped opportunities for improvement.
  4. Promote education and awareness: Teams have the opportunity to gain a better understanding of accessibility principles and best practices. Understanding why things need fixing rather than just what needs fixing will result in more accessible and inclusive products in subsequent releases and projects.

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.

Insight, imagination and expertly engineered solutions to accelerate and sustain progress.

Contact