At a glance
- Test complete employee journeys, not just a polished product demonstration.
- Ask suppliers exactly which product version, interface, platform, and assessment their accessibility evidence covers.
- Retest the configured service after changes to workflows, documents, integrations, or authentication.
HR software can pass a polished demonstration and still leave an employee unable to submit an application, correct bank details, read a payslip, or finish required training. The problem often appears in the real journey: authentication, a custom field, an uploaded document, or a third-party tool that sits outside the supplier’s headline claim.
That is why an accessibility statement should start the conversation, not settle the buying decision. HR and procurement teams need to test the tasks people actually complete, using the configured workflows and access methods they will rely on after launch.
Ask what the evidence actually covers
Request a current accessibility conformance report where the supplier provides one. Check the product version, interfaces, platforms, and assessment date. Ask who performed the evaluation, what methods they used, and which limitations remain open. A report for the employee portal may say little about the recruiting site or mobile application.
The W3C WCAG overview explains that WCAG has testable success criteria at different conformance levels. A vague “WCAG compliant” answer does not tell you the version, level, scope, or known exceptions. Ask for that detail in your HR software RFP.
Keep technical standards separate from legal conclusions. Identify the requirements that apply to your organization with the appropriate specialists, then ask the supplier to show how its product supports them. Buying a product does not automatically settle the accessibility of everything you configure inside it.
Follow an employee through a complete task
Choose tasks with consequences: submitting an application, correcting a bank detail, reading a payslip, requesting an accommodation, or completing required learning. Include login, navigation, data entry, error recovery, confirmation, and any document the person must download.
Try the task using a keyboard without a mouse. Check whether the current focus is visible and whether it moves in a sensible order. Explore the experience with assistive technology and users who understand it. Enlarging text or changing the viewport should not make essential controls disappear.
| Task | What to observe | Question for the supplier |
|---|---|---|
| Complete a form | Labels, instructions, errors, and confirmation | Can someone recover without losing their work? |
| Choose a date | Keyboard operation and understandable announcements | Is an alternative to the visual picker available? |
| Upload a document | Clear requirements and useful error messages | What happens when the upload fails? |
| Read a payslip | Document structure and access | Is the generated document usable with assistive technology? |
| Finish learning | Captions, controls, assessments, and timing | Does the entire course work, not just the LMS menu? |
A test should capture the barrier, its effect on the person, and how to reproduce it. “Accessibility issue” is less helpful than “the employee cannot reach the Submit button with a keyboard after opening the date selector.”
Test your configuration, not only the standard product
Custom fields, branding, third-party assessment tools, embedded videos, and uploaded PDFs can change the experience. Ask which changes the supplier controls and which become your responsibility. Find out whether administrators receive useful warnings or guidance when creating content.
Your employee self-service design should also reduce unnecessary complexity. Clear language, visible progress, and sensible error messages help many users. They do not replace technical accessibility testing, but they make the workflow easier to understand and support.
Authentication deserves its own test. An accessible form is of little use if the person cannot get through the sign-in process or recover their account. Work with IT on the whole journey, including any external identity service.
Give employees a way to influence the decision
Involve people with relevant access needs without making them responsible for certifying the product. Explain what you are testing, make participation voluntary, and provide a straightforward way to report difficulty. A short session with a real task can reveal friction that a generic feature demonstration misses.
Pay attention to the workaround. If an employee must tell a manager private information because they cannot use the normal form, the barrier has created a second problem. If someone else has to complete every training module on their behalf, the completion record no longer describes the learning experience you intended.
This is why accessibility belongs beside security and permissions, not in a forgotten appendix. The system must make the right work possible for the right person.
Make remediation specific
Ask the supplier to identify the affected functions, planned fixes, expected delivery, and available alternatives. Distinguish a confirmed fix from a roadmap ambition. Record how you will retest after the change and who will decide whether an interim approach is workable.
Avoid treating all issues as equivalent. Prioritize barriers that prevent essential tasks or expose sensitive information, while keeping other issues visible. A procurement score should not allow attractive features to cancel out an inability to perform a necessary task.
After purchase, include accessibility in release testing and content maintenance. New workflows, documents, and authentication changes can introduce new barriers. The useful outcome is a service employees can continue to use, with a clear route to help when something gets in the way.
