Planning accessibility means deciding, at each stage of a project, how people with different abilities will use the system. It is not a separate workstream tacked on before launch. It is a set of constraints and choices that shape the specification, the design, the component library, the acceptance criteria and the ongoing support model.
Decision summary: Include accessible interaction, content, errors, focus, keyboard use and assistive-technology testing from discovery onward.
For business systems — CRMs, customer portals, admin panels, document workflows — accessibility planning has particular characteristics that differ from public-facing marketing sites. The users are often employees or contracted partners who must use the system to do their job. If the system is inaccessible, the business does not lose a casual visitor; it creates a compliance risk, a productivity bottleneck and a potential duty-of-care issue.
The planning decisions that matter most fall into four areas:
- Which users and roles need accessibility support. An admin panel used by three internal staff has different planning requirements from a customer portal used by thousands of external account holders.
- Which interaction patterns the system relies on. Drag-and-drop kanban boards, complex data tables, multi-step wizards and real-time notifications each present distinct accessibility challenges that need to be addressed in the design phase, not after development.
- Which third-party components and integrations are involved. A charting library, a rich-text editor or an embedded payment form may or may not meet the accessibility level you are targeting. That decision is made during component selection, not during testing.
- How accessibility will be verified and maintained. Planning includes deciding what evidence of accessibility you will require at each milestone and who will be responsible for it after launch.
Accessibility planning should begin in discovery and be reflected in the specification. If it is absent from the initial requirements document, it will almost certainly be underfunded and under-prioritised later.
| Accessibility area | User impact | Evidence |
|---|---|---|
| Mapping accessibility to user roles | Start by listing the roles in the system and asking, for each one, whether accessibility is a hard requirement, a desirable improvement or not applicable. | Test authorisation, recovery and removal as well as successful access. |
| Interaction patterns in business systems | Business applications tend to rely on interaction patterns that are more complex than those found on informational pages. | Retain test scope, issue evidence, remediation and retest status. |
| Third-party components and integrations | Most business systems include third-party elements: date pickers, WYSIWYG editors, mapping widgets, chart libraries, embedded iframes from payment providers. | Retain test scope, issue evidence, remediation and retest status. |
| Writing accessibility into the specification | The specification should state the target accessibility level (for example, WCAG 2.2 AA) and then translate that into concrete requirements for each feature. | Test authorisation, recovery and removal as well as successful access. |
The current accessibility baseline
For “How to Plan Accessibility in a Web Application”, accessibility obligations depend on the organisation and service, while WCAG provides testable technical criteria rather than a complete legal conclusion. Plan accessible interactions from discovery and retain manual as well as automated test evidence.
Mapping accessibility to user roles
Start by listing the roles in the system and asking, for each one, whether accessibility is a hard requirement, a desirable improvement or not applicable. A customer-facing portal where users cannot self-select an alternative channel demands a higher accessibility standard than an internal reporting tool that only one person uses and where reasonable adjustments can be made differently.
This role-based approach also intersects with role-based access control planning. If certain users have permission to view sensitive data but rely on screen readers, the way that data is presented in tables, modals and filtered views needs to work with assistive technology from the outset.
Interaction patterns in business systems
Business applications tend to rely on interaction patterns that are more complex than those found on informational pages. Planning accessibility means examining each pattern early:
- Data tables with sorting, filtering and inline editing. These need proper markup, keyboard-operable controls and clear announcements when content changes.
- Multi-step forms and wizards. Users need to understand where they are in the process, what has been validated and how to go back without losing data.
- Notification systems. Toast messages, inline errors and status banners must be announced to assistive technology and must not disappear before a screen-reader user can read them.
- Document preview and annotation. If the system allows users to review or mark up documents, the annotation layer must be reachable by keyboard and describable to screen readers.
For each pattern, the planning question is not "can we make this accessible later?" but "do we have a design and a component that supports accessibility now?" If the answer is no, the pattern needs to change or the component needs to be replaced before development begins.
Third-party components and integrations
Most business systems include third-party elements: date pickers, WYSIWYG editors, mapping widgets, chart libraries, embedded iframes from payment providers. Each of these is a planning decision. Before a component is selected, check whether the vendor documents its accessibility support, whether it has been tested with screen readers and keyboard-only navigation, and whether you can control or override its behaviour if it falls short.
If an integration — for example, a third-party billing dashboard embedded via iframe — cannot be made accessible, the planning decision is how to handle that: provide an alternative accessible view, document the limitation and the rationale, or choose a different provider. Ignoring the problem is not a plan.
Writing accessibility into the specification
The specification should state the target accessibility level (for example, WCAG 2.2 AA) and then translate that into concrete requirements for each feature. Rather than a single line saying "the system must be accessible," the specification should include statements such as:
- All form fields must have visible, persistent labels.
- Data tables must support keyboard navigation of rows and cells.
- Error messages must be associated with the relevant field and announced to screen readers.
- Modal dialogs must trap focus and return it on close.
This level of specificity gives developers clear boundaries and gives you a basis for acceptance criteria.
Treating accessibility as a retrofit
The single most common mistake is assuming that accessibility can be "added on" after the core functionality is built. In practice, retrofitting accessibility is significantly more expensive than building it in, because it often requires changes to the underlying HTML structure, the component architecture and the interaction logic — not just the visual styling. If accessibility is not in the specification and the acceptance criteria, it will not be in the delivered system.
Assuming automated tools are sufficient
Automated accessibility checkers can identify a subset of issues — missing alt text, empty headings, colour-contrast failures in some cases. They cannot determine whether a workflow makes sense to a screen-reader user, whether a drag-and-drop interface has a usable keyboard alternative, or whether the timing of a notification is appropriate. Planning needs to account for manual testing as well, but the details of what to require from testing belong in a separate assessment — the point here is that the plan must include a budget and a process for it.
Overlooking dynamic content and single-page application behaviour
Business web applications frequently update content without a full page reload: filtered lists, live search results, status changes and AJAX-driven form submissions. Each of these can break assistive technology if the development team does not plan for appropriate ARIA live regions, focus management and state announcements. This is a technical planning decision that should be raised during architecture and component selection, not discovered during testing.
Not assigning responsibility
Accessibility planning fails when nobody owns it. The specification can list requirements, but if there is no agreed point during each sprint or milestone where accessibility is reviewed, those requirements will be deprioritised under time pressure. The plan should name who checks accessibility at each stage — the developer during build, the designer during review, a specialist during acceptance — and what happens when an issue is found.
Key questions to put to a supplier
- How do you integrate accessibility into your discovery and specification process?
- Which accessibility level do you default to, and how is it documented in the acceptance criteria?
- How do you evaluate third-party components for accessibility before selecting them?
- What is your process for handling dynamic content, single-page application routing and focus management?
- Who is responsible for accessibility verification at each milestone, and what evidence do you provide?
- How do you handle accessibility issues found after launch — are they treated as bugs, as support requests, or as separate change requests?
Limitations to acknowledge
Accessibility planning cannot guarantee a perfect experience for every user in every combination of assistive technology and browser. What it can do is establish a clear target, make that target measurable, embed it into the build process and create a mechanism for handling the gaps that will inevitably surface. The plan should include a process for receiving and triaging accessibility feedback after launch, not assume that the initial build will be definitive.
Additionally, some business-system features — complex data visualisations, real-time collaborative editing, highly specialised domain interfaces — may not have established, well-tested accessible patterns. In these cases, honest planning means documenting the limitation, providing the best available alternative and scheduling further work rather than claiming full compliance.
Accessibility evidence to retain
- Identify the critical journeys and users that must be included in manual testing.
- Test with keyboard operation, screen readers, zoom, reflow, contrast and realistic error states.
- Keep an evidence-backed remediation plan and retest after significant changes.
- Define the applicable legal and contractual position for the organisation and service; public-sector regulations and Equality Act duties are not interchangeable.
Primary guidance checked for this edition
Sources for “How to Plan Accessibility in a Web Application” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.