Accessibility Statement 2026 What it must contain, how to prepare it and who monitors it
A practical guide for public bodies, foundations and companies covered by the EAA — covering HTML technical requirements, meta tags and the most common errors.
In a nutshell
Who is affected:
Any public body (government department, school, hospital, cultural institution, foundation carrying out public tasks). From 28 June 2025, this will also apply to private companies in sectors covered by the European Accessibility Act (e-commerce, banking, transport).
Deadline:
Updates must be made by 31 March each year. New websites from 1 August 2024 must be in the Declaration 2.0 format.
Format: HTML
only (no PDFs, no Word documents, no images). It must be fully digitally accessible — even if the website itself does not comply with WCAG.
Meta tag: The
Ministry of Digital Affairs recommends including the following in the code of every subpage: . This enables monitoring tools to automatically detect the statement.
Penalty:
Up to 5,000 PLN for a missing or incomplete declaration. Enforced by the Ministry of Digital Affairs.
An accessibility statement is a document that informs users — particularly those with disabilities — about the digital accessibility status of a website or mobile app. It is not a marketing statement of good will. It is a legal obligation arising from the Act of 4 April 2019 on the digital accessibility of websites and mobile applications of public sector bodies. Even if your website does not meet the WCAG requirements, the declaration must exist and must be fully accessible. This is a deliberate choice by the legislator: a user with a disability has the right to know what to expect from the website before they start using it.
In this article, we explain exactly what the declaration must contain in 2026 (version 2.0, effective from 1 August 2024), how to publish it technically — including the meta tag and HTML identifiers — what mistakes public bodies most commonly make, and who is responsible for monitoring compliance.
What has changed with the Accessibility Statement 2.0?
On 31 July 2024, the Ministry of Digital Affairs published a new version of the technical requirements for publishing declarations — version 2.0. New websites created from 1 August 2024 must comply with this version. Existing websites should update their declaration at their next review (by 31 March).
Key changes
• Standardised document structure — fixed sections and headings, predictable for screen readers.
• Revised HTML identifiers (id attribute) — new section names, more required IDs.
• Mandatory link to a report or self-assessment — it is not enough to simply declare compliance; you must specify the basis for this.
• More examples of HTML code in the documentation — easier to implement.
• A clearer distinction between declarations for websites and mobile applications.
What must the declaration contain? Compulsory sections
The accessibility statement consists of several fixed sections. Each has a specific heading and HTML identifier. Below is a full list with explanations.
Introduction — Accessibility StatementHeading: “Accessibility Statement”. Identifier: id="a11y-statement". It contains the name of the public body, the name of the website, and the compliance status with standard EN 301 549 (which refers to WCAG 2.1 AA). The status can be: compliant, partially compliant, or non-compliant. Important: if the website is partially compliant or non-compliant, you must describe which elements are inaccessible and why. You must not state that “the website is compliant” if this is not the case.
Content not availableIdentifier: id="a11y-non-compliance". A section describing specific elements that do not meet the requirements. Typical examples: missing alt text for some images, unstructured PDF documents, videos without subtitles, forms without labels. Each issue should include an indication of when it will be rectified or why rectification is not possible (e.g. archived material prior to 23 September 2018).
Date of preparation and method of assessmentDate of first publication of the page, date of the last significant update, date the declaration was drawn up, date of the last review. Assessment method: self-assessment, internal audit or external audit. Declaration 2.0 requires a link to the report on which the assessment is based. If you carried out an audit — a link to the report. If you carried out a self-assessment — a description of the method.
Feedback and contact detailsIdentifier: id="a11y-kontakt". Mandatory heading: “Feedback and contact details” — in exactly this form. Contact details (name, email, telephone number) for reporting accessibility issues. Description of the procedure for handling reports: without undue delay, within 7 days, up to a maximum of 2 months. Information on the possibility of lodging a complaint with the Ombudsman if the organisation fails to respond.
Architectural accessibilityIdentifier: id="a11y-architecture". Description of the physical accessibility of the premises: entrances, lifts, toilets, car park for people with disabilities, assistance dogs, sign language interpreter. This is not optional — every public body must provide a description of each location.
Mobile apps (if applicable)If an organisation provides mobile apps, it should include a section containing information on their availability, download links and compliance status.
HTML technical requirements how to submit a declaration
The declaration must be published in HTML format (any version). It must not be a PDF file, an image, a Word document or a scan. It must comply with the WCAG 2.1 AA requirements — even if the page itself does not comply with them.
Where to place the link
A link to the accessibility statement must be visible on every subpage — typically in the footer or header. Users must be able to access the statement from any subpage in an intuitive and accessible manner. The link text should read ‘Accessibility Statement’ — not ‘WCAG’, not ‘Accessibility’, not ‘A11y’.
Meta tag recommendation from the Ministry of Digital Affairs
In addition to the visible link in the footer, the Ministry of Digital Affairs recommends including a meta tag in the code of each subpage that specifies the address of the accessibility statement. This enables monitoring tools (used by the Ministry for inspection purposes) to automatically locate the declaration without analysing the visual structure of the page.
The official format recommended by gov.pl:
In practice, some organisations also use an alternative format with a link element:
<link rel="accessibility-statement" href="https://twoja-strona.pl/deklaracja-dostepnosci">
Both formats are encountered in practice. The official recommendation from the Ministry of Digital Affairs (gov.pl/web/dostepnosc-cyfrowa) specifies the meta tag. The `link rel` format is an alternative used by some organisations, but it is not explicitly mentioned in the official guidelines. Our recommendation: use the meta tag (as it is the official one) and, at the same time, include a visible link in the footer. This provides double coverage — search engine bots will find the tag, and people will find the link.
How to implement a meta tag in the TYPO3 CMS
In TYPO3 CMS, there are two ways to add a meta tag. Via TypoScript — globally on all subpages:
page.meta.accessibility-statement = //your-website.co.uk/accessibility-statement
Or directly in the Fluid template within the <head> section: <br><strong><meta name="accessibility-statement" content="{f:uri.page(pageUid: 123)}"> </strong></head>
The second approach uses Fluid’s ViewHelper to dynamically generate the URL of the accessibility statement page — if you change the statement’s slug, the meta tag will update automatically.
Mandatory HTML identifiers (the id attribute) full list
Declaration 2.0 requires the use of specific identifiers in HTML elements. This is not just for show — the Ministry of Digital Affairs’ monitoring tools (including the deklaracja-dostepnosci.info validator) search the code for id attributes beginning with a11y- and use these to assess the completeness of the declaration. Missing identifiers = declaration not recognised by the monitoring system.
Below is a full list of identifiers required by the Ministry of Digital Affairs’ technical specifications, grouped by section.
Introduction Statement
• a11y-declaration — main heading:
Accessibility Statement
• a11y-introduction — the full text of the introductory statement (“Name of organisation undertakes to ensure accessibility...”)
• a11y-organisation — name of the public organisation, e.g.Kraków City Council
• a11y-url — link to the website to which the declaration relates, e.g. the City Council’s website
Compliance Status Section
• a11y-status — compliance status: compliant / partially compliant / non-compliant with the Act
• a11y-non-compliance — list of inaccessible content (required if the status is not ‘compliant’)
Declaration Preparation Section
• a11y-date-of-preparation — the date the declaration was drawn up in the format YYYY-MM-DD, e.g. 2026-03-15
• a11y-auditor — the name of the external body that carried out the audit (optional — required only if the audit was carried out by an external body)
• a11y-assessment — a link to the document containing the analysis of undue burden (optional)
Contact section the one most often overlooked
This is the section where IDs are most often missing. Each contact element must have its own ID:
• a11y-contact — section heading:
Feedback and contact details
• a11y-person — the first name and surname of the person responsible for accessibility enquiries, e.g. Jan Kowalski. This is NOT the Data Protection Officer — it is the accessibility coordinator or the person fulfilling this role.
• a11y-email — the contact person’s email address: [email protected]
• a11y-telefon — the contact person’s telephone number • a11y-procedura — a description of the requests and complaints procedure (what to do if the organisation fails to respond: a complaint to the Ombudsman)
Why a11y-person is important: a user with a disability needs to know exactly who to contact. ‘Contact’ is not enough — the law requires a specific person to be named. The validator checks whether this identifier exists in the HTML code of the declaration.
Architectural and Transport Accessibility Section
• a11y-architecture — section heading:
Architectural Accessibility
• a11y-architecture-url — link to a separate page describing architectural accessibility (if the description is on a different subpage)
• a11y-communication — section containing information on communication and information accessibility (PJM interpreter, induction loop, etc.)
• a11y-apps — a section on mobile apps (if the organisation provides them)
An example of correct HTML code
An extract from the contact section containing all the required identifiers:
<h2 id="a11y-kontakt">Feedback and contact details</h2> <p>The contact person is <span id="a11y-osoba">Anna Nowak</span>, email: <a id="a11y-email" href="mailto:[email protected]"> [email protected]</a>, telephone: <span id="a11y-telefon">12 345 67 89</span>. </p> <div id="a11y-procedura"> <p>Everyone has the right to request that the website or any part of it be made digitally accessible...</p> </div>
The deklaracja-dostepnosci.info validator searches the HTML code for all elements with an id attribute beginning with ‘a11y-’ and compares them with the requirements of the Technical Specifications 2.0. If a required identifier is missing, the declaration is marked as incomplete. The tool is publicly available and anyone can check their declaration before it is reviewed by the Ministry.
Mandatory HTML headings
Accessibility Statement 2.0 requires a minimum of 8 headings in the correct hierarchy:
• Accessibility Statement — main heading (h1)
• Digital accessibility status — subheading (h2)
• Preparation of the accessibility statement — h2
• Feedback and contact details — h2 (exactly this name, mandatory format)
• Handling of accessibility-related requests and complaints — h2
• Architectural accessibility — h2
• Communication and information accessibility — h2
• Mobile applications — h2 (if the organisation provides them)
The hierarchy must be logical: if the title is h1, the sections are h2. If the statement is embedded within a page with its own h1, the title of the statement may be h2 and the sections h3. Important: you must not skip levels (e.g. h1 → h3 without h2). Screen readers lose context.
The most common mistakes What we see among our customers
Before you proceed to publish your declaration, it is worth checking where problems most commonly arise. In practice, most errors do not stem from a lack of goodwill, but from a lack of clarity in the requirements or from copying ready-made templates without understanding their meaning. The result is the same: the declaration looks correct ‘at a glance’, but fails to meet the formal or technical requirements and does not pass validation. Below, we have compiled the most common errors that we regularly see in projects — both among public bodies and companies subject to accessibility requirements.
Formal errors
✗ The declaration has been published as a PDF — this is not in accordance with the Act; it must be in HTML.
✗ No date of the last review — the declaration appears to be from 2020.
✗ No information on the assessment method — it is unclear on what basis accessibility was assessed.
✗ No link to the report or self-assessment — a requirement of Declaration 2.0.
✗ Copying the declaration from another organisation — a common practice, easily detected by monitoring.
Technical errors
✗ Missing HTML identifiers (id attribute) — monitoring tools cannot recognise the section.
✗ Missing meta tag — automatic detection is not possible.
✗ Headings in the wrong hierarchy — e.g. H3 after H1 without H2. The screen reader loses context.
✗ The accessibility statement itself is inaccessible — lack of contrast, no keyboard navigation, no focus indicators. Ironically, the accessibility document is inaccessible.
Factual errors
✗ A ‘compliant’ status when a website has obvious issues — this is untrue and could form the basis of a complaint.
✗ No description of inaccessible content — ‘the site is partially compliant’ without explaining what is non-compliant.
✗ No contact details for the accessibility coordinator — the user does not know who to report a problem to.
✗ No information on physical accessibility — particularly common in organisations with multiple locations.
Who monitors accessibility statements? What are the penalties for failing to comply with the rules?
The Ministry of Digital Affairs is responsible for monitoring digital accessibility. It publishes an annual report on the results of its monitoring of public sector websites. Inspections may be scheduled (based on a random sample) or carried out following a user’s complaint.
Procedure: The Ministry issues a request for improvement — the organisation has between 60 and 120 days to respond. If the organisation fails to respond, a fine of up to 5,000 PLN may be imposed for failing to submit a declaration or for publishing an incomplete declaration. In extreme cases, the Ministry may require the organisation to withdraw the service or impose a ban on the website’s continued operation.
In addition, every user has the right to lodge a complaint regarding a lack of accessibility with the Ombudsman. This means that even if the Ministry does not happen to inspect your website, a user with a disability can initiate the procedure themselves.
Important: from 28 June 2025, private companies in sectors covered by the EAA (e-commerce, banking, transport, telecommunications) will also be subject to accessibility requirements. These are monitored by other bodies (PFRON, sectoral supervisory authorities), but the principle remains the same: lack of accessibility = legal and financial consequences.
How to prepare a tax return Step by step
If you’re just starting to draw up a declaration or need to update an existing one, here’s a tried-and-tested process.
- Carry out a website accessibility audit
Either on your own (using the gov.pl checklist and tools such as WAVE, Lighthouse and aXe) or by commissioning an auditor. You need to know what is compliant and what isn’t before you draw up your declaration.
- Collect data on architectural accessibility
Every location: entrances, lifts, toilets, car parks, assistance dogs, PJM interpreters.
- Write a declaration in HTML
Use the structure from Declaration 2.0: headings with identifiers, fixed section names, and a correct hierarchy.
- Insert the meta tag into the code of each subpage
- Add a visible link to the footer
The text ‘Accessibility Statement’, which appears on every subpage.
- Check the availability of the declaration itself
Contrast, keyboard navigation, screen reader. The declaration must be fully accessible.
Set a reminder for your serviceBy 31 March each year and following any major website redesign.
Frequently Asked Questions
If a foundation carries out public tasks or receives public funds — yes, it is subject to the Digital Accessibility Act. If it is purely private — it does not have to, but from 28 June 2025 it may be subject to the EAA if it operates in the sectors covered (e.g. e-commerce).
No. The Act requires the HTML format. PDFs are not accessible in the same way as HTML pages — screen readers support HTML natively, whereas PDFs require additional structure (PDF/UA tags), which most documents do not have.
You still need to publish the declaration. Enter the status ‘non-compliant’ or ‘partially compliant’ and specify exactly which elements are unavailable. The declaration is not a penalty — it is information for users. It is better to make an honest ‘non-compliant’ declaration than a false ‘compliant’ one.
The meta tag () is an official recommendation from the Ministry of Digital Affairs — it is used to enable monitoring tools to automatically detect accessibility statements. The rel link (<link rel="accessibility-statement" href="URL">) is an alternative format used by some organisations, but it is not explicitly mentioned in the official guidelines. Our recommendation: use the (official) meta tag and add a visible link in the footer.
At least once a year — by 31 March. In addition, following any major website redesign, change of CMS, or addition of new features (forms, multimedia, e-services). In practice, it is worth reviewing the accessibility statement after any content update that may affect accessibility (e.g. new PDFs, new videos).
The generator is a good starting point — it creates a framework with the correct sections and identifiers. But you’ll need to adapt it to your specific situation: describe the actual issues, add contact details, information on accessibility, and a link to the report. A generic template is no substitute for an individual assessment of your website’s condition.
Partly. You add the meta tag and the link in the footer once in TypoScript or a Fluid template. The content of the declaration is an HTML subpage in TYPO3 — the editor updates it just like any other page. You insert HTML identifiers manually in the HTML editor or via a dedicated Content Block. EYE-ABLE Report can automatically generate a declaration based on the scan results — but it still requires human verification.
How can we help?
Preparing a valid accessibility statement requires three things: an understanding of your website’s current state (an audit), knowledge of the legal and technical requirements (version 2.0, identifiers, meta tags), and the ability to implement this within a specific CMS. We combine all three.
Our portfolio includes websites we have developed for public bodies, foundations and institutions using the TYPO3 CMS — including CUS Drobin, the International Youth Meeting Centre in Oświęcim, and the German Historical Institute in Warsaw. Each of these projects required a full accessibility statement, a WCAG audit and the implementation of corrective measures. We know how this works in practice — not just in theory.
If you need an accessibility audit, a declaration of compliance with version 2.0, the implementation of meta tags and HTML identifiers, or a comprehensive adaptation of your website to WCAG standards — please contact us. Telephone: 12 333 44 01. Email: [email protected].
