How public and private buyers turn accessibility into requirements that suppliers can price, prove and keep meeting after go-live.
In short
Swedish public buyers must, as a rule, set accessibility requirements when they procure anything people will use, under chapter 9, section 2 of the Public Procurement Act (LOU). For digital services, reference EN 301 549 and WCAG 2.2 AA, ask for test evidence, verify key journeys during evaluation, and write maintenance, fixing and audit duties into the contract.
Procurement decides accessibility long before any designer or developer touches the product. A platform bought without requirements can lock an organisation into barriers for years, and the DOS law still holds the buyer responsible. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for procurement officers, IT buyers and product owners who need tillgänglighetskrav i upphandling that are specific enough to evaluate and enforce.
What does the law require of public buyers?
Public buyers in Sweden must consider accessibility in the technical specifications of anything intended for use by people, and may skip it only for special reasons.
Chapter 9, section 2 of the Public Procurement Act (LOU, SFS 2016:1145) says that technical specifications for something to be used by natural persons shall take account of all users' needs, including accessibility for people with disabilities, unless there are special reasons. Where EU law sets mandatory accessibility requirements, the specifications must refer to them. The rule implements Article 42 of Directive 2014/24/EU.
According to the Swedish National Agency for Public Procurement (Upphandlingsmyndigheten), the buyer carries the burden of proof for any exception. For websites and apps, specifications must refer to the requirements of the Web Accessibility Directive, which in Sweden is implemented by the DOS law. Section 11 of that law also requires services on third-party platforms to be accessible as far as possible, which makes the tender the main lever.
Upphandlingsmyndigheten links the duty to procurements above the EU thresholds. Below the thresholds the rule does not apply in the same way, but nothing prevents a buyer from setting the same requirements, and for websites and apps the DOS law applies to the finished service regardless of contract value.
Private companies have no such duty, but those covered by the European Accessibility Act carry the compliance risk for their consumer services, so the same requirements protect them as buyers. A retailer that buys an e-commerce platform without accessibility terms still answers to the supervisory authority for the result.
Which standard should the tender reference?
Reference EN 301 549 for the legal benchmark and state WCAG 2.2 AA as the target level, so the delivered product meets both today's and the next version of the standard.
As of October 2026, the version cited for EU law is EN 301 549 V3.2.1, based on WCAG 2.1 AA, and V4.1.1, published in September 2026, moves to WCAG 2.2 AA. EN 301 549 is more than WCAG: it covers web content, documents, software, hardware, and documentation and support services, so name the clauses that apply.
Ask suppliers to answer clause by clause in a conformance report, stating for each criterion whether it is supported, partly supported or not supported, with a comment. Many vendors already publish such reports for their products, often in the VPAT format with an EN 301 549 edition. Treat a report as a starting point: check its date, the version tested and whether it covers the configuration you will actually use, since themes, plug-ins and custom content can break a product that conforms out of the box.
What you buy
EN 301 549 clauses to reference
Website or web app
EN 301 549 clauses to reference
Clause 9 (web), clause 10 if it produces documents, clause 12 (documentation and support)
Native mobile or desktop app
EN 301 549 clauses to reference
Clause 11 (software), clause 12
Platform or system that generates PDFs, emails or reports
EN 301 549 clauses to reference
Clause 10 (non-web documents) in addition to 9 or 11
Kiosk, terminal or device
EN 301 549 clauses to reference
Clauses 5 to 8 (generic, two-way communication, video, hardware) plus 11
Development or design services
EN 301 549 clauses to reference
Requirements on competence, process and test evidence, with the product clauses above as acceptance criteria
How to write accessibility requirements in seven steps
Good accessibility requirements combine a clear standard, evidence the supplier must provide, your own verification and contract terms that last beyond delivery.
- Scope who will use it. List the user groups, including staff and the public, and the critical journeys, such as applying, booking, paying and administering. This decides which clauses apply and what you will test.
- Set the mandatory requirement. State that the delivered solution shall meet the applicable clauses of EN 301 549 and WCAG 2.2 level AA, including future releases during the contract term.
- Ask for evidence, not promises. Require a conformance report against EN 301 549 for the offered product, with the test method, date, scope and known gaps. A recent third-party audit is stronger than a self-assessment.
- Verify during evaluation. Ask shortlisted suppliers to demonstrate a critical journey with keyboard only and with a screen reader. A ten-minute demonstration reveals more than a long questionnaire.
- Evaluate competence for services. For design and development services, Upphandlingsmyndigheten notes that requirements must be proportionate; ask for named accessibility competence, a test process that includes manual testing, and examples of delivered work.
- Write contract terms. Require fixes within set times by severity, accessibility testing before each release, a maintained accessibility statement or compliance information, the right to audit, and remedies if requirements are not met.
- Follow up during the contract. Test after major releases, review the supplier's reports and record findings, as our comparison of automated accessibility testing and a manual audit suggests, with scans for regressions and manual checks for releases.
What are the most common mistakes in tenders?
The most common mistake is a single sentence such as "the solution shall be accessible", which no supplier can price and no buyer can enforce.
- No version or level. "WCAG compliant" without a version and level is open to interpretation. Write "WCAG 2.2 level AA via EN 301 549".
- Only the public interface. Administrative views used by staff also fall under the requirements and are often the least accessible part.
- Accepting a scan as proof. An automated report alone cannot show conformance; ask for the manual test method.
- No obligation after go-live. Without release testing and fix times, accessibility decays with every update.
- Forgetting documents and integrations. Generated PDFs, emails and embedded third-party widgets are part of the service users experience.
- Requirements nobody can evaluate. Asking every bidder for a long free-text description of their accessibility work produces answers that cannot be compared. Ask for specific evidence and score it against stated criteria.
The supplier's evidence should also feed your own accessibility statement, so require it in a form you can reuse.
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 it mandatory to set accessibility requirements in public procurement in Sweden?
As a rule, yes. Chapter 9, section 2 of the Public Procurement Act requires technical specifications for anything to be used by natural persons to take account of accessibility for people with disabilities, unless there are special reasons, and the buyer has to justify any exception. When EU law sets mandatory accessibility requirements, as for public websites and apps, the specifications must refer to them.
Should we require WCAG 2.1 or WCAG 2.2?
Require WCAG 2.2 level AA through EN 301 549. As of October 2026, the version of EN 301 549 cited for EU law is based on WCAG 2.1 AA, but the newly published version is based on 2.2 AA. A solution that meets 2.2 AA also meets 2.1 AA, so requiring the newer level avoids a second round of work during a contract that may run for years.
How do we verify a supplier's accessibility claims?
Combine documents and practice. Ask for a conformance report against EN 301 549 with method, scope, date and known gaps, preferably from an independent tester. Then verify yourself: during evaluation, ask the supplier to complete a critical journey with keyboard only and with a screen reader. After delivery, run an acceptance test and keep testing after major releases.
Can accessibility be an evaluation criterion instead of a requirement?
Both are possible, and they serve different purposes. Use mandatory requirements for the legal baseline, such as WCAG 2.2 AA via EN 301 549, so no supplier can trade it away. Use evaluated criteria for what goes beyond the baseline, such as user testing with people with disabilities or stronger competence. Upphandlingsmyndigheten reminds buyers that requirements must be proportionate to the contract.
Sources
- Lag (2016:1145) om offentlig upphandling, riksdagen.se
- Directive 2014/24/EU on public procurement
- Upphandlingsmyndigheten: Upphandla tillgängliga varor, tjänster och miljöer
- AccessibleEU: The European accessibility standard EN 301 549 has been updated (7 September 2026)
- Lag (2018:1937) om tillgänglighet till digital offentlig service
