Implementing Accessibility Step by Step (Part 2/2)
In the first part of this article, we covered why accessibility matters, the key regulations, and how standards like WCAG 2.1, the European Accessibility Act (EAA), and EN 301 549 fit together.
Now, let’s move from the why to the how.
This guide offers a step-by-step framework to help teams start, develop, and maintain accessible digital products, with recommended tools, resources, and manual activities for each stage.
1. Starting Point: Accessibility Audit
Your goal for this first step is to assess the current state of your product’s accessibility and identify barriers for people with disabilities.
What is an Accessibility Audit?
An accessibility audit is a systematic evaluation of a digital product, such as a website, app, or platform, to determine how well it meets recognized accessibility standards (e.g., WCAG 2.2, EN 301 549, or ADA requirements). It serves as the foundation for planning accessibility improvements.
Before you can make meaningful accessibility improvements, you need to understand your product’s current accessibility status. An accessibility audit is the essential first step, it’s a structured review of your digital platform, app, or website to identify any barriers that might prevent people with disabilities from using it effectively.
Start by defining the scope of the audit, focusing on key pages or user flows, such as sign-in, checkout, or key dashboards.
Then, assess your product against established accessibility standards such as WCAG 2.2 or EN 301 549, using both manual and automated testing.It’s also important to test your product using assistive technologies such as NVDA or VoiceOver to simulate real user experiences. The goal at this stage is to uncover issues, document them clearly with references to accessibility criteria, and prioritize them based on severity. This audit creates a foundation for the next steps: planning improvements and integrating accessibility into the development process.
Recommended Tools/resources:
- Accessmonitor
- WebAIM’s WCAG Checklist
- Introduction to Web Accessibility
- Figma Accessibility PluginsWCAG plugin
2. Evaluation Activities
For the second step you will sart to dig deeper is goal is to Test your product with a mix of automated tools and real user perspectives.
Once you’ve completed the initial audit, the next step is to dive deeper by combining automated checks with real user perspectives. While automated tools are great for spotting quick wins, like missing alt text or low contrast, they can’t catch everything.
That’s why it’s essential to complement them with usability testing that includes people with disabilities.
These users bring valuable insights that tools can’t replicate, highlighting issues like confusing navigation, unclear error messages, or interactions that break when using screen readers or keyboard-only controls. You can also conduct task-based usability tests, where participants try to complete common tasks like making a purchase or filling out a form.
Observing their experience helps you identify barriers in context. This step ensures that accessibility isn’t just about compliance, it’s about creating a truly usable product for everyone. The findings will help you prioritize improvements based on real impact and user needs.
Recommended Tools/resources:
- ATAG Report ToolThis tool helps evaluators report on the accessibility ofauditing tools.
- NVDA Screen Reader
- VoiceOver (built-in for Mac/iOS)
- Axe Accessibility Scanner (Mobile)
- Keyboard-only navigation test.
- Include users with disabilities in usability testing sessions.Inclusive Usability Testing Guide (W3C)
- WebAIM’s WCAG Checklist
- Accessibility checklist from A11yproject
- WCAG 2.2 with palin language (in portuguese)
3. Planning and Development
With accessibility issues identified and user feedback gathered, the next step is to embed accessibility into your design and development process from the beginning.
This means shifting from fixing issues after the fact to proactively designing and building with inclusivity in mind. Start by translating audit findings and user insights into actionable updates, such as revising color palettes for contrast, improving keyboard navigation patterns, or updating components to use proper semantic HTML.
Make accessibility a shared responsibility across the team by involving designers, developers, and content creators early on. Use accessible design systems or component libraries (like Material Design or Gov.uk Design System) that follow WCAG standards.
Design teams can use Figma plugins such as Able, Stark, or Contrast to check color contrast and simulate vision impairments directly in their mockups. On the development side, integrate tools like eslint-plugin-jsx-a11y, axe-core, and Pa11y into your CI/CD pipeline to automatically flag accessibility issues during builds.
Pair this with thorough documentation, including accessibility checklists and coding guidelines, to keep teams aligned.
By planning for accessibility from the start, you create a foundation for inclusive, scalable, and legally compliant digital experiences, while saving time and effort in the long run.
Recommended Tools/Resources:
- Accessibility audit kit using Figma or just an Excel (figma kit example)
- Figma Accessibility Plugins (Able,Stark plugin for figma)
- Color Contrast Checker
- WAI Design and Develop Accessibility
- ARIA Authoring Practices Guide
- https://design-system.service.gov.uk/
4. Integration into the Product Lifecycle
Making a product accessible isn’t a one-time task, it needs to be part of your ongoing process. This step is about embedding accessibility into the entire product lifecycle, so it becomes a consistent part of how you design, build, and release features.
That means incorporating accessibility tasks into sprint planning, user stories, and definition of done. For example, a user story might include a requirement that the feature be fully navigable by keyboard or readable by screen readers.
During QA, include accessibility checks alongside functional testing using tools like axe DevTools, Accessibility Insights, or Screen Reader testing to validate usability across assistive technologies.
Ensure that your QA team and product managers are trained to recognize and flag accessibility regressions, and consider adding automated checks to your deployment pipelines.
You can also use accessibility scorecards or dashboards to monitor progress over time. By treating accessibility as a continuous, integrated part of your development cycle, not an afterthought, you create better experiences for all users and reduce the risk of compliance issues or costly redesigns later.
Manual Activities:
- Include accessibility acceptance criteria in user stories.
- Run accessibility checks as part of code reviews.
- Add accessibility checkpoints in QA testing cycles.
Recommended Tools/Resources:
5. Continuous Testing and Validation
Accessibility isn’t something you achieve once; it’s something you maintain. As your product evolves, new features, updates, and content can unintentionally introduce accessibility barriers. That’s why continuous testing and validation are essential to ensure your product remains inclusive over time.
Schedule regular accessibility reviews as part of your release cycle, and run automated scans frequently using tools like Axe-Core, Pa11y, or Siteimprove to catch regressions early.
Combine these with periodic manual testing, including keyboard navigation checks and screen reader walkthroughs. Encourage real users, including those with disabilities, to give feedback on a recurring basis, through usability testing, support channels, or in-app feedback widgets.
Monitor metrics over time, such as your WCAG conformance level or the number of resolved accessibility issues per release.
Finally, stay up to date with evolving standards like WCAG 2.2 or legal changes in your region. By making accessibility validation a routine practice, you protect the user experience for everyone and avoid the risk of falling behind or introducing unintentional barriers.
Here an accessibility continuous validation checklist to help you:
- Run automated scans after every release
- Schedule quarterly manual audits or accessibility check-ins
- Test with real users, including people with disabilities
- Monitor accessibility metrics (e.g., issues resolved, conformance level)
- Keep documentation and accessibility guidelines up to date
- Re-test existing features after significant UI or content changes
- Subscribe to updates on WCAG, EN 301 549, and legal standards
- Encourage team-wide ownership of accessibility over time
Recommend tools/Resources:
- Scheduleperiodic accessibility audits.
- Monitoruser feedback and accessibility complaints.
- Stay updated withWCAGrevisionsand evolving standards.
- Declaration of accessibility
- Google Lighthouse Scheduled Runs
Final Takeaways
Start Now.
Accessibility is not something to postpone; even small, incremental improvements make a difference.
Balance Automation and Manual Testing.
Automated tools can catch 30–40% of accessibility issues. Manual evaluation and involving real users will catch the rest.
Make Accessibility Everyone’s Job.
It’s not just a developer task. Designers, product owners, QA, and content writers all have a role.
Think Lifecycle, Not Checklist.
Accessibility isn’t a one-time event. It must be built into your workflows and continuously monitored.
Resources and Support Are Available.
From WCAG cookbooks to technical checklists like EN 301 549, your team has clear paths to follow.
Got thoughts on this?
I’d love to hear them. Have you run into accessibility barriers that frustrated you? Or maybe you’ve seen examples of places that got it right? Let’s talk about it.
