Accessibility as a growth feature, not a checkbox

By Marco Lopes · October 23, 2024 · Web Development

We often discuss growth through acquisition, activation and retention. We optimise landing pages, shorten onboarding and measure where people abandon a purchase. Yet accessibility can still end up in a separate conversation: something to audit before launch, delegate to compliance or fix when someone complains.

We think that separation is a mistake.

If someone cannot navigate a menu, understand a form error or complete checkout with their assistive technology, we have a product barrier. Buying more traffic will not remove it. Neither will a more persuasive headline.

At Kordspace, we approach accessibility as part of building useful products. As a remote studio working across software, AI, Web3, hardware and design, we see it as a shared responsibility rather than a specialist finishing pass. It supports growth by allowing more people to participate successfully. That business case matters, but access should not depend on proving that every person generates revenue.

Start with the journey, not the audit score

Accessibility work becomes easier to prioritise when we connect it to real tasks. Can someone discover the offering, compare options, create an account, finish a transaction and get help?

We map those journeys before treating the website as a collection of pages. A readable homepage does little good if the booking calendar is impossible to operate with a keyboard.

For an initial review, we choose one high-value journey and try it in several ways:

• With a keyboard and no mouse.
• With a screen reader.
• At increased text size and browser zoom.
• On a narrow screen, including when the on-screen keyboard is open.
• With reduced motion enabled.

These checks reveal different problems. Keyboard testing can expose a focus trap; zoom can reveal clipped controls; a screen reader can reveal that an apparently clear button has no usable name.

We record barriers against the task they prevent, not merely the component where they appear. “Cannot submit a support request” gives a team a clearer priority than “input accessibility issue.”

Use standards as a foundation, not a finish line

As of October 2024, WCAG 2.2 is the current W3C Recommendation for web content accessibility. We generally use Level AA as a technical target, while checking the standards and legal obligations that apply to the product and its markets.

WCAG provides testable requirements covering areas such as contrast, keyboard access, focus, error identification and accessible authentication. It gives design, engineering and quality assurance a shared vocabulary.

It does not replace usability research. A workflow can satisfy individual criteria and still be confusing or exhausting. Nor does a clean automated scan establish conformance: many requirements need manual evaluation and human judgement.

We therefore separate three questions: does the implementation meet the applicable requirements, can people complete the task, and does the experience remain usable under real conditions?

Our acceptance criteria should answer all three. We also avoid presenting a plugin, overlay or accessibility statement as evidence that the underlying product works.

Build accessible behaviour into the design system

The cheapest accessibility fix is often the one we do not have to repeat across twenty screens.

We start with shared components: buttons, links, fields, dialogs, navigation, notifications and tables. Each needs more than a visual specification. We document its accessible name, keyboard interaction, focus behaviour, states and error handling.

A dialog, for example, needs an appropriate label, sensible initial focus, contained keyboard navigation when modal, and a reliable way to close it. When it closes, focus should usually return to the control that opened it.

We prefer native HTML where it fits. A button already has keyboard behaviour and semantics that a clickable div does not. ARIA can communicate information that HTML alone cannot express, but it does not automatically add the missing behaviour.

Design tokens help us keep contrast, focus indicators and spacing consistent. We test actual foreground and background combinations, including hover, disabled and error states, rather than assuming an approved palette makes every interface accessible.

Make forms help people succeed

Forms are where accessibility and conversion work often meet directly. We can remove unnecessary questions, explain unfamiliar requests and make recovery from mistakes straightforward.

We give fields persistent labels rather than relying on placeholder text. Instructions appear before they are needed, and required fields are identified clearly. Where appropriate, standard autocomplete attributes help browsers and assistive tools identify familiar information.

When validation fails, we preserve valid input. We connect each error message to its field and explain what needs to change. For longer forms, an error summary with links to affected fields can make recovery much easier.

“Invalid input” is not enough. “Enter the date as DD/MM/YYYY” gives someone an actionable next step, although we should also ask whether the input format needs to be so restrictive.

Authentication deserves the same care. We support password managers and pasted credentials instead of blocking them. Where a challenge creates a barrier, we provide an accessible alternative. Security controls and accessibility need to be designed together, not traded off casually.

Treat content and media as interface elements

A technically sound page can still exclude people through unclear language, poor structure or inaccessible media.

We write headings that explain the sections beneath them and arrange them in a meaningful hierarchy. We use descriptive links instead of repeating “click here.” We explain essential terminology, especially in products where unfamiliar financial or technical concepts affect decisions.

Alternative text should communicate an image’s purpose in context. Decorative images generally need empty alternative text; informative charts may need a text summary or accessible data table, not a long description stuffed into an image attribute.

For video, we plan accurate captions and any necessary audio description. For audio content, we provide an appropriate text alternative. Building these into production is easier than trying to reconstruct meaning at publication time.

We also review downloadable documents. An accessible landing page leading to an inaccessible application PDF still leaves the main task unfinished.

Watch the places modern interfaces break

Client-side applications introduce accessibility responsibilities that traditional page navigation can hide. When a route changes without a full reload, we need to consider the document title, focus position and how the new context becomes apparent.

Dynamic updates need similar attention. A basket total or submission result may change visually without being communicated to a screen reader. We use status announcements deliberately, avoiding a constant stream of interruptions.

AI interfaces add another layer. Streaming every token into a live region can create an overwhelming experience. We design readable response structure, predictable controls, a way to stop generation and an announcement strategy that does not compete with the content.

For Web3 flows, we inspect wallet connection, transaction review and recovery from rejection or failure. Third-party interfaces can break an otherwise accessible journey. We evaluate them during selection and document limitations we cannot directly control.

When hardware and web interfaces meet, we also avoid assuming that an LED colour, vibration or sound alone communicates enough information.

Combine automation with human testing

Automation gives us useful coverage, especially when it runs repeatedly. We add accessibility checks to component tests and critical end-to-end journeys, and we scan representative pages in continuous integration.

These checks can catch issues such as missing accessible names, some contrast failures and invalid ARIA usage. They cannot tell us whether alternative text is useful, whether a task makes sense or whether focus moves to the right place after a complex interaction.

We pair automation with scheduled manual testing. Our test matrix reflects the audience and includes relevant browser, operating system and assistive technology combinations rather than assuming one setup represents everyone.

We also involve disabled people in research and usability testing, compensate participants, and make the research process accessible. Their feedback is not a substitute for standards testing; it answers different questions about the experience.

Whether we deploy on our preferred Google Cloud stack or on AWS or Azure, we keep these checks close to the delivery pipeline. Hosting choices do not make an interface accessible, but release workflows can help us prevent regressions.

Measure progress without profiling people

We should measure whether accessibility work improves the product, but we do not need to infer who has a disability to do that.

Useful signals include successful task completion in usability studies, abandonment at known problem steps, support requests about access barriers and the time taken to resolve critical defects. We also track recurring issues to identify weaknesses in components or team practices.

We treat conversion changes carefully. If completion improves after several changes ship together, we cannot honestly attribute the entire improvement to accessibility. Controlled experiments may help with some design questions, but we should not deliberately preserve an access barrier just to create a comparison group.

Qualitative evidence matters too. A participant completing a previously blocked task is meaningful progress even when a dashboard cannot isolate its commercial effect.

We make the feedback route easy to find and usable. Reports need an owner, a response process and a path into the backlog, not an unattended mailbox.

Give accessibility an owner at every stage

Shared responsibility works only when individual responsibilities are clear.

We ask product leads to include accessibility in scope and prioritisation. Designers specify interaction and content requirements. Engineers implement and test the behaviour. Quality assurance verifies journeys, while editors maintain accessible content after launch.

For an existing product, we avoid waiting for a complete redesign. We first fix blockers in essential journeys, then address shared components that spread defects widely, and then work through remaining issues with explicit priorities.

Before release, we use a short checklist:

• Can we complete the essential journey using only a keyboard?
• Are names, roles, states and changes understandable with a screen reader?
• Do zoom, reflow and text resizing preserve content and controls?
• Are focus indicators, contrast and non-colour cues sufficient?
• Do forms explain errors and support recovery?
• Are media and documents accessible for their intended use?
• Have we tested third-party steps and assigned owners to unresolved barriers?

This checklist is a prompt, not a conformance claim. We retain detailed evidence and retest affected journeys when the product changes.

Build growth on participation

Accessibility is not a one-time milestone. New features, content updates and third-party integrations can introduce new barriers. We build it into how we discover, design, develop and maintain products because a product cannot serve people it prevents from participating.

If we are going to invest in growth, we should make the core experience worth reaching. To build a new product or improve an existing one with accessibility in scope from the start, start a project with Kordspace. For more about how we work across design and development, explore our related services pages.