Building a lasting accessibility strategy: Part 3
Posted:
In part 2, we covered how to get people involved, raising awareness, accessibility champions, and the importance of internal resources.
Now that you have people on board, the next step is making accessibility part of how you build and maintain your products. That means going beyond compliance, weaving accessibility into the development lifecycle, making good use of design systems, building a dedicated accessibility function, and ensuring every role contributes to more inclusive experiences.
As before, I'll keep using the word "website" as shorthand for digital products, services, platforms, and apps.
Understand technical compliance, but aim higher
A lot of organisations stop at WCAG AA compliance, since it's the minimum required by most accessibility laws. The problem is that this approach often ignores AAA requirements and best practices outside WCAG that can make a big difference to real people.
AAA criteria are especially helpful for people with cognitive, visual, or auditory impairments. For example:
- 1.4.6 Contrast (Enhanced): higher contrast ratio for text, improving readability for people with low vision
- 2.4.9 Link Purpose (Link Only): ensures link text makes sense in isolation, which helps screen reader users
- 3.1.5 Reading Level: can help people with dyslexia and other learning disabilities
It's true that not all AAA criteria are practical for every website. WCAG itself says Level AAA should not be required across the board. But aiming for AAA where possible is valuable. WCAG itself notes:
It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
Beyond WCAG, additional guidance and recomendations exist, such as the work done by the W3C's Cognitive and Learning Disabilities Accessibility Task Force (COGA TF), for example, Making Content Usable for People with Cognitive and Learning Disabilities. The excellent Inclusive Design Principles are another useful reference.
Simple design choices can make a big difference too. A decorative font might technically pass contrast checks but still be hard to read for people with dyslexia or low vision. That's why testing with real users is so important: a site can meet WCAG yet still include barriers.
Compliance is the baseline. A stronger approach is to define your own accessibility standards, combining AA, selected AAA, and best practices that fit your users' needs.
Embed accessibility into the full development lifecycle
Accessibility isn't something to tack on at the end, nor is it just one person's job - everyone can and needs to contribute. It should be integrated across the entire development life-cycle. Set role-specific expectations and requirements. For example:
- Product owners/Project managers: prioritise accessibility work, ensure it's included in roadmaps and make space for it in sprints. Write accessible user stories and acceptance criteria.
- Designers: follow inclusive design patterns from the start, including accessible colours, target sizes, layouts, user journeys and interactions that work for a wide range of users.
- Developers: use accessible components and semantic HTML. Run basic accessibility checks before passing work to testers. Write accessibility test assertions with the same priority as unit and end-to-end (e2e) tests. Include accessibility checkpoints in your Definition of Done (DoD)
- QA/Testers: catch issues through automated tools and manual testing with assistive technologies. Contribute to any automated accessibility test suite.
Other roles, not specifically involved in the typical development lifecycle can and should also contribute to promoting accessibility:
- Content authors: write clear, concise content with headings, plain language and descriptive link text so information is easy to understand and navigate
- Customer support: listens to feedback from users, especially those with disabilities, and passes insights back to product teams
- Marketing: produces campaigns and assets that are accessible and easy to engage with, from alt text on images to accessible PDFs and video captions
- Leadership: sets expectations, removes barriers and gives teams the time and resources they need to do accessibility properly
Accessibility works best when it's seen as part of everyone's responsibility, not a single team's task. When each role contributes, accessibility becomes a natural and sustainable part of your organisation's culture. The goal is to make accessibility a habit, not a one-off task.
Design systems and component libraries
If you're not using a component library, start now. If you are, make sure accessibility is built in by default.
These reusable UI components should include all the necessary accessibility considerations - semantics, color contrast, keyboard support, ARIA (where necessary - remember the first rule of ARIA), focus styles - the lot. Broader accessibility guidance can be covered in your design system, as well as component specific guidance and expectations.
The real power of a component library is that updates cascade across your whole product. Fixing one component can fix hundreds of instances in one go. That makes it a powerful tool for rolling out accessibility improvements, and a natural place to start when auditing or testing your site.
An accessible component library doesn't guarantee a fully accessible product, but it gives teams strong foundations to build on.
A dedicated accessibility team
Many organisations don't have a dedicated accessibility team or lead, and instead rely on individual champions scattered across departments. While this grassroots energy is important, having a dedicated team can significantly accelerate progress.
A dedicated accessibility team can:
- Set direction: define the organisation's accessibility vision, strategy and standards
- Provide expertise: fill knowledge gaps across teams by offering guidance on design, content and development best practices
- Collaborate: with product management, design, and development teams to define accessibility requirements and acceptance criteria
- Consult: on scope of effort, user impact, and regulatory priorities related to accessibility
- Deliver training: run onboarding, refresher sessions and role-specific training tailored to different functions
- Support projects: partner with product teams to review designs, test features and advise on complex accessibility challenges
- Build resources: maintain documentation, component libraries and internal guidance to ensure consistent approaches
- Lead audits and monitoring: coordinate testing and reporting, making sure accessibility is continuously tracked and improved
- Act as advocates: champion accessibility at all levels, helping it stay visible and properly resourced
The presence of a team also shows that accessibility is a real priority, not just something left to volunteers. It gives people a clear place to go for advice and reduces the burden on individual teams.
What a dedicated team can look like
- Smaller organisations: A single accessibility lead or specialist who drives initiatives, supports teams, and acts as the main point of contact
- Mid-sized organisations: A small accessibility team (2–3 people) who split responsibilities across training, audits, design support and development guidance
- Larger organisations: A central accessibility function with specialists in design, development, content and assistive technology, often paired with accessibility champions embedded across departments
Whatever the size, the team needs both visibility and authority. They should be able to influence priorities, shape processes, and work with leadership to ensure accessibility is resourced and sustainable.
The business case
Investing in a dedicated team pays off quickly. It helps avoid costly retrofits or lawsuits, creates reusable resources, and drives customer loyalty by making products usable by more people. In short: it helps everyone work smarter, not harder.
In part 4, we'll wrap things up by covering testing, measuring and monitoring accessibility.