Accessible by default: How we embed accessibility into our development and quality processes

At Nexer Digital, we believe digital services should work for everyone, regardless of ability, device, or context. Accessibility is not something we tack on at the end. It is part of how we design, build, and deliver from the very beginning.

Our focus is on digital accessibility. That means making sure the websites, platforms and tools we create work for people with a wide range of access needs, including those using screen readers, voice commands, or keyboard navigation. It matters not only because it is the right thing to do, but because accessibility is shaped by the decisions made during software development. When you build access in from the start, the result is stronger, more inclusive digital products.

Here is how we make sure accessibility is embedded into every stage of our software development process.

Starting with culture

Accessibility is built into our team culture. It’s not the job of one person or one team, it’s a shared responsibility. That means we talk about accessibility during sprint planning, in design reviews, and in the kitchen over a cup of tea. We don’t treat it as a ‘nice to have’ or a checkbox to tick off once that other work is done.

We also run regular training across our teams to build confidence and understanding, and we often share real-world stories, both from colleagues in the team, and further afield, to remind ourselves who we’re designing and building for. It helps keep us grounded in the fact that we’re making things for people, not just ‘users’.

Designing with accessibility in mind

Good design is inclusive design. Our design team starts by thinking about accessibility from the earliest stages of a project. That means using colour palettes with strong contrast, choosing readable fonts, and keeping things clear and consistent.

We also consider how people interact with digital products in different ways -- by keyboard, screen reader, touch, or voice. We test prototypes early to check that they’re accessible before any code is written. This saves time and avoids any problems later down the line.

Building accessibility into development

Our developers start with semantic HTML, ensuring each page is built on a meaningful structure that supports both human understanding and machine readability. This enables better navigation for users who rely on screen readers, keyboard input, or voice assistants. 

When building forms – the basis of most user interactions – we ensure every input is properly labelled, includes real-time feedback, and supports intuitive navigation. Error states, required fields, and confirmation messages are implemented with clarity and care. 

Accessibility is embedded from the earliest stages of our design and development workflow and we create prototypes and reusable components with accessibility features baked in. This includes dynamic ARIA attributes, correct tab index order, logical focus management, and keyboard-accessible interactivity. By standardising accessible patterns in our component libraries, we avoid duplicating effort across projects and consistently deliver inclusive experiences.

The role of our Quality team

Our Quality team plays a big part in making sure accessibility is properly delivered. We don’t just test for bugs. We help define what accessible means and collaborate closely with the relevant delivery teams to guide that work throughout the project. This includes adding accessibility requirements into our acceptance criteria and user stories.

Example user story

As a visitor, I want to see the latest news in a block on the page so that I can stay updated.

Acceptance Criteria:

1. Block displays X most recent news articles (default 3, configurable 1–10). After 3, carousel is apparent. Loops back to start when reaching the end.
2. Each article shows title, summary, image, date, and link.
3. Editor can set: number of items, block title, category.
4. Responsive layout matches design. (Desktop, Mobile, Tablet)
5. Graceful empty state if no news.
6. Accessible and semantically marked up. Images have alt text. Fully keyboard navigable.
7. Must use existing News document type.
8. Performance target: loads in <500ms.

We carry out audits, raise defects, and advocate for accessibility just as we would for performance or usability. We try to ask the right questions at the right time. Whether that is in backlog refinement or whilst creating defects, we make sure issues are properly prioritised and fixed.

Testing, automated and manual

We use a combination of automated tools and manual testing to make sure our work meets accessibility standards and works well for real people.

Tools like axe DevTools, Wave, Lighthouse, and SiteImprove help us catch common issues early in the build. But automation can only go so far, so we also test manually. That includes navigating with a keyboard, checking compatibility with screen readers like NVDA or VoiceOver, and verifying that layouts respond well to zoom and text resizing.

Wherever possible, we include people with lived experience of disability in our user testing. No tool or checklist can replace real feedback from real people.

We share what we learn

Accessibility is always evolving and guidelines are updated, so we’re constantly learning. We share that learning internally, through playbacks, lunchtime talks, and documentation, so that everyone at Nexer can benefit from it.

And we’re always learning

We don’t claim to have it all figured out. Accessibility is a journey, and there’s always more to learn, especially as technologies change and people’s needs shift.

But we’re committed to building digital services that are as inclusive as possible, and doing that consistently, not just when a project specifically asks for it. Accessibility isn’t what we do, it's who we are.

Why it matters

Ultimately, accessible design is better design. It helps more people use what we build, improves usability across the board, and makes our digital services more resilient and futureproof.

It supports compliance with standards like WCAG, and legislation like the European Accessibility Act (EAA). It also improves search engine performance, and increases engagement by removing barriers. And, most importantly, it means we are not leaving anyone behind.

If you are looking to improve digital accessibility in your services or want to share ideas on accessible software development, we would love to hear from you: hello@nexerdigital.com