Accessibility is a feature, so ship it like one

Ask a product team about accessibility and you will usually hear one of two things: "we will do an audit before launch" or "our users do not need it." Both answers cost real money. The audit-later plan turns small fixes into rework, and the second answer is simply wrong about who your users are.

The teams that get this right stop treating accessibility as a compliance checkbox and start treating it as a feature: scoped, owned, tested, and shipped. Here is what that looks like in practice.

The business case is bigger than you think

Around 15% of people live with some form of disability, and that is before you count situational limits: a warehouse supervisor using a tablet in bright sunlight, a parent filling in a form one-handed, a 55-year-old client who has quietly bumped the font size on every device. Accessible products serve all of them.

There is also a hard commercial edge. Enterprise and public-sector buyers increasingly require WCAG 2.1 AA conformance in procurement. We have watched a client win a banking tender partly because they could answer the accessibility section with evidence instead of promises. And the overlap with SEO is real: semantic structure, proper headings, and alt text help both screen readers and search crawlers.

Where products actually fail

After dozens of reviews, the same five problems account for most of what we find. None of them are exotic, and none require a specialist to fix.

• Contrast. Grey-on-grey placeholder text and pale disabled states that fail the 4.5:1 ratio for body text.
• Keyboard traps. Modals you cannot escape, dropdowns that only open on hover, custom widgets with no focus state at all.
• Unlabelled controls. Icon-only buttons with no accessible name, so a screen reader announces "button" and nothing else.
• Form errors that vanish. Validation shown only as a red border, with no text and no announcement.
• Focus order chaos. DOM order that fights visual order, so tabbing jumps around the page.

Notice what is on that list: buttons, forms, modals, focus. These are exactly the shared components a design system owns, which is why fixing accessibility at the component level pays off so heavily. Repair the shared Select once and every screen that uses it improves the same day. We covered that structure in design systems for product teams.

Bake it into the process, not the backlog

Accessibility tickets in a backlog lose every prioritisation fight, because they compete against features with revenue attached. The fix is to move the work out of the backlog and into the definition of done, the same way you handled testing and code review.

1. 1Design reviews check contrast, focus states, and touch-target size before handoff, using the token palette so passing combinations are the default.
2. 2Every component PR includes keyboard behaviour: what Tab, Enter, Escape, and arrow keys do is part of the spec, not an afterthought.
3. 3Automated checks run in CI on every merge and catch the mechanical failures: missing labels, contrast, landmark structure.
4. 4One manual screen-reader pass per release on the two or three flows that matter most.
5. 5Accessibility bugs are bugs. They go in the same queue, with the same severity scale, as everything else.

A test kit that fits in an afternoon

You do not need a lab to test the basics. Unplug your mouse and complete your signup flow with the keyboard alone. Turn on the screen reader built into your phone and try to pay an invoice. Zoom the browser to 200% and check nothing overlaps or disappears. Run your main screens through a contrast checker. Each of these takes minutes and each maps directly to a WCAG criterion.

The first session is always humbling. On one logistics product, the dispatch screen that looked polished turned out to be unusable without a mouse: the driver-assignment dropdown could not be opened at all. That bug had been live for two years. No user had reported it. They had just churned.

Start where the money flows

You cannot retrofit an entire product at once, so sequence it. Fix the shared components first, then the revenue path: signup, login, checkout or its equivalent, and the core daily task. That usually covers 80% of user time within a few sprints. Announce what you fixed in your release notes, because buyers looking for conformance evidence do read them.

Shipped like this, accessibility stops being a scary audit and becomes a normal part of building well. It is a standing part of every design engagement we run at Entrebyte, and the teams that adopt the habit keep it long after we leave.