The six parts Swedish rules require, the evidence each claim needs, and a routine that keeps the statement true after every release.
In short
An accessibility statement is a public page that says how well a website or app meets the accessibility requirements, lists what is not accessible and why, and tells users how to report problems. In Sweden it is mandatory for public-sector services. It holds up when every claim rests on a dated test and the page is updated when the service changes.
An accessibility statement (tillgänglighetsredogörelse in Swedish) is a declaration of conformance that users, supervisors and procurers read as a promise. Most weak statements fail in the same way: a generic template, a conformance claim nobody tested, and a review date that is two years old. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for digital, product and communications leads who own a statement and want it to survive a complaint, an audit or a supervisor's review.
Who needs an accessibility statement?
Every website and app covered by the Swedish DOS law needs an accessibility statement, and companies under the European Accessibility Act need a similar but separate piece of compliance information.
The DOS law, lagen om tillgänglighet till digital offentlig service (SFS 2018:1937), requires public bodies and some publicly funded providers to publish a statement for each covered website and app. Our guide to the Swedish DOS law and who it covers explains the scope in detail.
Private companies selling consumer services such as e-commerce and banking fall under the European Accessibility Act instead. Article 13 of Directive (EU) 2019/882 asks them to explain how their services meet the requirements, using the information listed in Annex V. That is not a tillgänglighetsredogörelse in the legal sense, but the same test evidence feeds both, so the method in this guide works for either.
Document
Who publishes it
Supervisor in Sweden
Accessibility statement (tillgänglighetsredogörelse)
Who publishes it
Public bodies and covered publicly funded providers
Supervisor in Sweden
DIGG
EAA service information
Who publishes it
Companies offering covered consumer services
Supervisor in Sweden
PTS and other sector authorities
Voluntary statement
Who publishes it
Anyone who wants to show their level
Supervisor in Sweden
None
What must the statement contain?
DIGG's regulation lists six mandatory parts, and a statement that misses one of them is incomplete regardless of how well the service performs.
As of October 2026, section 6 of DIGG's regulation MDFFS 2019:2 requires:
- The organisation and the services covered: the public actor's name and each website and app the statement applies to.
- The compliance status: whether the service fully, partly or does not meet the requirements.
- The non-accessible content: a list of what is not accessible, the reasons, and any accessible alternatives.
- Date and method: when the assessment behind the statement was done, which method was used, and when the statement was last updated.
- A feedback function: a way, or a link to one, for users to report barriers and request exempted content in an accessible form.
- The enforcement route: information that users can report perceived deficiencies to DIGG, with a link to DIGG's reporting procedure.
The same section says the statement must reflect the service's current accessibility, be in an accessible format, and be clearly linked from the home page or from every page. For apps, it must be available on the organisation's website or with the download information. The EU's model accessibility statement in Implementing Decision (EU) 2018/1523 follows the same structure.
How to write the statement, step by step
A statement that holds up is written from test evidence, not from a template, so the work starts with the assessment and ends with the page.
- Fix the scope. List every domain, subdomain, app and embedded service the statement covers. Decide whether one statement covers several services or each gets its own.
- Name the benchmark. As of October 2026 the legal benchmark is EN 301 549 V3.2.1, based on WCAG 2.1 AA. Testing against WCAG 2.2 AA covers that and the next version, as our article on WCAG 2.2 and how to test it explains.
- Run a real assessment. Combine automated scanning with manual keyboard, screen reader and zoom tests on representative pages and journeys. Our comparison of automated accessibility testing and a manual audit explains why a scanner alone cannot support a conformance claim.
- Choose the honest status. "Fully compliant" means every criterion passes for everything in scope. One failure anywhere in scope makes the status "partly compliant", which is the realistic answer for most services.
- Describe each gap in user terms. Write "the date picker in the booking form cannot be used with a keyboard", not "2.1.1 fails". Add the criterion in brackets, the affected pages and a planned fix date.
- Separate the reasons. Keep three groups apart: non-compliance you will fix, content exempted by law, and any claim of disproportionate burden with its justification.
- Wire up the feedback route. Test the form or address yourself. Name who answers, how quickly, and how requests for alternative formats are handled.
- Add date, method and the DIGG link. State whether the assessment was a self-assessment or done by a third party, and when.
- Publish it accessibly. Use plain HTML, real headings and lists, and link it from the footer of every page.
What makes a statement hold up under scrutiny?
A statement holds up when a reader could repeat the test and reach the same conclusion, which requires traceable evidence behind each sentence.
Supervisors, journalists and complainants tend to test the same things: does the claimed status match a quick keyboard check, does the feedback route answer, and are the dates recent. Prepare for those checks:
- Keep the evidence. Store the test report, the sample of pages and the tool versions next to the statement, so you can show how each claim was reached.
- Avoid vague phrases. "We strive to be accessible" says nothing. "Search, booking and account settings were tested in May 2026; two issues remain" is checkable.
- Do not overclaim exemptions. Exemptions under the DOS law are specific, such as some older office documents and live media. Disproportionate burden must be argued case by case.
- Match the language of the service. If the service is in Swedish and English, publish the statement in both.
- Show progress. Remove fixed issues and add the date. A shrinking list of gaps is the best evidence that the organisation takes the duty seriously.
How do you keep the statement current?
Tie the statement to your release process, because a statement only stays true if someone updates it when the service changes.
DIGG's rule that the statement must reflect current accessibility means a yearly rewrite is not enough if you ship every two weeks. A workable routine:
- add an accessibility check to the definition of done for every feature;
- run automated scans in the build pipeline to catch regressions;
- retest affected journeys manually after major releases and redesigns;
- review the whole statement at least once a year and update the dates;
- route every feedback report into the backlog with an owner.
Companies under the European Accessibility Act benefit from the same routine. Our overview of what the EAA requires of companies describes the compliance information they publish instead.
Keep reading
From our work
Client Case: Lea BankLea Bank rebuilt its digital platform with Strapi, React, GrowthBook, GA4, and BigQuery to improve SEO, A/B testing, and marketing autonomy.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Is an accessibility statement mandatory in Sweden?
Yes, for organisations covered by the DOS law, which includes public bodies and some publicly funded providers such as private schools and care providers. Each covered website and app needs a statement. Private companies covered by the European Accessibility Act do not publish a tillgänglighetsredogörelse, but they must publish information on how their services meet the accessibility requirements, which uses the same test evidence.
Can we say we are fully compliant after an automated scan?
No. Automated tools check only part of the WCAG success criteria. Keyboard operation, focus order, meaningful labels and screen reader behaviour need manual testing. A conformance claim of "fully compliant" means every criterion passes for everything in scope, so it needs a complete assessment. Most services that are tested honestly end up partly compliant, with a list of gaps and dates for fixing them.
How often should we update the accessibility statement?
Swedish rules require the statement to reflect the service's current accessibility and to show the date of the latest update. In practice, update it whenever a release fixes or introduces an accessibility issue, and review the whole statement at least once a year. Teams that ship often should link the update to their release process so that the statement never lags behind the product.
Where should the accessibility statement be published?
For websites, DIGG's regulation requires a clearly presented link on the home page or on every page; most organisations put it in the footer. For apps, the statement must be available on the organisation's website or with the download information, and it may also be placed inside the app. The page itself must be accessible, so plain HTML is better than a PDF.
