Your Voluntary Product Accessibility Template Guide for 2026

An RFP from a university or college usually looks routine until you reach the accessibility requirements. Then one line stops the whole process: provide a current VPAT.

If you're an EdTech product manager, that request can feel bigger than it sounds. You're not just being asked for a form. You're being asked for a defensible record of how your product behaves for keyboard users, screen reader users, caption users, and buyers who need evidence they can rely on.

That's where many teams go wrong. They treat the voluntary product accessibility template as an admin task, fill in a few support ratings, and submit something that reads like marketing copy. UK education buyers rarely accept that at face value. They need detail, context, and enough specificity to support their own accessibility obligations.

What Is a VPAT and Why It Matters for Your Video Platform

A Voluntary Product Accessibility Template is the standard template used to produce an Accessibility Conformance Report, or ACR. In practice, buyers often ask for a “VPAT”, but the document they expect to receive is the completed report.

For a video platform, that report matters because accessibility questions go far beyond whether the interface “works”. Buyers want to know whether a student can operate the player by keyboard, whether captions are supported, whether transcripts are available where relevant, whether status messages are exposed properly to assistive technology, and what happens when something only partially meets the standard.

The VPAT has become a mainstream procurement document, not a niche US artefact. The Information Technology Industry Council says the completed ACR is the “leading global reporting format” for identifying accessible ICT products, which is why UK education and public-sector buyers often treat it as a foundational procurement artefact when the evidence is specific, current, and tied to recognised standards (ITI VPAT overview).

That practical shift matters for any supplier selling into higher education. A purchasing team may begin with the VPAT, but they'll often use it to decide whether your product deserves a deeper technical review, a demo, or a place on the shortlist.

Practical rule: If your ACR sounds like a brochure, buyers will assume the testing was shallow.

A strong ACR does three jobs at once:

• It reduces buyer uncertainty. It tells the institution what was tested, against which standard, and where limitations remain.

• It shows operational maturity. Teams that can describe exceptions and remediation plans usually manage accessibility better than teams claiming blanket support.

• It supports internal procurement conversations. Accessibility leads, IT teams, teaching staff, and procurement officers need a common document they can all review.

For vendors in learning technology, the best way to think about a VPAT is simple. It's not a badge. It's evidence. If your public accessibility information still lives mostly in general statements, start by reviewing your wider accessibility approach and then build the report from actual testing.

Mapping Accessibility Standards to Video Platform Features

The standards can look abstract until you map them to product behaviour. For a video platform, that translation work is essential. Otherwise teams write reports that repeat standard names without saying anything useful about the player, uploader, editor, admin screens, or embedded learning workflows.

What the standards mean in practice

For most video products, buyers will care about three overlapping frameworks:

• WCAG 2.1 AA as the main web accessibility benchmark

• Section 508 because many VPAT habits and templates come from US procurement practice

• EN 301 549 because UK public-sector procurement decisions are assessed against that framework

The easiest working model is this: WCAG tells you much of what good web accessibility looks like, while EN 301 549 is the procurement-facing standard many UK buyers need to apply to ICT products.

A video platform touches all four WCAG principles:

• Perceivable means users can access information through captions, transcripts, readable controls, visible focus, and clear labels.

• Operable means the player, uploads, media library, quizzes, and settings work by keyboard without traps.

• Understandable means labels are consistent, instructions are clear, and interactive controls behave predictably.

• Compatible means the interface exposes names, roles, values, and status changes properly to assistive technology.

If your product includes caption editing, lecture capture, live streaming, LMS embeds, and browser-based trimming, each of those surfaces needs its own accessibility review. Teams often test only the player and forget the rest of the workflow.

A practical mapping for video products

The table below gives a useful starting point for testing and documentation.

WCAG 2.1 AA Criterion	Requirement for Video Platforms	Example in MEDIAL
1.1.1 Non-text Content	Buttons, thumbnails, icons, and waveform controls need meaningful text alternatives	Media library action icons and player controls need accessible names
1.2.2 Captions (Prerecorded)	Prerecorded video with audio needs captions	Uploaded lecture recordings should support closed captions
1.2.3 Audio Description or Media Alternative	Users need access to equivalent information for visual-only meaning where relevant	Instructional videos with important on-screen visuals may need description support or a suitable alternative
1.3.1 Info and Relationships	Headings, forms, tables, and control groups must be coded semantically	Upload forms, settings panels, and analytics views need proper structure
1.4.3 Contrast (Minimum)	Text and control states must remain readable	Player buttons, timestamps, and menus need sufficient contrast
2.1.1 Keyboard	All core actions must work without a mouse	Play, pause, seek, volume, caption toggle, and menu access should be keyboard operable
2.4.3 Focus Order	Keyboard focus must move in a logical order	Focus should move sensibly through player chrome, transcript panel, and surrounding page controls
2.4.7 Focus Visible	Users must be able to see where focus is	Active control indicators in the player and admin interface need a clear visible state
3.3.1 Error Identification	Form errors must be identified clearly	Upload failures or missing required metadata should be announced and described
4.1.2 Name, Role, Value	Custom controls must expose programmatic information correctly	Custom player buttons and sliders must work with screen readers
4.1.3 Status Messages	Updates must be announced without forcing focus changes	“Upload complete”, “caption file added”, or “processing failed” should be exposed to assistive tech

A second useful exercise is feature-by-feature mapping. Don't ask, “Is our platform WCAG compliant?” Ask narrower questions:

• Player controls: Can a student start playback, change volume, toggle captions, and move focus predictably?

• Media management: Can an administrator upload, rename, replace, and organise assets without relying on drag-and-drop alone?

• Live sessions: Are scheduling, recording, and join flows usable with keyboard and assistive technology?

• LMS embeds: Does the embedded experience preserve labels, headings, and focus behaviour inside Moodle, Canvas, Blackboard, or Brightspace?

When a buyer asks for accessibility evidence, they're rarely asking about your homepage. They're asking about the job the user must complete.

If you work with video and caption workflows, it also helps to understand the wider legal context around media accessibility. A practical primer on video captioning laws and accessibility expectations can help product teams connect standards language to real platform features.

How to Gather Evidence for Your Accessibility Report

A credible report starts long before anyone opens the template. The hard part isn't choosing “Supports” or “Partially Supports”. The hard part is assembling evidence that justifies the choice.

Start with the user journeys buyers care about most. For a video platform, that usually means logging in, uploading media, playing content, enabling captions, editing metadata, embedding or sharing media, and completing a student-facing task inside the LMS.

Build an evidence locker, not a memory

Treat every finding as something you may need to explain later to procurement, legal, engineering, or a customer success team. That means collecting proof in a way others can review.

Use a simple structure:

1. Define the scope. Record product name, version, environment, browser, assistive technologies used, and which flows were tested.

2. Run automated checks. These help catch obvious issues such as missing form labels, contrast problems, or heading errors.

3. Run manual keyboard testing. Tab through every core workflow. Check focus order, visibility, trapped focus, and operation of custom controls.

4. Test with screen readers. Focus on actual user tasks, not isolated widgets.

5. Capture evidence. Save screenshots, short clips, defect tickets, and notes showing pass and fail conditions.

6. Link findings to criteria. Each issue should map to a standard requirement and a product location.

A lot of teams skip step six. That's why their ACR remarks become vague. They know there's “an issue in uploads” but can't say which criterion it affects or whether it blocks task completion.

For teams improving media workflows, it's worth looking at how features such as AI-assisted captioning and accessibility enhancements fit into evidence gathering. Features don't count as proof by themselves. What matters is how they perform in use.

What to collect during testing

Don't overcomplicate your evidence pack. A small, organised set of artefacts beats a chaotic folder of screenshots.

• Test logs: Record the page, feature, criterion, expected behaviour, observed result, and impact.

• Short recordings: Capture keyboard movement, focus loss, or screen reader output where that helps explain the problem.

• Defect references: Link accessibility issues to your development tracker so buyers can see the work is managed, not ignored.

• Version notes: If one issue is already fixed in a pending release, record that separately rather than pretending it's already resolved.

This video is a useful companion if your team needs a visual overview of accessibility reporting practice.

https://www.youtube.com/embed/7fVlXOKMOoI

What works and what doesn't

What works is repeatable testing on common user flows with evidence attached.

What doesn't work is relying only on automated scans, testing only the marketing site, or asking developers whether they think a control is accessible. A buyer reviewing your report can usually tell the difference very quickly.

Filling Out Your Voluntary Product Accessibility Template

Once the evidence is organised, the template becomes much easier to complete. The key is to write for a sceptical but fair reader. They want honest reporting, not polished reassurance.

Start with the front matter

Before the criteria tables, get the basics right:

• Product identification: exact product name, version, and modules covered

• Report date: so buyers can judge whether it's current

• Evaluation methods: manual testing, automated checks, assistive technology testing, and any scope limits

• Contact route: a real accessibility contact, not a generic sales mailbox

This information sets the tone. If the report can't clearly say what was tested, when, and how, confidence drops immediately.

Use conformance levels carefully

Most reports use these ratings:

Conformance level	When to use it	Common misuse
Supports	The feature meets the requirement in the tested scope	Used when only some pages or components pass
Partially Supports	Some parts conform, but there are meaningful exceptions	Used as a soft way to hide serious blockers
Does Not Support	The requirement is not met in a meaningful part of the tested experience	Avoided because teams fear it looks bad
Not Applicable	The criterion genuinely does not apply to the product or feature	Used to skip hard criteria that actually do apply

The trade-off is simple. A report with a few well-explained “Partially Supports” entries is often more credible than one that claims universal support.

Buyer test: If the remarks column disappeared, would the rating still make sense? If not, the entry isn't finished.

Write remarks that help a purchaser make a decision

The remarks column carries most of the value. Ratings alone don't tell a university whether the issue affects lecture playback, student submissions, admin management, or only an edge case.

Compare these two styles.

Weak remark

• Supports. The platform is accessible and follows best practice.

Useful remark

• Partially Supports. Keyboard users can start and pause playback, adjust volume, and toggle captions. In the tested version, focus on the seek control is visible but the current time announcement is inconsistent in one browser and screen reader combination. A workaround is available through standard play controls while a fix is in progress.

The second example gives a buyer something they can work with. It says what passes, what doesn't, where the limitation appears, and how severe it is.

Use feature-level honesty

For video products, the highest-risk areas usually include custom media players, drag-and-drop upload interfaces, live-session controls, transcript panels, caption editors, and LMS embeds.

A practical way to write those entries is:

• name the component

• describe what was tested

• state the outcome

• explain any exception

• note user impact or workaround if relevant

For example:

• Player keyboard access: “Supports. Core playback controls were operable by keyboard in the tested browser set.”

• Caption editing panel: “Partially Supports. The editor is usable by keyboard for text entry and timing review, but one toolbar control lacked a clear accessible name during testing.”

• Drag-and-drop upload: “Partially Supports. Users can upload through the file picker without relying on drag-and-drop, though one status update was not announced consistently.”

Keep scope under control

A single ACR should not pretend to cover every integration, deployment option, plugin, and custom client configuration unless those were tested.

That's especially important for products used inside learning environments. An embedded player inside an LMS might behave differently from the standalone portal. If your report covers only one of those contexts, say so plainly.

The voluntary product accessibility template rewards precise scoping. Broad claims create risk. Narrow, documented claims build trust.

Seven Common VPAT Pitfalls You Must Avoid

Bad ACRs usually fail in the same ways. Not because teams don't care, but because they rush, overstate, or confuse accessibility evidence with product messaging.

The mistakes that damage credibility fastest

1. Blanket “Supports” ratings If a player passes but the caption editor fails keyboard testing, the product does not “Support” everything.

2. Remarks written like marketing copy Phrases such as “designed with inclusivity in mind” tell the buyer nothing about conformance.

3. Reports that don't match the current version If the interface changed, the evidence may no longer be reliable.

4. Testing only the public website Buyers care about the authenticated product experience, especially for staff and students.

5. Using “Not Applicable” to dodge difficult criteria If your platform delivers video, media criteria probably apply somewhere.

6. No explanation of exceptions A partial support entry without detail leaves procurement teams guessing.

7. No traceable evidence behind the ratings If engineering, support, and sales can't explain the entry, the report is fragile.

Why this matters in UK procurement

In the UK, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 required public-sector websites to publish accessibility statements, taking effect on 23 September 2018, with new public-sector websites covered from 23 September 2019 and existing ones from 23 September 2020. Those rules created demand for structured accessibility evidence aligned to WCAG 2.1 AA and comparable reporting, which is why public bodies and education buyers increasingly expect documentation that records conformance, exceptions, and remediation plans (CMS summary of accessibility reporting context).

That's the part many vendors miss. A vague or inaccurate ACR doesn't just look untidy. It can be treated as inadequate evidence.

A procurement team can live with limitations they understand. They won't trust limitations you hide.

A quick self-audit before submission

Ask these questions before you attach the report to an RFP response:

• Is the report current? Product version and date should match what the buyer will receive.

• Is each exception located? The buyer should be able to tell which feature is affected.

• Could a technical reviewer reproduce the claim? If not, the statement is probably too vague.

• Does the report separate known limitations from planned fixes? Hope is not evidence.

The fastest way to weaken a voluntary product accessibility template is to treat it as a compliance script. Good buyers read it as a technical disclosure.

Leveraging Your VPAT for RFPs and Procurement

A strong ACR isn't just there to get past a mandatory upload field. It can shape the whole procurement conversation.

Use it early, not defensively

The best vendors don't wait for the buyer to discover accessibility late in the process. They introduce the ACR alongside product demos, implementation discussions, and security documentation.

That changes the tone. Instead of sounding reactive, the team shows that accessibility is managed, documented, and open to scrutiny.

A practical submission pack often includes:

• The ACR itself: current, scoped, and dated

• A short cover note: summarising tested areas, known exceptions, and who can answer follow-up questions

• Supporting material: demo access, testing notes, or a session with a product specialist if the buyer asks

Think like a UK buyer

Authoritative guidance stresses that a VPAT or ACR is only a starting point for procurement, not definitive proof. Organisations are advised to pair it with demos and testing, which matters in the UK because public-sector buyers must assess digital accessibility against EN 301 549 and need clear, verifiable evidence for a defensible procurement decision (University of Missouri guidance on validating a VPAT).

That buyer perspective changes how you should write the report. Procurement teams may ask:

• Can we see the feature that was marked “Supports”?

• Does the report cover the LMS-integrated workflow or only the standalone product?

• Are known accessibility issues documented and prioritised?

• Can the vendor explain how the ACR maps to the product we are buying?

If your ACR already anticipates those questions, sales conversations move faster.

What helps close the gap between report and trust

The most effective approach is to make validation easy.

• Offer a guided accessibility demo: Show keyboard-only use, captions, focus states, and a screen reader-tested workflow.

• Prepare engineering-backed answers: Sales alone shouldn't have to explain technical entries.

• Keep remediation notes ready: Buyers often accept limitations better when the vendor can discuss them openly and specifically.

A voluntary product accessibility template becomes commercially useful when it helps a buyer say yes with confidence. Not because the product is perfect, but because the evidence is clear enough to support a responsible decision.

Building Trust Through Transparent Accessibility

The true value of an ACR isn't the template itself. It's the discipline behind it.

When a team tests carefully, documents accurately, and explains limitations without spin, buyers notice. That matters in education, where institutions need technology that works for diverse learners and can stand up to internal scrutiny. The strongest reports don't claim perfection. They show that accessibility is part of product practice, release management, and customer trust.

---

If you're reviewing your video platform's accessibility evidence or preparing for a UK education procurement, MEDIAL can help you see what a more transparent, accessibility-aware media workflow looks like in practice. Explore the platform, review its approach, or book a demo to assess how it fits your institution's teaching, learning, and compliance needs.