IT leaders, product owners and designers responsible for internal enterprise applications - ERPs, dashboards, field-service tools, HR and operations portals - used by employees every day.
- Accessibility work in enterprises tends to focus on the public website. Internal tools - used all day, often for high-stakes work - are rarely audited.
- Your workforce includes people with disabilities: more than 1 in 4 US adults have some type of disability, and many more have temporary or situational limitations.
- Internal tools fail in predictable ways: complex tables, custom widgets, keyboard traps, session timeouts, colour-only status and inaccessible exported documents.
- The efficient fix is systemic. Build accessible components and patterns once, and every internal application inherits them.
- Start with the tools used most often and for the highest-consequence tasks, not the easiest ones to fix.
Accessibility conversations in enterprise and infrastructure companies usually centre on the public website - understandably, since that is where legal and reputational scrutiny is most visible. What gets missed is the software employees use every day: ERPs, maintenance systems, HR portals, dashboards, field-service apps, approval workflows. These tools are rarely audited by anyone outside the company, and the people who struggle with them have often learned to work around problems that should not exist.
This article covers why internal tools deserve the same accessibility discipline, where they typically fail, and how to fix them efficiently across a portfolio of applications. For public-facing websites and procurement requirements, see our companion piece on accessibility for public-facing enterprise websites.
Why internal tools matter more than they seem
Your workforce includes disabled people. The CDC reports that more than 1 in 4 US adults have some type of disability, and the WHO estimates 16% of the global population experience significant disability. Not everyone discloses, and many conditions are invisible: low vision, colour-vision deficiency, dyslexia, repetitive strain injury, tremor, hearing loss, migraine.
Temporary and situational limits are common. A broken arm, recovery after surgery, a glare-filled site office, a noisy plant floor, gloves, a small shared screen - all make an inaccessible tool harder for everyone.
Internal tools are used longer and harder. Public websites are visited briefly; internal tools are used for hours, repetitively, often under time pressure and with real consequences - approving payments, scheduling maintenance, recording safety checks. Small barriers compound over a working day.
Workarounds hide the cost. When a tool is hard to use, people ask colleagues for help, keep side spreadsheets or avoid certain tasks. Those costs rarely show up as "accessibility problems", but they are.
Where internal tools usually fail
Public websites tend to fail on content basics - WebAIM's 2026 study found low-contrast text on 83.9% of top home pages. Internal applications share those problems and add their own, because they are built from complex, often custom, interactive components.
| Problem | How it shows up in internal tools | Who it affects most | WCAG area |
|---|---|---|---|
| Complex data tables | Grids without header associations; sorting and editing only by mouse | Screen-reader and keyboard users | Info and relationships; keyboard |
| Custom widgets | Home-made dropdowns, date pickers and tree views that ignore keyboard and screen readers | Keyboard, screen-reader and switch users | Keyboard; name, role, value |
| Keyboard traps | Focus stuck in a modal or embedded frame | Keyboard users | No keyboard trap |
| Invisible focus | No visible indicator of where you are on a dense form | Keyboard users, low vision | Focus visible |
| Colour-only status | Red, amber and green dots with no text | Colour-vision deficiency, low vision, printouts | Use of colour |
| Timeouts | Sessions expire mid-form with data lost | People who need more time | Timing adjustable |
| Tiny targets | Small icon buttons packed together | Motor impairments, touchscreens, gloves | Target size (WCAG 2.2) |
| Exported documents | Reports as untagged PDFs or images of tables | Screen-reader users | Varies |
| Vague errors | "Invalid input" with no explanation | Everyone, especially cognitive disabilities | Error identification and suggestion |
Fix it in the system, not per application
Most enterprises run dozens of internal applications, often built by different teams and vendors over many years. Auditing and fixing each one individually is slow and never finishes. The efficient approach is the same lesson that applies to visual consistency: build accessibility into shared components and patterns, so every application that uses them inherits the fix.
Practical steps:
- Agree a baseline standard. WCAG 2.1 or 2.2 Level AA is the usual target for enterprise software.
- Fix the shared building blocks. Tables, form controls, dialogs, menus, tabs, date pickers, notifications and status indicators - accessible once, reused everywhere.
- Document the patterns. Keyboard behaviour, focus order, error handling and status language, with examples.
- Put accessibility in vendor contracts. Require conformance to your standard and an accessibility conformance report for purchased or outsourced software.
- Add checks to delivery. Automated tests in CI, keyboard testing in QA, and accessibility acceptance criteria in tickets.
Handled per project, accessibility becomes a recurring cost that never fully resolves. Handled at system level, it becomes an investment that pays out on every application built afterwards. See design systems and WCAG-informed design for how that looks in practice.
Where to start: prioritise by use and consequence
You cannot fix everything at once. Rank internal applications on two axes:
| Low consequence of error | High consequence of error | |
|---|---|---|
| Used daily by many people | Fix second: high cumulative friction | Fix first: e.g. timesheets, approvals, maintenance logs, safety checklists |
| Used occasionally | Fix last | Fix third: e.g. annual reviews, incident reporting |
Then, within each application, start with the most common tasks: sign-in, search, the main form, the main table, and any export people rely on.
A quick self-check
Try these five tests on one of your most-used internal tools:
- Put the mouse away and complete a routine task with only the keyboard. Can you see where focus is at every step?
- Zoom the browser to 200%. Does the layout still work without horizontal scrolling on a normal screen?
- Turn on a screen reader and navigate a key table. Are column headers announced?
- Convert a screenshot of a status dashboard to greyscale. Can you still tell statuses apart?
- Leave a long form half-finished for the session timeout period. Do you get a warning, and is your data kept?
If any of these fail, you have found real barriers that affect real colleagues.
Accessibility and brand consistency are the same project
Enterprises with a structured brand and design system find accessibility easier to apply consistently, because colours, type sizes, spacing and components are already defined centrally. On an infrastructure brand system, enforceable rules - a defined grid, a fixed spacing scale, specified type sizes - gave the team one place to embed accessibility decisions rather than hundreds. Read more in how to build an enforceable design system.
The accessibility gaps I find most often in enterprise and infrastructure companies are not on the public website - teams have usually at least thought about that one. They are in the internal tools nobody outside the company audits, used daily by employees who have learned to work around problems that should not exist.
Treating accessibility as a system-level default rather than a per-application decision is what closes that gap efficiently. It is also the only version that scales: auditing every internal tool one at a time, forever, is not a realistic operating model for a company with a growing application portfolio.
Frequently asked questions
Are internal tools legally required to be accessible?
It depends on your country, sector and employment law, and whether you are a public body. Many organisations have obligations to make reasonable adjustments for employees. Check with your legal team - but the business case for accessible internal tools stands regardless.
We buy most internal software. What can we do?
Make accessibility part of procurement: ask vendors for a conformance report against WCAG 2.1 or 2.2 AA, test the key workflows before signing, and include remediation commitments in contracts.
Won't accessibility slow down internal tool development?
Not if it is in the shared components. Teams using accessible building blocks spend little extra time; the cost comes from fixing custom components after the fact.
How do we find out which employees are affected?
You do not need to identify individuals. Design for the whole workforce, invite feedback through an accessible channel, and include disabled employees in usability testing where they volunteer.
Which tools should we test first?
The ones used most often for the highest-consequence tasks - approvals, safety records, timesheets, core operational systems.
Unsure if your internal tools would pass an accessibility review?
Let's find out - and build the fix into your system, not a one-off patch.
Sources
Every statistic in this article links to its original publisher. Figures were checked against these sources on September 29, 2026.
- Disability Impacts All of Us - US Centers for Disease Control and Prevention
- Disability and health fact sheet - World Health Organization, 2023
- The WebAIM Million, 2026 report - WebAIM, 2026
