Accessibility is the item that appears in a procurement checklist as four words and returns eighteen months later as a remediation project. It is also the one obligation on this list that is routinely justified with the wrong piece of law.
This guide sets out which regime applies, what evidence to demand before signature, how to read that evidence, and the clauses that make remediation enforceable. Seven steps, each with a named owner and the artefact it produces.
First, the correction: it is probably not the European Accessibility Act
The EAA is invoked constantly in edtech procurement papers, and for a university platform it is usually the wrong instrument.
The European Commission’s own page lists what the EAA covers: computers and operating systems; ATMs, ticketing and check-in machines; smartphones; TV equipment related to digital television services; telephony services and related equipment; access to audio-visual media services; services related to air, bus, rail and waterborne passenger transport; banking services; e-books; and e-commerce. Member States had to incorporate it into national law by June 2022.
Educational platforms are not on that list. Read the list before you cite the Act, because a committee paper resting on a directive that does not apply is a paper that gets sent back.
The instrument that does reach you is the Web Accessibility Directive. It has been in force since 22 December 2016 and, in the Commission’s words, “obliges websites and apps of public sector bodies to be ‘more accessible’, providing a technical standard which clarifies what is ‘accessible’.” Most European universities are public sector bodies. All Member States have transposed it; the deadline was 23 September 2018.
The two regimes are complementary rather than alternative — the Commission describes the WAD as complementing the EAA, which reaches a wide range of private-sector products and services. Establish which applies to you in writing, once, and stop re-litigating it in every tender.
What the Directive actually requires
Three obligations, and the first two are the reason vendor evidence is a procurement matter rather than an operational one.
- An accessibility statement for each website and mobile app, “stating non-accessible content and alternatives as well as contacts”. A model statement is established by Commission Implementing Decision (EU) 2018/1523.
- A feedback mechanism “so users can flag accessibility problems or request information published in a non-accessible content”.
- Regular monitoring of public sector websites and apps by Member States, who report results to the Commission every three years. The methodology and reporting arrangements are set by Commission Implementing Decision (EU) 2018/1524.
Sit with obligation one. You must publish a statement naming what is not accessible. If a third-party platform is embedded in your estate and the supplier has given you nothing, you cannot write a truthful statement about it — and the statement is published under your name, not theirs. That is the whole argument for making conformance evidence a condition of award.
The Directive also foresees a limited number of exceptions, including broadcasters and live streaming. Check whether anything in your scope falls inside them rather than assuming it does not.
The seven steps
Step 1 — Establish and record which regime applies
Owner: legal or the data protection office, jointly with the accessibility lead.
Artefact: a one-paragraph statement of the applicable obligation, its national transposition, and the standard you will test against.
Do this once per institution rather than once per tender. National transposition varies, and there may be a domestic equality or disability duty that bites harder than the Directive. That paragraph then goes into every subsequent specification unchanged.
Step 2 — Put the evidence requirement in the specification, not the evaluation
Owner: procurement.
Artefact: a mandatory requirement clause naming the standard, the report format and the currency of the report.
A requirement in the specification excludes non-compliant bids. A criterion in the evaluation merely scores them, which means the cheapest bid can win with an accessibility gap and a promise. Name the standard explicitly: EN 301 549 V3.2.1 (2021-03), the harmonised European standard for “Accessibility requirements for ICT products and services”, is the right reference point for European institutions, and the harmonised standard route provides the presumption of conformity.
Step 3 — Demand a report that is dated, versioned and scoped
Owner: procurement.
Artefact: the vendor’s conformance report, with the three attributes below confirmed in writing.
- Dated. A report from three product releases ago describes software you are not buying.
- Versioned. It must name the release you will deploy.
- Scoped. It must cover the authenticated workflows your users will actually perform, not the vendor’s public marketing site. This is the single most common defect in submitted evidence.
If the vendor supplies a self-assessment, that is normal in this market and not disqualifying. Record that it is a self-assessment.
Step 4 — Read the report for its qualifiers, not its headline
Owner: the accessibility or disability service.
Artefact: an annotated copy listing every partial or negative finding.
Conformance reports are written in three states — broadly, a criterion is supported, partially supported, or not supported. The document’s value is entirely in the second and third categories and in the explanatory notes attached to them. A report showing full support against everything deserves more scrutiny than one showing honest gaps, because mature products have known limitations and vendors who document them are the ones managing them.
Extract every “partially supports” into a list. That list is the raw material for both your accessibility statement and your remediation clause.
Step 5 — Test the journeys that matter, with real assistive technology
Owner: the disability service with IT, ideally including users of assistive technology.
Artefact: a short tested-journeys report — journey, technology used, outcome, severity.
Pick the four or five paths a user cannot avoid: sign in through your identity provider, reach the main working area, complete the core task, submit, and retrieve feedback. Test with a screen reader and with keyboard only. An automated scan is a useful first pass and finds perhaps a third of real problems; it will not tell you that a critical control is unreachable without a mouse.
Run this inside the departmental pilot rather than as a separate exercise — the pilot already assembles the participants and the environment, and the method is in our guide to running a departmental pilot of an AI writing tool.
Step 6 — Turn the gaps into contract terms
Owner: procurement with legal.
Artefact: a remediation schedule annexed to the agreement.
Three clauses do the work:
- A dated remediation commitment for each identified gap, by severity, with the fix in the vendor’s published roadmap rather than in an email.
- A no-regression undertaking: conformance is maintained across releases, and a new release that breaks an accessible path is a defect rather than a change request.
- An evidence-refresh obligation: an updated report at an agreed interval and on major release, supplied without being chased.
Refuse, in turn, a conformance claim with no report behind it; a report scoped to the marketing site; and any attempt to charge for accessibility remediation as customisation. Accessibility is not a bespoke feature request — the wider list of things to refuse is in what an institutional licence should actually buy you.
Step 7 — Publish the statement and wire up the feedback route
Owner: the web team, with a named accessibility contact.
Artefact: the published statement and a monitored inbox with a service standard.
Write the statement from your step 4 and step 5 findings, name the alternatives available for non-accessible content, and give a real contact. Then make sure the feedback mechanism reaches someone who can act — a form that routes to an unmonitored queue satisfies the letter of the requirement and none of its purpose. Set the review date at the same time, aligned to the three-year monitoring cycle rather than to your procurement calendar.
One honest note on sources
Everything above about the two directives and their implementing decisions is taken from the European Commission’s own pages, and the EN 301 549 reference is taken from the published standard itself, read in August 2026.
We also attempted to read the W3C’s current accessibility guideline documentation directly and could not — the pages returned an automated challenge rather than content. We are therefore citing the harmonised European standard rather than paraphrasing guideline text we could not verify at source. If your specification needs to name a guideline version, take it from the standard your national transposition references, not from a secondary summary.
What this costs you
Roughly a day of coordinated effort spread across three teams, almost all of it before signature. Compare that with the alternative: discovering after deployment that a required workflow is unusable for part of your population, with a signed contract, no remediation clause, and a published statement you cannot write honestly.
Run it in parallel with the data protection review rather than after it. Both draw on the same vendor evidence pack and the same committee cycle, and the sequencing for that review is in how to run a data protection review before deploying an AI writing tool. The questions to send alongside them are in our procurement question bank.
If you would like the conformance evidence for a specific deployment scope before any commitment, request an institutional evaluation and we will supply it against the workflows you name.
Frequently asked questions
Does the European Accessibility Act apply to our learning platform?
Probably not directly. The Commission’s list of covered products and services runs to computers, ATMs, smartphones, TV equipment, telephony, audio-visual media, transport, banking, e-books and e-commerce. Educational platforms are not named.
Which directive does apply?
The Web Accessibility Directive, in force since 22 December 2016, obliging the websites and mobile apps of public sector bodies to be more accessible. Most European universities are public sector bodies.
What must we publish?
An accessibility statement for each website and mobile app stating non-accessible content and alternatives with contacts, plus a feedback mechanism for users to flag problems or request information published in non-accessible form.
Is there a model for the statement?
Yes. Commission Implementing Decision (EU) 2018/1523 establishes a model accessibility statement, and 2018/1524 establishes the monitoring methodology and reporting arrangements.
How often is compliance monitored?
Member States monitor periodically and report the results to the Commission every three years.
Which technical standard should we name?
EN 301 549 V3.2.1 (2021-03), the harmonised European standard for accessibility requirements for ICT products and services. A harmonised standard provides the presumption of conformity.
Is a vendor self-assessment acceptable?
It is normal in this market and not disqualifying. Record that it is a self-assessment, and weight it accordingly against your own testing.
What is the most common defect in submitted evidence?
Scope. Reports are frequently written against the vendor’s public marketing site rather than the authenticated workflows your users will perform.
Are automated scans sufficient?
No. They are a useful first pass but will not reveal that a critical control is unreachable by keyboard, which is the class of failure that stops a user completely.
Should accessibility be a requirement or an evaluation criterion?
A requirement in the specification. A criterion only scores a bid; a requirement excludes one, which is the difference between a preference and an obligation.
Can a vendor charge for accessibility remediation?
Refuse it. Meeting a published conformance claim is not customisation, and treating it as chargeable turns your legal obligation into their revenue line.
What happens if a new release breaks accessibility?
That is why the no-regression undertaking matters. Without it, a regression is a change request with a price; with it, it is a defect with a fix.
Who should own this in the institution?
A named accessibility lead with a route into procurement. Where ownership is split between IT, the disability service and the web team, the evidence requirement reliably falls between them.