Your Course Evaluation Survey Is Probably a Legal Accessibility Obligation. Most Vendors Won''t Mention It.

Bottom line up front: If your university is a public-sector body in the EU, the tools it uses to collect student feedback almost certainly fall within the scope of the Web Accessibility Directive — Directive (EU) 2016/2102 — which has required public-sector websites to conform to the EN 301 549 standard (which references WCAG 2.1 level AA) since 23 September 2020, and mobile apps since 23 June 2021. The European Accessibility Act, Directive (EU) 2019/882, applicable since 28 June 2025, extends comparable accessibility duties into parts of the private sector. An inaccessible course-evaluation instrument is therefore not merely bad practice or a source of silent non-response bias — for many institutions it is a legal exposure. Yet accessibility almost never comes up when a university procures evaluation software.

Two laws, one obligation that lands somewhere

Be precise about the instruments, because vendors and buyers routinely conflate them.

The Web Accessibility Directive (EU) 2016/2102 binds public-sector bodies. Most European universities are public bodies or are treated as bodies governed by public law, which brings their websites and mobile applications — and, in practice, the third-party digital tools embedded in them, including survey and feedback platforms — within scope. The directive is unambiguous and already in force: WCAG 2.1 AA via EN 301 549, plus two procedural duties that are easy to overlook: every in-scope site must publish an accessibility statement, and must provide a feedback mechanism so users can report barriers. The W3C's Web Accessibility Initiative maintains a clear summary of the EU policy landscape.

The European Accessibility Act (EU) 2019/882 works differently. It targets private-sector economic operators and a defined list of products and services — e-commerce, consumer banking, e-books, ticketing, electronic communications and more — and became applicable on 28 June 2025. Here honesty matters: the EAA does not name universities, and its enumerated service categories were not written with course evaluation in mind. What it does do is raise the baseline expectation across the digital economy and catch many private ed-tech providers and the consumer-facing services universities rely on. National transpositions also vary, and several member states apply obligations that go beyond the EU minimum.

Put together, the practical conclusion is robust even though the legal routing differs by case: for a public university the Web Accessibility Directive already binds the student-facing tools it deploys; for private providers the EAA raises the floor. The obligation lands somewhere regardless of which door you came in through — which is exactly why "is our evaluation tool accessible?" is a procurement question, not an afterthought.

The standard, concretely

EN 301 549 is the harmonised European standard for ICT accessibility; its web chapter incorporates WCAG 2.1 level AA by reference. WCAG 2.1 AA is not a vague aspiration — it is a testable set of success criteria covering perceivability, operability, understandability and robustness. For a survey instrument, the criteria that most often fail are predictable.

Where evaluation surveys break

Course-evaluation forms are unusually good at violating accessibility criteria, because their signature feature — the dense Likert matrix — is one of the hardest patterns to make accessible:

• Grid/matrix questions that a screen reader announces as an undifferentiated wall of radio buttons, with no reliable association between row label and column value.
• Colour-only cues (red/amber/green scales) that convey meaning no colour-blind or non-visual user can perceive, failing the use-of-colour criterion.
• Missing or unprogrammatic labels, so an input is spoken as "edit text" with no idea what it asks.
• Keyboard traps and non-focusable controls, locking out anyone who cannot use a mouse.
• Time-limited sessions that expire before a user with a motor or cognitive disability can finish.
• Insufficient contrast on the light-grey placeholder text survey designers love.
• CAPTCHA gates and inaccessible PDF result exports that reintroduce barriers at the reporting stage.

Each of these is both a WCAG failure and a mechanism of the non-response bias that quietly removes disabled students — a group whose experience you most need to hear — from your data.

"We're already covered — our vendor ticks WCAG"

This is the objection to take seriously, because it is where most institutions actually sit, and it is usually wrong for three reasons.

First, a procurement checkbox is not conformance. A supplier asserting "WCAG compliant" in a sales deck has told you nothing testable. What you need is an accessibility conformance report against EN 301 549 / WCAG 2.1 AA — the European equivalent of a filled-in VPAT — naming version, date, criteria met, and known exceptions. Second, automated checkers catch a minority of issues; the matrix, label and keyboard failures above are precisely the ones that require manual testing with real assistive technology. Third, conformance decays per release: a claim from two years and forty deploys ago is evidence of nothing today. And a subtler trap — the evaluation instrument is frequently a separately embedded tool, so your LMS passing an audit says nothing about the survey iframe living inside it.

A fair counter-counterargument: full WCAG 2.1 AA conformance is genuinely hard, and no vendor is perfect. True — which is why the directive expects an accessibility statement that honestly discloses non-conformances and a feedback mechanism to fix them, rather than a bare "compliant" claim. Transparency about what is not yet accessible is closer to the law's intent than a confident tick-box.

What to actually do

1. Ask every vendor — including us — for an EN 301 549 / WCAG 2.1 AA accessibility conformance report, dated to the current release, not a marketing assertion.
2. Test the actual instrument with real assistive technology — a screen reader, keyboard-only navigation — on the exact form students will see, matrix questions included.
3. Publish an accessibility statement and a feedback route for the evaluation tool, as the Web Accessibility Directive requires of public bodies.
4. Offer accessible alternatives and ensure result exports (PDF, dashboards) meet the same bar as the survey.
5. Write accessibility into the tender, with conformance evidence as a scored criterion rather than a yes/no box.

The reporting stage counts too

Accessibility obligations do not stop at the questionnaire. The dashboards and PDF exports that carry results to committees, and any public-facing publication of evaluation outcomes, fall under the same EN 301 549 expectations for a public body. A perfectly accessible survey feeding an untagged, unreadable PDF simply moves the barrier downstream — now excluding disabled staff and student representatives from the governance conversation rather than disabled students from the data. Treat the whole pipeline, collection through reporting, as in scope, because the law does. Member states are also required to monitor public-sector compliance and provide an enforcement procedure, so a barrier reported through your mandatory feedback mechanism is not a suggestion box — it is the start of a process you are obliged to act on.

Where Koji fits

A one-question-at-a-time conversational interview is inherently friendlier to assistive technology than a dense matrix grid: it is linear, it carries less cognitive load, and it removes the single hardest-to-make-accessible pattern in the whole genre. That is an architectural advantage, not a compliance guarantee — and we would rather say so plainly. Any serious vendor, Koji included, should be able to hand you an EN 301 549 / WCAG 2.1 AA conformance report and let you test the live instrument with a screen reader before you sign. Koji is built for the European context — GDPR/AVG-aware, EU-hosted — and treats accessibility as part of that same duty of care rather than a feature to bolt on. The identical conversational engine underpins koji.so for general user research, where accessible instruments are just as much a legal and ethical baseline.

Accessibility in course evaluation is not a nice-to-have you can defer to a future sprint. For public European universities it is settled law, for private providers it is the new floor, and for disabled students it has always been the difference between having a voice and being silently dropped from the dataset.