Is This Business Application Accessible? A Practical Evaluation Checklist
A procurement-focused checklist for discussing accessibility before you choose a business application. Define essential work, ask vendors about the product and evidence they can share, and record questions that need follow-up. This is a decision aid, not a standards-based technical assessment.
Why include accessibility in procurement?
Business applications can support essential work, from managing records to approving requests. Accessibility is worth raising before you choose a product or plan a rollout, so that the needs of the people who will use it are part of the buying conversation.
UVA Finance describes its [Digital Accessibility Review Checklist](https://uvafinance.virginia.edu/resources/digital-accessibility-review-checklist) as a resource for purchase or contract requests that may include a digital component, such as software, tools, or content. That supports a practical procurement principle: include accessibility in the selection discussion rather than leaving it until after a decision.
- Include accessibility in the same conversation as workflow fit, security, support, and operating requirements.
- Discuss the application and modules your team expects to use, rather than relying on general statements about a product.
- Treat this article as a procurement discussion aid, not as a technical evaluation against an accessibility standard.
Describe the work your team needs to do
Start with the work people need the application to support. Describe a few important tasks in plain language and identify who expects to do them. This gives your team and the vendor a shared basis for discussing whether the product is suitable.
Where possible, involve people who will use the application and invite them to describe what they need. Do not assume that one person’s experience represents everyone’s.
- List three to five important tasks, such as creating a record, finding it again, or submitting a request.
- Note who needs to complete each task and what the work depends on.
- Identify any particular access needs or tools that staff say they rely on, without making assumptions about individuals.
- Decide who will review open questions and make the procurement decision.
Ask the vendor what information is available
Ask the vendor what accessibility information or evaluation materials it can share about the application you are considering. Ask which product areas the information covers and whether it relates to the modules and use cases your team expects to adopt.
These are questions to help you understand what information is available; they are not a prescribed evidence standard. If the material does not answer your questions, record what remains unclear and ask the vendor to explain it.
- What accessibility information or evaluation materials can you share about this application?
- Which product areas or modules do those materials cover?
- What should we know about the scope of the information and any areas it does not address?
- Can you discuss the tasks our team expects to perform and respond to questions about them?
- Record unanswered questions rather than treating missing information as proof either way.
Discuss essential workflows with the vendor
Use your list of essential tasks to guide a product discussion or demonstration. Ask the vendor to show the relevant parts of the application and explain how a user would complete each task. This keeps the conversation grounded in your team’s intended use rather than a general product overview.
This discussion can help identify questions for follow-up. It does not, by itself, establish that every part of the application is accessible or that it meets a particular technical standard.
- Ask for a demonstration of the tasks your team identified.
- Ask how the application supports the access needs your staff have raised.
- Note tasks or product areas that were not covered in the discussion.
- Record what needs further explanation or review before the buying decision.
Use product examples carefully
If you are evaluating a learning management system, Blackboard’s evaluation checklist suggests looking for features such as audio narration and adapting content to suit learners. These are examples to raise during a product discussion, not proof on their own that a system is accessible. See [Blackboard’s LMS Evaluation Checklist](https://www.blackboard.com/learning-management-system/lms-evaluation-checklist-for-business-and-government).
For other kinds of business applications, ask questions that match the work your team needs to do. Avoid assuming that an example from an LMS applies to a different product category.
- For an LMS, ask the vendor about features such as audio narration and adapting content to suit learners.
- Ask how any feature relates to the learning tasks your organization intends to support.
- For other application types, focus your questions on the product and workflows under consideration.
- Do not treat the presence of a feature as a complete accessibility assessment.
Keep a clear record of the decision
Keep procurement notes that connect the application to the work your team expects to do. Record which tasks were discussed, what information the vendor shared, what questions remain, and who will follow up.
A clear record helps your team carry unresolved questions into the next decision or planning step. It also makes it easier to distinguish what you learned from what still needs review.
- Record the application and product areas discussed.
- List the workflows and access needs raised during the conversation.
- Summarize the information the vendor provided and note what remains unanswered.
- Assign an owner and next step for each open question.
- Keep unresolved questions visible in the procurement decision and rollout planning.
Frequently asked questions
Can a small team use this checklist without an accessibility specialist?
Yes. A small team can use it to bring accessibility into procurement discussions, describe important work, and record questions for follow-up. It is a discussion aid, not a technical assessment against an accessibility standard.
Does vendor information prove that an application will meet our needs?
Not by itself. Ask what product areas and tasks the information covers, discuss your team’s intended use with the vendor, and record what remains unclear.
What should we do if we still have questions after speaking with the vendor?
Document the unanswered questions, assign someone to follow up, and keep them visible in the procurement decision. Consider whether the information available is sufficient for your organization to proceed.
Does self-hosting make an application more accessible?
The deployment model alone does not establish whether an application is accessible. Discuss the application and the workflows your team intends to use. Infrastructure arrangements and application accessibility are separate considerations.
Sources and further reading
- Digital Accessibility Review Checklist — UVA Finance
- LMS Evaluation Checklist for Business and Government — Blackboard