Most accessibility work stops at the marketing site. The public pages get audited, the contrast gets fixed, and the admin dashboard, where employees spend eight hours a day, gets ignored. That's a mistake, and it's increasingly an expensive one.
Internal Tools Are Still Covered
The ADA doesn't distinguish between "customer-facing" and "employee-facing" software. Title I covers employment, which means any tool an employee is required to use must be usable by employees with disabilities. If your dashboard can't be operated with a screen reader or a keyboard, and you hire someone who needs one, you're looking at a reasonable-accommodation obligation at minimum, and a discrimination claim at worst.
Federal contractors face Section 508. Companies selling SaaS to enterprises increasingly get hit with VPAT requests during procurement. "It's only internal" is not a defense anyone's lawyer actually wants to make.
Beyond the legal exposure, there's the plain operational cost: an inaccessible dashboard means you can't hire the best person for the job if that person happens to use assistive tech. You also can't accommodate temporary impairments (a broken wrist, eye surgery, a migraine) without a full workflow disruption.
Failure 1: Data Tables Built From Divs
This is the most common failure in admin UIs. Someone needed a sortable, filterable, resizable table and reached for a grid library that renders everything as nested divs with ARIA sprinkled on top. Screen readers announce it as a pile of text. Keyboard users can't navigate row to row.
A real table needs <table>, <thead>, <tbody>, <th scope="col">, and <th scope="row"> where appropriate. If you're using a library, verify it emits actual table semantics. Many popular React data grids don't. Check that column headers are programmatically associated with cells, that sort state is announced via aria-sort, and that keyboard users can move through cells predictably.
Failure 2: Form Density With No Labels
Admin forms pack fifty fields onto a screen. To save space, designers drop the labels and rely on placeholders, tooltips on hover, or a header above a cluster of inputs. All three fail WCAG.
Every input needs a programmatically associated <label>, even if you visually hide it. Required fields need aria-required="true" and a visible indicator that isn't color-only. Validation errors must be announced via an aria-live region or an aria-describedby pointing to the error text. A red border alone tells a screen-reader user nothing.
Grouped fields (an address block, a date range) need <fieldset> and <legend> so the group's purpose is announced once, not repeated per input.
Failure 3: Keyboard Navigation Traps
Admin tools are full of custom widgets: combo boxes, multi-selects, drawer panels, command palettes, inline editors. Each one is a fresh opportunity to trap a keyboard user or skip them past critical controls.
The baseline: every interactive element must be reachable with Tab, operable with Enter or Space, and dismissible with Escape where a dismiss action exists. Custom widgets should follow the ARIA Authoring Practices patterns. Don't invent your own keyboard model. A combo box that uses arrow keys for one thing on one screen and another thing on another screen is unusable.
Tab through every page of your dashboard with no mouse. If you lose track of focus, if focus jumps somewhere unexpected, or if a modal swallows your keyboard, you have a bug to file.
Failure 4: Color-Only State
Status columns love color. Green dot for active, red dot for error, yellow for pending. Gray for disabled. None of that conveys meaning to someone who can't distinguish the colors, and "gray for disabled" often fails contrast entirely.
Every status needs a non-color indicator: a text label, an icon with an accessible name, or both. "Active" beats a green circle. If you must use an icon, pair it with aria-label or visually hidden text. Disabled buttons should still be perceivable. aria-disabled="true" is often better than the disabled attribute because disabled buttons are removed from the tab order and their purpose becomes invisible.
Failure 5: Modal Focus Management
Admin dashboards open modals constantly: confirm dialogs, edit forms, filter panels. Most of them handle focus wrong. Focus should move into the modal on open, stay trapped inside it until close, and return to the trigger element on close. Escape should dismiss.
Check three things on every modal: Does opening it move focus inside? Does Tab cycle only through the modal's contents? Does closing it return focus to the button that opened it? If any of those answers is no, a keyboard user is lost the moment the modal appears.
What To Do This Week
- Run an automated scan (axe, WAVE, Lighthouse) against your three most-used admin pages. Fix the critical issues first.
- Tab through your dashboard with the mouse disconnected. Note every place focus disappears, skips, or traps.
- Audit your data tables for actual table semantics. Replace div-grids with real tables or a library that emits them.
- Add visible labels to every form field. Remove placeholder-as-label everywhere.
- Replace every color-only status indicator with text or icon plus accessible name.
- Write an accessibility acceptance criterion into your ticket template so new features don't regress.
If this list looks like a quarter of work, it probably is. Schedule a consultation and we'll scope an audit against your actual dashboard, not a generic checklist.