An internal tool should enter procurement and acceptance with verifiable accessibility scenarios, not only a supplier's general statement. Check whether a user can complete an official transaction by keyboard, whether a screen reader can convey the form and its errors, and whether focus remains visible. State formal conformance only after an appropriate assessment.
Accessibility of internal business tools is not an isolated design topic. It determines whether an employee can independently enter an invoice, approve an order, close a production work order, find a document, or correct an incorrect entry.
In ERP and connected business applications, a barrier often appears in a small step: focus disappears after a dialog opens, a required field has no clear label, an error message remains outside a screen reader's reach, or an action can only be completed with a mouse. The result is not only an inconvenient user experience. A user may stop, ask another person for help, record incorrect data, or fail to complete an official transaction on time.
Accessibility should therefore be treated as a criterion of the system's business capability. Procurement defines what the supplier must demonstrate. The process owner identifies critical transactions. IT and security establish the test environment and the way changes are managed. Users participate in checking the real workflow.
WCAG 2.2 describes accessibility criteria for digital content and user interfaces. It can serve as a reference framework for requirements and assessment. A framework, component library, or statement about modern development does not on its own demonstrate conformance.
A sentence such as "the system must be accessible" is not enough for a contract, demonstration, or acceptance. Procurement needs to turn the requirement into tasks that can be observed and repeated.
Start with business flows, not with a list of every screen. Select transactions carrying operational, financial, or control risk. Examples can include:
For every selected transaction, write an acceptance scenario. The scenario should include the starting state, user action, expected outcome, and assessment evidence. Avoid vague wording such as "easy to use".
1. Keyboard operation
A user needs to be able to reach all required controls and perform key actions without a mouse. The assessment covers focus order, opening and closing dialogs, selecting from a dropdown list, entering data in a field, confirming and cancelling an action. Pay particular attention to complex controls such as dates, tables, filters, autocomplete suggestions, and nested dialogs.
A measurable acceptance criterion can state: using only a keyboard, the user completes the selected transaction, including data entry, validation, error correction, and saving, without losing access to a required control.
A user working by keyboard needs to see the active control at all times. Focus should remain visible after a view change, a modal dialog opening, result filtering, or an error message appearing. Focus existing in a technical sense is not enough when the user cannot locate it.
An acceptance criterion can state: during every keyboard action, the active control has a visible indicator, and after a dialog closes, focus returns to a meaningful location in the previous workflow.
3. Screen reader support and control meaning
A screen reader needs to convey a field's name, purpose, state, and available action. A label such as "field 3" or "button" is not enough for business work. The user needs to hear, for example, the field name, whether it is required, its current value, and a message about invalid input.
An acceptance criterion can state: in the agreed test environment, the screen reader announces an understandable name and state for every control required by the selected transaction, including validation messages and confirmation of successful saving.
4. Clear errors and a route to correction
A business form must not merely tell the user that saving failed. It needs to explain the issue clearly and support finding the field that needs correction. A "save error" message without further explanation does not support reliable work, especially in a long form or when using a screen reader.
An acceptance criterion can state: after an attempt to save deliberately invalid data, the system presents or conveys an understandable message, identifies the related field, and enables return to it without moving through the entire form again.
Criteria for an accessible business form need to cover more than the appearance of a screen. Include the following items in the specification:
Not all business forms carry the same risk. A form for a one-time internal survey does not have the same risk as a form for posting, payroll, payment approval, or closing a production activity. Set priority according to frequency, criticality, number of users, consequences of error, and the availability of a reasonable alternative procedure.
Consider a hypothetical procurement process for a module that approves purchase requests. The team does not ask the supplier only for a presentation. It requests a demonstration of three pre-submitted scenarios: creating a request, correcting a required field, and approving a request.
The supplier demonstrates each scenario by keyboard. The team then checks focus visibility, error-message behaviour, and control names with a screen reader in the agreed browser and test environment. Findings are recorded against the scenario, date, delivery version, evidence, and decision owner.
If a critical action cannot be performed without a mouse, this is not a minor note. The team decides whether the supplier will correct the issue before acceptance, whether a temporary alternative procedure will be introduced, or whether the item returns to the procurement decision. Such a decision needs a named owner and a review date, but a date should not be invented in the specification before the actual scope of work is assessed.
A supplier may provide an accessibility description, documentation, results of its own testing, or a remediation plan. These materials are useful inputs, but they do not replace checking a business scenario in your context.
The internal team should verify at least the following:
A formal conformance level should not be inferred from a technology name, a supplier declaration, or a few successful demonstrations. Such a statement requires scope, method, results, and expert assessment applicable to the specific release and environment. If those elements are unavailable, it is more precise to state which scenarios the team assessed and which exceptions remain open.
Assessing every screen may be disproportionate in an initial phase, especially in a large legacy system. This is not a reason to abandon accessibility. A reasonable approach is to cover the most critical flows first, then expand scope according to risk and system changes.
An exception is not closed by the phrase "out of scope". Record the reason, affected process, users, risk assessment, temporary alternative, decision owner, and condition for reopening the matter. The alternative procedure also needs assessment: relying on a colleague as a permanent solution may affect independence, confidentiality, or timely completion of work.
In an ERP implementation, responsibility is distributed. Orkasta can hold day-to-day coordination and business priorities, the ERP team can hold official transactions and their implementation, and Trueforce can provide specialised engineering work when needed. Without clearly assigned responsibility, an accessibility finding can easily remain between the business owner, implementer, and supplier.
Before a decision and before production acceptance, record the following:
The first practical step is not a long policy. It is selecting three to five critical transactions and turning them into acceptance scenarios. When accessibility needs to be integrated into a wider process review, Business process screening can help connect business risks, responsibilities, and assessment priorities.