Accessibility often appears in software procurement as a checkbox marked “yes”. That does not show which users can complete critical tasks, which problems are known or when they will be fixed. Requirements need to be specific before a supplier is selected.
Start with critical journeys
Record the tasks that must not exclude anyone: signing in, searching, purchasing, submitting, exporting or managing an account. Ask the supplier to demonstrate these journeys rather than a carefully selected screen.
Request evidence with a defined scope
An accessibility statement or report is a starting point, not final proof. Check the date, product version, scope, methodology and known exceptions. Ask which issues remain open and which team owns them.
Test different ways of using the product
Check keyboard operation, focus, zoom, screen readers, contrast and error messages in the main workflows. Include real users where possible. An automated scan identifies some problems, but does not prove that a task can be completed.
Put the requirement in the contract
Define minimum acceptance criteria, remediation times by severity, reporting methods and the right to retest. If accessibility remains only in the sales presentation, its priority will disappear after signing.
Check changes too
The product may be acceptable today and deteriorate in the next version. Request release notes covering relevant changes, regression testing and notification when a new feature fails to meet agreed requirements.
Plan an alternative route
Where a known barrier exists, the alternative must be equivalent, quick and clear. A general instruction to “contact us” is not enough if the user loses time, privacy or the ability to help themselves.
This accessibility procurement framework is an original evaluation framework developed by DigitalNow.