European Accessibility Act & Course Evaluation Software: A 2026 Compliance Buyer's Guide

Course evaluation is a digital service you provide to every enrolled student. If a blind student using a screen reader, a student with a motor impairment using keyboard-only navigation, or a student with low vision cannot complete your end-of-semester survey, you have not collected "low response from that group" — you have built a systematic non-response bias into your quality data and, in most European institutions, breached an accessibility obligation you are already under.

This guide answers the question procurement and QA teams actually ask in 2026: which accessibility law binds our course evaluations, what is the real technical bar, and what conformance evidence must we demand from a vendor before we sign?

The short answer

• The operative technical standard is WCAG 2.1 Level AA, delivered through the European harmonised standard EN 301 549. This is the same bar across every relevant EU accessibility instrument — it does not change depending on which law names you.
• For most EU public universities, the binding instrument is the Web Accessibility Directive (2016/2102) — not the European Accessibility Act. It already requires WCAG 2.1 AA on public-sector websites and applications, and has done so for years.
• The European Accessibility Act (Directive 2019/882), in force since 28 June 2025, raises the private-sector baseline. It does not enumerate "higher education course evaluation" as a covered service, but it does bind many software vendors and private providers, and it has made accessible-by-default the market expectation for the tools you buy.
• Do not let a vendor sell you on "EAA-mandated" urgency, and do not let your own team conclude "the EAA does not list us, so we are fine." Both are wrong. The requirement reaches you through the Web Accessibility Directive and equal-treatment law regardless. The correct procurement position is: specify EN 301 549 / WCAG 2.1 AA conformance and demand the evidence, whichever law is your hook.

Why this matters more than most buyers assume

Disability is not a small edge case in a student population. National and EU survey data consistently put the share of higher-education students reporting a disability, long-term health condition, or specific learning difference in the mid-teens percentage range. If your evaluation instrument is even partially inaccessible, that cohort's voice is quietly missing from the very data you use to judge teaching quality, revalidate programmes, and feed accreditation reports. Inaccessibility does not announce itself as an error — it shows up as a demographic simply not responding.

Accessibility is therefore both a legal requirement and a data-validity requirement. The two arguments reinforce each other, and both point at the same procurement checklist.

Which law binds you — a decision map

Your institution	Primary binding instrument	Technical requirement
Public / state-funded university (most of the EU/EEA)	Web Accessibility Directive 2016/2102	WCAG 2.1 AA via EN 301 549
Private higher-education provider serving EU consumers	European Accessibility Act 2019/882 (where its services apply) + national equal-treatment law	WCAG 2.1 AA via EN 301 549
Software vendor selling into the EU	European Accessibility Act 2019/882 (for covered products/services)	EN 301 549 conformance
UK institution	Public Sector Bodies Accessibility Regulations 2018 + Equality Act 2010	WCAG 2.1 AA (WCAG 2.2 increasingly expected)

The practical point of the table: the destination is the same everywhere — EN 301 549, which incorporates WCAG 2.1 Level AA for web content essentially verbatim. EN 301 549 V3.2.1 (March 2021) is the version cited in the Official Journal of the EU. Whether your legal route is the Web Accessibility Directive, the EAA, or domestic disability-discrimination law, the software must clear that bar.

The three layers accessibility has to reach

Buyers routinely check only the first layer. All three are in scope.

1. The instrument the student answers. Every question type, rating control, open-text field, progress indicator and error message must be perceivable and operable with a keyboard and a screen reader. This is where traditional survey tools most often fail: dense Likert grid/matrix questions are notoriously hard to navigate with assistive technology, because the association between a row (the item) and a column (the rating) is easily lost by a screen reader.
2. The response channel. Email invitations, reminder flows, QR-code entry points and any authentication step must themselves be accessible, and must not force a single modality (for example, a QR-only entry with no accessible link).
3. The staff-facing side. Dashboards, exported reports and the analysis interface used by faculty and QA staff are also covered — accessibility law does not stop at the student. A report a partially-sighted programme director cannot read is as much a conformance gap as an inaccessible survey.

Requirement → what to demand in procurement

EN 301 549 / WCAG 2.1 AA area	What it means for course evaluation	What to require from the vendor
Perceivable (contrast, text alternatives)	Sufficient colour contrast; no meaning conveyed by colour alone; alt text on any images/icons	Documented contrast ratios; screen-reader labels on all controls
Operable (keyboard, no traps, timing)	Full keyboard completion; no time limits that cannot be extended; visible focus	Keyboard-only completion demo; no un-extendable timers
Understandable (labels, errors, language)	Clear labels; error identification and suggestions; declared page language	Programmatic labels; accessible error handling
Robust (assistive-tech compatibility)	Works with JAWS/NVDA/VoiceOver and standard AT	Named AT tested and versions
Conformance evidence	Proof, not marketing	A current EN 301 549 VPAT / Accessibility Conformance Report (ACR)
Accessibility statement	Legal artefact under WAD/EAA	Published statement + feedback/remediation route

The single most important line in that table is the VPAT / Accessibility Conformance Report. A "we are WCAG compliant" line on a marketing page is not evidence. A dated, versioned EN 301 549 VPAT that lists each success criterion as Supports / Partially Supports / Does Not Support is.

Where the main vendors stand (verify current documents)

Represented honestly, and to be confirmed against each vendor's current documentation at the time you buy:

• Explorance Blue publishes a Section 508 and EN 301 549 VPAT (for example, an Accessibility Conformance Report covering Blue 7.13 against WCAG 2.0/2.1). This is the kind of artefact you should expect — request the version matching the release you would deploy.
• EvaSys markets accessibility (WCAG-aligned online surveys) and is widely used across the public DACH sector where the Web Accessibility Directive already applies; ask for its current conformance report rather than relying on the marketing claim.
• General-purpose survey platforms (Qualtrics, and similar) typically maintain VPATs, but their default question library includes complex matrix questions that can be built inaccessibly by the survey author — meaning tool conformance does not guarantee instrument conformance. Your survey design still has to be accessible.

The honest takeaway: several established vendors can produce a VPAT. Conformance is table stakes, not a differentiator. The differentiator is whether the format itself fights against accessibility or works with it.

How Koji's format maps to accessibility

Koji for Education replaces the static Likert grid with an AI-moderated conversational interview — a text-based, one-question-at-a-time exchange. That format has structural accessibility advantages, and we frame them precisely rather than as a compliance guarantee:

• No dense matrix grids. The most common assistive-technology failure mode in course evaluation — the rating grid — simply is not present. One clear prompt, one response field, sequentially. This is inherently easier to navigate with a screen reader than a 12-row × 5-column table.
• Plain-language, adaptive prompts. Follow-up questions are generated in clear language and can adapt to the respondent, which supports students with cognitive and specific learning differences.
• A single, consistent interaction pattern rather than a page of heterogeneous widgets, reducing the surface area where an inaccessible control can hide.

What we will not claim is that any format is automatically conformant. Require an EN 301 549 conformance statement from every vendor you shortlist — including Koji. The right question in your RFP is identical for all of us: "Provide your current EN 301 549 / WCAG 2.1 AA Accessibility Conformance Report for the release we would deploy, and name the assistive technologies you test against." Koji shares the same AI interview engine as the main Koji research platform, so accessibility and data-handling questions can be answered once across both education and general user-research use.

When a competitor may be the better choice

• If you run a large paper-based evaluation operation for accessibility or connectivity reasons in specific settings, EvaSys's mature paper+online scanning workflow may matter more to you than conversational depth.
• If you are standardised on Explorance Blue's SIS/LMS integration and already hold its VPAT, staying put and hardening your survey design is a legitimate path — the format is less accessible than a conversational one, but a well-built Blue survey with a current ACR clears the legal bar.
• If your immediate mandate is purely legal box-ticking on an existing tool, the cheapest compliant move may be to fix your current instrument's accessibility rather than switch platforms. Accessibility conformance and platform choice are separate decisions; do not let a vendor conflate them.

A five-step procurement path

1. Establish your legal hook (WAD for public bodies; EAA/equal-treatment for private) — but specify EN 301 549 / WCAG 2.1 AA regardless.
2. Demand a current, versioned VPAT/ACR from every shortlisted vendor. No document, no shortlist.
3. Test the instrument, not just the platform — run a keyboard-only and screen-reader pass on an actual evaluation you would send.
4. Check all three layers — student instrument, invitation/response channel, and staff dashboards/exports.
5. Publish an accessibility statement with a feedback and remediation route, as the Directive/Act expect.

Related resources

• Is AI-Assisted Course Evaluation High-Risk Under the EU AI Act?
• EU AI Act & Course Evaluation Software: A Compliance Guide
• Is Your Course Evaluation Survey Accessible? The Silent Non-Response Bias
• GDPR-Compliant Course Evaluation Software (2026)
• Student Feedback as ESG / Accreditation Evidence

Frequently asked questions

Does the European Accessibility Act require our university's course evaluations to be accessible? Not directly for most public universities — the EAA (Directive 2019/882, in force 28 June 2025) enumerates specific consumer services and does not list higher-education course evaluation. But public universities are already bound by the Web Accessibility Directive (2016/2102), which requires WCAG 2.1 AA on websites and applications, and equal-treatment law applies broadly. The practical requirement — WCAG 2.1 AA via EN 301 549 — reaches you regardless of which instrument is your legal hook.

What is the exact technical standard we should put in an RFP? WCAG 2.1 Level AA, delivered through EN 301 549 (current cited version V3.2.1, March 2021). Ask for a VPAT/Accessibility Conformance Report against EN 301 549 for the specific product release you would deploy, and require the vendor to name the assistive technologies (e.g. JAWS, NVDA, VoiceOver) they test against.

Why are Likert matrix questions an accessibility problem? Dense rating grids rely on a visual row-by-column association that screen readers often cannot convey reliably, so respondents lose track of which item a rating applies to. Conversational, one-question-at-a-time formats avoid the grid entirely, which is why Koji's interview structure is inherently easier to navigate with assistive technology.

Is a vendor's "WCAG compliant" marketing claim enough evidence? No. Require a dated, versioned VPAT/ACR that rates each success criterion as Supports / Partially Supports / Does Not Support. A marketing line is not conformance evidence, and tool conformance does not guarantee that the specific survey you build is accessible — you must test the actual instrument.

Does accessibility only apply to the student-facing survey? No. Accessibility obligations cover the invitation and response channel (emails, links, authentication) and the staff-facing dashboards and exported reports as well. A report a partially-sighted programme director cannot read is also a conformance gap.

We are on a competitor already — do we have to switch? Not necessarily. Accessibility conformance and platform choice are separate decisions. If your current vendor holds a current EN 301 549 VPAT and you harden your survey design, you can meet the legal bar without switching. Switching is justified when you also want the data-validity and qualitative-depth benefits of a more accessible, conversational format.