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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
Linters: Linters run against your source code and can be used to detect any accessibility violations before the code has even been executed.
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:
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.
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.
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.
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.
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:
Copy to Clipboard
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.
Copy to Clipboard
By using some of the above techniques and shifting accessibility considerations earlier in the development lifecycle, product teams can:
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.
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.
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.
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.