Third-party component evaluation
Video players, file viewers and embedded tools become part of your product the moment you ship them. We help you evaluate them before adoption, or decide what to do when a barrier appears after launch.
Third-party components are often chosen quickly and fixed slowly. Evaluating them first, against the tasks your users need to complete, makes the adoption decision clearer.
Who this is for
- Product and technology teams choosing a third-party tool to embed.
- Teams whose users or employees have reported a barrier in a tool they already use.
- Procurement and engineering leads who need to compare vendor claims with real behavior.
When teams usually get in touch
You are about to adopt a video player, file viewer or embedded tool, or you are already using one and need to decide whether to configure it, replace it or take the issue to the vendor.
What is in scope
- Evaluation of the specific component in the context where you use it, against the parts of WCAG 2.2 that apply.
- Comparison of what the vendor documents with how the component behaves.
- Review of the configuration options that affect accessibility.
- Where useful, comparison of alternatives you are considering.
How we approach it
- Agree the component, version, platforms and the tasks your users need to complete.
- Review the vendor's accessibility documentation, then test the component against those tasks.
- Identify which problems can be addressed through configuration or integration, and which sit in the vendor's product.
- Present the findings with a clear recommendation and the questions worth putting to the vendor.
Likely deliverables
Exact deliverables are agreed when we scope the work. They may include:
- Findings for the tasks and contexts reviewed, with the reasoning behind each.
- A recommendation to adopt, configure, replace or escalate, and why.
- Questions and evidence you can bring to the vendor.
- Interim approaches for affected users, where they exist.
Limitations
- We can recommend, but we cannot change a vendor's product, and a vendor may not act on what you raise.
- Results apply to the version, configuration and context reviewed. Vendors update their products.
- Contract negotiation and legal advice are outside this offer.
- It is not a certification or a guarantee of compliance or of any particular outcome.
What helps us scope
- Access to the component, or a test environment where it is configured as you use it.
- The vendor's accessibility documentation, if they publish any.
- The tasks your users need to complete with it.
- Your decision timeline, for example a purchase or launch date.
How scoping starts
Scoping starts with a free introductory conversation about the component, your context and your timeline. If it looks like a fit, we agree the scope together before any work begins.
Questions teams ask
Can you tell us whether to buy a particular product?
We can give you accessibility findings and a recommendation about the component. The decision to buy also depends on factors outside our scope, such as cost, security and fit.
What if the vendor will not fix the problem?
That is a real possibility. The evaluation helps you decide between configuring around it, replacing the component or accepting a documented risk.
Do you test with assistive technology?
What is tested is agreed during scoping, based on your users and platforms. We will state what was and was not covered in the findings.
Have a project in mind?
Start with a free introductory conversation about what you are building, buying or publishing. If it looks like a fit, we agree the scope together before any work begins.