Accessibility isn't optional: a practical checklist for B2B apps

Accessibility gets treated as a consumer-app concern, something Amazon and government sites worry about, not the internal dashboard your ops team uses eight hours a day. That's backwards. B2B software has a captive audience that can't just switch to a competitor's app if the contrast ratio hurts their eyes by 3pm, and enterprise procurement increasingly asks for a VPAT before they'll sign. Retrofitting accessibility into a mature app is expensive; building it in from the start is mostly discipline, not extra work.

The checklist that covers 80% of real issues

You don't need a full WCAG 2.2 AA audit to catch most of what actually breaks for real users. Start here, and you'll fix the issues that show up in every usability session we've run.

• Every interactive element is reachable and operable by keyboard alone: try tabbing through your own app before you ship it
• Focus states are visible, not just present: a 1px outline that matches the background isn't a focus state
• Color is never the only signal: a red input border needs an icon or text next to it, not just the color
• Text contrast hits at least 4.5:1 for body copy, 3:1 for large text, checked against your actual brand palette, not a mockup
• Every form field has a real, programmatically associated label; placeholder text is not a label
• Data tables use proper table markup so screen readers can navigate rows and columns, not divs styled to look like a grid

Where B2B apps specifically get it wrong

Dense data tables, dashboards, and multi-step workflows are where most B2B products live, and they're also where accessibility debt piles up fastest, because the temptation to reach for a custom-styled div grid or a drag-and-drop-only interaction is strongest exactly where structured markup matters most.

• Drag-and-drop interfaces (kanban boards, reorderable lists) need a keyboard-operable alternative, not just a mouse gesture
• Modal dialogs must trap focus while open and return it to the trigger element on close
• Loading and error states need to be announced to screen readers via aria-live regions, not just a visual spinner
• Custom dropdowns and comboboxes need real ARIA roles: a styled div with an onClick is not a select element

Build it into the design system, not into every screen

The cheapest way to be accessible everywhere is to make your base components accessible once. If your button, input, modal, and dropdown primitives handle focus states, ARIA attributes, and keyboard interaction correctly, every screen built from them inherits that for free. This is one of the strongest arguments for investing in a real design system early: accessibility becomes a property of the components, not a separate audit pass at the end.