Accessibility in university software procurement: the Web Accessibility Directive, the EAA and EN 301 549

Universities buy most of the digital services students and staff must use: the learning platform, the exam system, video, library databases and e-books. When those services are inaccessible, the university usually carries the legal duty and the student carries the barrier. This guide explains which EU rules apply, which standard to cite, how to read a vendor's accessibility conformance report critically, and what to write into the tender and the contract.

Published 9 October 2026 · Sources checked 9 October 2026

Also available in: Svenska · Nederlands · Norsk · Suomi · Dansk · Français · Español · Português

1. Why accessibility belongs in procurement

Universities build few of the digital services students and staff depend on. Learning platforms, exam systems, lecture capture, library databases and e-book platforms are bought or licensed. If one of them cannot be used with a screen reader, a keyboard or magnification, students are excluded from teaching, assessment or research.

The legal responsibility usually stays with the university. The Web Accessibility Directive excludes third-party content only where it is "neither funded nor developed by, nor under the control of" the public sector body (Art. 1(4)(e)). Jisc's guidance for UK universities explains that the UK government's Central Digital and Data Office "has said that buying or licensing a third-party product could be considered to be funding the product", covering materials "from e-books and e-journals to HR systems". The UK is no longer in the EU, but its regulations transposed the same Directive, and the reasoning is a useful guide for EU institutions.

Validemic's analysis Procurement is the moment of greatest leverage. Before signature, the vendor competes for the contract and will document, test and commit. After signature, the university can request fixes but has few levers left. Accessibility should therefore sit in the same vendor assessment as data protection and security, as described in our vendor assessment guide for universities.

2. What is the Web Accessibility Directive?

Directive (EU) 2016/2102 requires Member States to ensure that the websites and mobile applications of public sector bodies are accessible, meaning "perceivable, operable, understandable and robust" (Art. 4). It covers websites independently of the device used, and mobile apps. Public universities are usually in scope as bodies governed by public law, and the obligations apply to the systems they offer to students, staff and the public.

Who is a public sector body?

Article 3(1) defines a public sector body by reference to the public procurement directive. A "body governed by public law" in Article 2(1)(4) of Directive 2014/24/EU is one established to meet needs in the general interest, not of an industrial or commercial character, with legal personality, and either financed mostly by the State, under its management supervision, or with a board mostly appointed by public authorities. Most public universities meet this test. Jisc quotes UK government guidance that "most higher and further education providers are considered to be in scope". Private universities need to check their own position under national law.

The Directive allows Member States to exclude schools, kindergartens and nurseries (Art. 1(5)). It contains no comparable exclusion for universities.

Dates and scope

The rules applied to new websites from 23 September 2019, to all other websites from 23 September 2020, and to mobile apps from 23 June 2021 (Art. 12(3)). Intranets and extranets published before 23 September 2019 are excluded "until such websites undergo a substantial revision" (Art. 1(4)(g)). Recital 34 lets Member States go further, for example for intranets "used by a limited number of persons in the workplace or in education". Several countries did, so a learning platform behind a login is often in scope. Jisc's guide says that in the UK, virtual learning environments and internal applications such as HR or finance platforms "all fall within scope".

What is excluded

Disproportionate burden

A public sector body may apply the requirements only "to the extent that those requirements do not impose a disproportionate burden" (Art. 5(1)). It must assess the size, resources and nature of the body and the estimated costs against the benefits for persons with disabilities, and explain the parts it could not meet in its accessibility statement, with accessible alternatives where appropriate (Art. 5(2) and 5(4)). Jisc adds that "lack of time or knowledge, or not giving accessibility priority, should not be considerations in the assessment".

Accessibility statements, feedback and enforcement

Article 7(1) requires "a detailed, comprehensive and clear accessibility statement" for each website and app, following the Commission's model in Implementing Decision (EU) 2018/1523. The statement must describe non-accessible content and the reasons, offer a feedback mechanism, and link to the enforcement procedure. The model statement uses three compliance levels: fully, partially or not compliant.

When the university deploys a vendor's system, the university publishes the statement for it. It needs facts from the vendor to write it, and the vendor's help to fix what users report.

Monitoring

Member States monitor compliance periodically using the methodology in Implementing Decision (EU) 2018/1524, which combines "an in-depth monitoring method to verify compliance" with "a simplified monitoring method to detect non-compliance" (Art. 5). They report to the Commission every three years. The Commission's page on the Directive notes that overlays which do not make a site meet the standard are not an appropriate solution. For a plain-language walk-through of the legal text, see our Web Accessibility Directive explained page.

3. Does the European Accessibility Act apply to universities?

The European Accessibility Act, Directive (EU) 2019/882, places obligations on economic operators: manufacturers, importers, distributors and service providers. Member States have applied it since 28 June 2025 (Art. 31(2)). It does not regulate the university's own website, which stays under the Web Accessibility Directive. It matters to universities because many of their suppliers are now directly regulated, and because it feeds into public procurement through Article 24.

What it covers

Article 2 lists the products and services in scope. The ones most relevant to universities are:

• Products placed on the market after 28 June 2025: consumer general purpose computer hardware and their operating systems, self-service terminals such as payment and ticketing machines, consumer terminal equipment for electronic communications and audiovisual media, and e-readers.
• Services provided to consumers after 28 June 2025: electronic communications, access to audiovisual media services, elements of passenger transport, consumer banking, "e-books and dedicated software" and "e-commerce services".

The definition of "e-book and dedicated software" covers the digital files and the software, including apps, used to access, navigate and read them (Art. 3(41)). Recital 41 adds that, for e-books, "the concept of a service provider could include publishers and other economic operators involved in their distribution".

What it means for publishers and vendors selling to universities

• Publishers and e-book platforms serving consumers must meet Annex I, Section IV. For e-books this includes accessibility metadata, compatibility with assistive technology, and "ensuring that digital rights management measures do not block accessibility features".
• Microenterprises providing services (fewer than 10 staff and turnover or balance sheet up to EUR 2 million) are exempt from the service requirements (Art. 4(5) and Art. 3(23)).
• An operator may rely on "fundamental alteration" or "disproportionate burden" only after a documented assessment, renewed at least every five years for services, and not if it received funding to improve accessibility (Art. 14).
• Service contracts agreed before 28 June 2025 may continue unaltered until they expire, but for no longer than five years from that date (Art. 32(1)).

Validemic's analysis The EAA is framed around consumers, defined as people acting "outside his trade, business, craft or profession" (Art. 3(22)). A library's institutional licence is a business-to-business contract, and staff use a learning platform as part of their work. Whether a given university service is in scope can therefore be unclear. In practice the EAA raises the baseline: a publisher that has made its consumer e-book platform conform is well placed to commit to the same in an institutional licence. Do not rely on the EAA to cover the licence; write the requirement in.

Article 24: the link to procurement

Article 24(1) says that, for products and services in Article 2, the Annex I requirements "shall constitute mandatory accessibility requirements within the meaning of Article 42(1) of Directive 2014/24/EU". When a university tenders for consumer-type laptops and operating systems, for example, its technical specifications should refer to those requirements. Where the purchase falls outside Article 2, Article 42 still applies on its own terms, as the next section explains.

4. What does public procurement law require?

Article 42(1) of Directive 2014/24/EU requires that, for all procurement intended for use by natural persons, "whether general public or staff of the contracting authority", technical specifications "take into account accessibility criteria for persons with disabilities or design for all users". The only exception is "duly justified cases". Where EU law sets mandatory accessibility requirements, the specifications must refer to them.

Three more procurement rules are useful in practice:

• Standards with "or equivalent". Article 42(3)(b) allows specifications by reference to European standards, and each reference must be accompanied by "or equivalent". Citing EN 301 549 is the natural route.
• Test reports and certificates. Article 44(1) lets contracting authorities require a test report or certificate from a conformity assessment body as proof of conformity, while accepting equivalent bodies.
• Award criteria and contract conditions. Accessibility can be a minimum requirement, a weighted award criterion and a contract performance condition. Most universities need all three.

Recital 21 of the Web Accessibility Directive says it is "without prejudice to" Article 42. Article 42 makes accessibility part of the purchase; the Directive makes the university answerable for the result.

5. EN 301 549 and WCAG: which version applies?

EN 301 549 is the European standard "Accessibility requirements for ICT products and services". Its web, document and software chapters (clauses 9, 10 and 11) are built on WCAG. On 9 October 2026, EN 301 549 V3.2.1 is the version whose reference is published for the Web Accessibility Directive, through Implementing Decision (EU) 2021/1339. V3.2.1 maps to WCAG 2.1 Level AA.

The September 2026 update

ETSI has published EN 301 549 V4.1.1 (2026-09), labelled a harmonised European standard. According to its foreword, the requirements in clauses 9, 10 and 11 "have all been updated to align with the WCAG 2.2 recommendation", a new Annex ZA maps the standard to the Web Accessibility Directive, and a new Annex ZB maps it to the European Accessibility Act. It was developed under standardisation request M/587. The document lists 24 August 2026 as its date of adoption and 31 May 2028 as the date for withdrawing conflicting national standards.

Pending: on 9 October 2026 the ETSI work programme showed the status "Delivery to the EC", and the Commission's web accessibility page still named V3.2.1. Presumption of conformity under Article 6 of the Directive depends on publication of the reference in the Official Journal. DigiToegankelijk, the Dutch government's accessibility service, reported on 8 September 2026 that the timing of harmonisation by the Commission was not yet known ("niet bekend"). Check before relying on V4.1.1 as the legal benchmark.

WCAG 2.1 and WCAG 2.2

WCAG 2.2 is a W3C Recommendation (current version dated 12 December 2024). It adds nine success criteria to WCAG 2.1, six of them at levels A and AA, covering focus visibility, dragging movements, target size, consistent help, redundant entry and accessible authentication. It also removed one criterion: "WCAG 2.2 has removed one success criterion, 4.1.1 Parsing." Content that meets WCAG 2.2 AA also meets WCAG 2.1 AA for practical purposes.

Several institutions already aim above the legal floor. The University of Cambridge tells staff: "Where possible, you should aim to comply with WCAG 2.2 AA." VU Amsterdam states that it follows WCAG 2.2 level AA for its website.

6. National supervisory bodies

Each Member State names bodies to monitor, report on and enforce the Web Accessibility Directive, and the Commission keeps a list. EAA supervision often sits with different bodies, so a university's suppliers may answer to another authority. The table reflects what we read on 9 October 2026.

We could not confirm from a primary source whether Arcom in France has a supervisory role under the Directive on our check date, so it is not listed. Check your national authority's own pages before relying on this table.

7. How to read a VPAT or ACR critically

The Voluntary Product Accessibility Template (VPAT) is published free of charge by the Information Technology Industry Council (ITI). ITI explains that "a version of the VPAT which has been completed for a specific product is an ACR", an Accessibility Conformance Report. The current template is "VPAT® Version 2.5Rev (April 2025)" in four editions: 508 (US federal rules), EU (based on EN 301 549), WCAG (WCAG 2.2) and INT (all three). ITI also states: "No, ITI does not review or approve VPATs."

An ACR is therefore the vendor's own description: structured and comparable, but in need of a careful reading. Check these points:

1. Edition and standard. For a European tender, ask for the EU or INT edition. A 508-only report refers to WCAG 2.0 and does not cover EN 301 549 chapters such as documentation and support services.
2. Product and version. The report should name the exact product, version and modules you are buying. A report for the web client says nothing about the mobile app or the authoring tool.
3. Date. A report more than a year or two old describes a different product.
4. Who evaluated it and how. Look for the evaluation method, the assistive technologies and browsers used, and whether an independent party was involved.
5. The conformance terms. The template uses "supports", "partially supports", "does not support" and "not applicable". "Partially supports" without a clear remark is not useful. Each partial or failing row should say what fails and where.
6. "Not applicable" used too often. Criteria such as captions, keyboard access or time limits rarely do not apply to a learning or exam platform.
7. Student and staff paths. Check the criteria behind the tasks that matter: logging in, submitting an assignment, taking a timed exam, reading feedback, building a course.
8. Remediation plans. A credible report links failing criteria to a roadmap with dates. Ask for one if it is missing.

Validemic's analysis Treat a report full of "supports" with as much caution as one with many failures. Few complex platforms conform fully. An honest report with clear remarks and a roadmap is better evidence than a perfect score with no method.

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

8. Testing before you buy

Testing is how you check the claims. It does not need to be exhaustive. W3C's evaluation methodology, WCAG-EM (version 2 published on 23 July 2026), describes five steps: define the scope, explore the product, select a representative sample, evaluate it, and report the findings. A university can apply the same logic to a shortlist.

1. Pick the critical tasks. Choose five to ten tasks that students or staff must complete, for example enrolling in a course, submitting a file, answering exam question types, or searching and downloading an article.
2. Run automated checks. They find issues such as missing labels and contrast errors quickly, but cannot judge whether alternative text is meaningful.
3. Test manually with assistive technology. Use a keyboard only, a screen reader (for example NVDA or VoiceOver), zoom to 200% and 400%, and voice control. The University of Edinburgh says "you must test the website or application manually and not just use automated testing."
4. Involve disabled users. Student services and staff networks can help with structured user tests. Their findings often differ from expert audits.
5. Record and compare. Log each failure against the EN 301 549 or WCAG criterion so it can go into the accessibility statement and the remediation plan.

Independence matters. The University of Edinburgh's Digital Accessibility Policy says: "Testing must be undertaken by independent body for externally developed systems and not the supplier or manufacturer." Erasmus University Rotterdam reports that a manual check by an external party takes place every two years ("elke 2 jaar wordt er een handmatig onderzoek uitgevoerd door een externe partij"), and Lund University says it continuously lets "oberoende experter" (independent experts) review its website.

For exam and proctoring systems, accessibility testing should run alongside the data protection review; see our guide to online exams and proctoring under the GDPR and the fact sheets on Inspera and WISEflow.

9. Contract clauses and model wording

The tender sets the minimum; the contract keeps it in place through years of releases. Adapt the clauses below to your national procurement law and template.

Model requirement wording

The following wording is a starting point, not legal text for every jurisdiction.

These requirements fit naturally into a vendor questionnaire. Our planned vendor questionnaire builder will include an accessibility module, and our guide to the HECVAT for European universities explains how to combine questionnaires with documentary evidence.

10. E-resources and publisher platforms

Libraries face the same problem with a different market. A university licenses databases, e-journal platforms and e-book collections from many publishers and aggregators, often through consortia. Two layers need checking: the platform (search, reader, download) and the content (the EPUB or PDF file).

EPUB Accessibility and metadata

EPUB Accessibility 1.1 is a W3C Recommendation. It requires every EPUB publication to include schema.org accessibility metadata in its package document, a conformance claim such as "EPUB Accessibility 1.1 - WCAG 2.2 Level AA" when the publication conforms, and the name of the party that evaluated it. The EAA points in the same direction: e-books must be discoverable "by providing information through metadata about their accessibility features".

DAISY Consortium's free, open-source tool Ace by DAISY checks EPUB files against the specification. DAISY notes it can be used to test an EPUB "which does not have digital rights management", which is one reason to ask publishers for evidence rather than testing protected files yourself.

Accessibility statements from publishers

The ASPIRE project took "a pioneering snapshot of accessibility statements in 2018" for publishers and e-book platforms. It now runs as a verification service from textBOX, publishing ASPIRElists that rate the accessibility statements of publishers, platforms and education institutions. A statement score measures how well a vendor documents its accessibility, not the accessibility of the platform itself, but it is a quick indicator of how much a vendor will be able to tell you.

Consortium work

Testing every platform alone is not feasible, so libraries work together. In the United States, the Big Ten Academic Alliance formed the Library E-Resource Accessibility Group in 2015, which grew into the Library Accessibility Alliance. It publishes e-resource testing results and engages "with library vendors in initiatives to improve usability of online resources for all users". In the UK, Jisc runs a digital accessibility community for members. European consortia can reuse such results, but older tests may describe an older platform version.

Some universities already make this part of their library service. The University of Edinburgh's Information Services state: "All databases are tested for accessibility and have accessibility statements published."

What to write into an e-resource licence

• The platform conforms to EN 301 549 or WCAG 2.1 AA (ideally 2.2 AA), with an ACR or accessibility statement available.
• New e-book content is supplied as EPUB 3 with EPUB Accessibility conformance metadata; legacy PDF-only titles are identified.
• Digital rights management does not block text-to-speech, screen readers, reflow or font changes.
• The licence permits making accessible copies for users with print disabilities, consistent with the Marrakesh-implementing rules (Directive (EU) 2017/1564).
• The publisher fixes reported barriers within agreed times and supplies accessible alternatives in the meantime.

Licence terms on AI and text and data mining raise separate questions; see our planned guide on library licences, AI and TDM and the planned guide on library patron privacy under the GDPR.

11. What European universities publish

Accessibility statements and policies show how universities handle bought systems in practice.

Procurement as an explicit requirement

University College Dublin says it aims to "incorporate accessibility considerations when procuring third-party systems or upgrading existing systems". VU Amsterdam writes that digital accessibility "is vanuit de dienst IT een (zachte) eis naar leveranciers van applicaties toe en wordt door onze IT-architecten gehandhaafd" (a soft requirement for application suppliers, enforced by IT architects). Trinity College Dublin links its accessibility page to guidance on "Accessible Procurement of Goods and Services". The University of Edinburgh's policy covers "systems provided by external suppliers" and "third-party systems we purchase or use".

Third-party components named in statements

The University of Helsinki lists ranking graphs that "have been implemented using an external service, and they may be inaccessible to users relying on a screen reader". The University of Copenhagen's statement lists a chatbot on its study pages "som ikke er fuldt tilgængelig" (which is not fully accessible) and a feedback tool, noting "Det har ikke været realistisk at tilvejebringe et tilgængeligt alternativ" (it has not been realistic to provide an accessible alternative). The University of Oslo's statement on uustatus.no, updated 17 June 2026, reports partial compliance with WCAG 2.1 and names its video player among the non-conformities. Aalto University's statement describes a third-party chat service and how its supplier updated it for keyboard and screen reader use.

The University of Granada's statement lists as out of scope "Contenidos de terceros no financiados ni desarrollados por la Universidad de Granada", the Directive's exemption in Spanish law. The Universidad Autónoma de Madrid ties each failure to a numbered requirement of UNE-EN 301549:2022, which is the traceability procurement teams should ask vendors for.

Self-assessment or independent audit

Methods vary. The University of Helsinki says its website service "has been audited by an external accessibility expert organisation". The University of Granada's statement was prepared by "autoevaluación llevada a cabo por el propio organismo" (self-assessment by the body itself). Aalto University's statement is also based on self-assessment. The Universidade do Porto declares its portal partially compliant with Decreto-Lei n.º 83/2018, the Portuguese transposition of the Directive, and Ghent University describes its site as partially conforming to EN 301 549 on the basis of an internal check.

Teaching materials and platforms

KU Leuven states that accessibility of "de leeromgeving en het cursusmateriaal is dan ook cruciaal voor de participatie van studenten met een functiebeperking" (the learning environment and course material are crucial for the participation of students with disabilities). That is the procurement case in one sentence: the learning environment is bought, and course material depends on its authoring tools. For learning platforms, see our fact sheets on Canvas, Moodle, Brightspace, and for video on Kaltura and Panopto.

Tools that support disabled students can also reveal health information; see our guide on assistive technology and the GDPR.

12. Procurement checklist

Each row should leave a document or a decision in the vendor file.

This checklist complements the data protection and security checks in our vendor assessment guide, which already lists the accessibility conformance report as part of the core evidence pack.

Sources

1. Directive (EU) 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies, Articles 1, 3 to 9 and 12, recitals 21, 30, 31 and 34 (Official Journal text read via the EU Publications Office, retrieved 9 October 2026).
2. Directive (EU) 2019/882 (European Accessibility Act), Articles 2 to 4, 14, 24, 31 and 32, recital 41 and Annex I (retrieved 9 October 2026).
3. Directive 2014/24/EU on public procurement, Articles 2(1)(4), 42 and 44 (retrieved 9 October 2026).
4. Commission Implementing Decision (EU) 2021/1339 on the harmonised standard for websites and mobile applications (EN 301 549 V3.2.1) (retrieved 9 October 2026).
5. Commission Implementing Decision (EU) 2018/1523 establishing a model accessibility statement (retrieved 9 October 2026).
6. Commission Implementing Decision (EU) 2018/1524 establishing a monitoring methodology (retrieved 9 October 2026).
7. European Commission: Web Accessibility (retrieved 9 October 2026).
8. European Commission: national bodies for monitoring, reporting and enforcement of the Web Accessibility Directive (retrieved 9 October 2026).
9. European Commission: European Accessibility Act (retrieved 9 October 2026).
10. ETSI/CEN/CENELEC EN 301 549 V4.1.1 (2026-09), Accessibility requirements for ICT products and services, foreword and introduction (retrieved 9 October 2026).
11. ETSI work programme, REN/HF-00301561 (revision of EN 301 549 V3.2.1) (retrieved 9 October 2026).
12. DigiToegankelijk: Nieuwe versie van EN 301 549 aanstaande, met update naar WCAG 2.2, 8 September 2026 (retrieved 9 October 2026).
13. W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (retrieved 9 October 2026).
14. W3C WAI: WCAG-EM overview (retrieved 9 October 2026).
15. Information Technology Industry Council: VPAT (retrieved 9 October 2026).
16. W3C: EPUB Accessibility 1.1 (retrieved 9 October 2026).
17. DAISY Consortium: Ace by DAISY (retrieved 9 October 2026).
18. Inclusive Publishing (DAISY Consortium): Regional Guidance and Legislation (retrieved 9 October 2026).
19. ASPIRE (textBOX): accessibility statement verification and ASPIRElist platforms (retrieved 9 October 2026).
20. Library Accessibility Alliance: Who we are (retrieved 9 October 2026).
21. Jisc: Meeting accessibility regulations (retrieved 9 October 2026).
22. Jisc: Accessibility regulations, what you need to know, updated 21 February 2023 (retrieved 9 October 2026).
23. DIGG: Digital tillgänglighet (retrieved 9 October 2026).
24. Uu-tilsynet (Norway) (retrieved 9 October 2026).
25. Traficom: Saavutettavuusvaatimukset (retrieved 9 October 2026).
26. Digitaliseringsstyrelsen: Webtilgængelighed (retrieved 9 October 2026).
27. DigiToegankelijk and Over DigiToegankelijk (Logius) (retrieved 9 October 2026).
28. DINUM: Référentiel général d'amélioration de l'accessibilité (RGAA) (retrieved 9 October 2026).
29. Observatorio de Accesibilidad Web (Spain) (retrieved 9 October 2026).
30. ARTE, Agência para a Reforma Tecnológica do Estado (Portugal) (retrieved 9 October 2026).
31. University of Edinburgh: Digital Accessibility Policy (retrieved 9 October 2026).
32. University of Edinburgh Information Services: Legal requirements (retrieved 9 October 2026).
33. University of Edinburgh: Library services for disabled users (retrieved 9 October 2026).
34. University of Cambridge UIS: Creating digital content that's accessible (retrieved 9 October 2026).
35. University of Helsinki: Accessibility statement (retrieved 9 October 2026).
36. Aalto University: Accessibility statement (retrieved 9 October 2026).
37. Lund University: Tillgänglighet för www.lu.se (retrieved 9 October 2026).
38. University of Oslo: accessibility statement for uio.no (uustatus.no) (retrieved 9 October 2026).
39. University of Copenhagen: Tilgængelighedserklæring for www.ku.dk (retrieved 9 October 2026).
40. Vrije Universiteit Amsterdam: Digitale toegankelijkheid (retrieved 9 October 2026).
41. Erasmus University Rotterdam: Digitale toegankelijkheid (retrieved 9 October 2026).
42. Ghent University: Toegankelijkheid voor personen met een beperking (retrieved 9 October 2026).
43. KU Leuven: Digitale toegankelijkheid (retrieved 9 October 2026).
44. University College Dublin: Accessibility Statement (retrieved 9 October 2026).
45. Trinity College Dublin: Accessibility (retrieved 9 October 2026).
46. Universidad de Granada: Declaración de accesibilidad (retrieved 9 October 2026).
47. Universidad Autónoma de Madrid: Declaración de accesibilidad (retrieved 9 October 2026).
48. Universidade do Porto: Declaração de acessibilidade (retrieved 9 October 2026).

About this page

Sources checked on 9 October 2026. We read the legal texts in the Official Journal versions published by the EU Publications Office, the EN 301 549 V4.1.1 document and ETSI work programme, the Commission, W3C, ITI, DAISY, Jisc and national authority pages listed above, and the accessibility statements and policies of sixteen universities in ten countries. Quotations from non-English pages are given in the original with our translation. Where we give our own interpretation, it is labelled as Validemic's analysis. This page is general information, not legal advice; national transposition and your institution's own procurement rules may add requirements. The harmonised status of EN 301 549 V4.1.1 was pending on our check date, and we will update this page when it changes. If you spot an error or an outdated point, please contact us and we will correct it.