WEBSITE ACCESSIBILITY AUDIT

It depends on what you sell and to whom. The Swedish Accessibility Act (tillgänglighetslagen, SFS 2023:254), which implements the European Accessibility Act (Directive (EU) 2019/882) in Sweden, has applied since 28 June 2025. The law covers certain services aimed at consumers – including e-commerce, banking services, e-books and passenger transport – and supervision is handled by authorities including the Swedish Post and Telecom Authority (PTS).

Microenterprises that provide services are exempt. A microenterprise is one with fewer than ten employees and an annual turnover or balance sheet total of no more than EUR 2 million. A B2B company with no sales to consumers is usually not covered by this law. Public bodies – and private operators that run schools, healthcare or social care with public funds – are instead governed by the Swedish Act on Accessibility to Digital Public Services (lagen om tillgänglighet till digital offentlig service), which has different requirements and different supervision. If you supply the public sector, you will encounter the requirements through procurement.

We give guidance on whether you are likely to be covered, not a legal opinion – if you are unsure, we recommend checking with PTS. More and more customers, procurers and users also demand accessibility, whatever the law says – and a website that cannot be used with a keyboard loses visitors.

If you offer consumer services covered by the Swedish Accessibility Act – for example e-commerce or banking services – and are not a microenterprise, yes. The law does not mention WCAG, but in practice the European standard EN 301 549 is used to show that the requirements are met, and it is based on WCAG level AA. We audit against WCAG 2.2 AA – the latest version, which builds on 2.1.

The Swedish Accessibility Act applies to the service as a whole, and a mobile app used to provide the service is therefore covered in the same way as the website. Documents that are part of the service – such as contracts, invoices or product information in PDF – should in practice also be accessible, because an inaccessible PDF stops the user just as much as an inaccessible page. We audit apps and documents on request.

An accessibility statement is a page on the website that describes how well it meets the accessibility requirements, which known issues exist, when they are planned to be fixed and how users can report problems. Bodies covered by the Swedish Act on Accessibility to Digital Public Services are required to have one. Companies covered by the Swedish Accessibility Act must provide information on how the service meets the requirements, and a statement is a clear way of doing that. We produce the material based on the audit.

The audit is done against WCAG 2.2 level AA – the latest version of the guidelines. Automated tools only find what can be measured by a machine – missing alt texts, contrast values, invalid HTML. The rest requires a person to use the website the way a user with a disability does:

• Keyboard and focus – can menus, buttons, dialogs and forms be reached without a mouse, and is it visible where you are?
• Contrast – text, buttons, icons and field borders against the background, also on hover and in dark mode.
• Alt text and structure – descriptive alt texts, heading hierarchy, landmarks and link texts that mean something outside their context.
• Forms – labels, error messages in text (not just red colour) and the ability to correct mistakes.
• Screen readers – a review with VoiceOver and NVDA of the flows for finding, understanding, buying or getting in touch.
• Motion – can animations be paused, and is the system setting for reduced motion respected?

Every issue in the report is linked to a WCAG criterion, location, severity and suggested fix. We recommend auditing the page templates and flows your business depends on – homepage, product pages, forms and checkout – rather than every subpage.

Most issues arise when a design is approved on a large screen with a mouse and nobody tests any other way of using it. Four patterns recur whatever the industry and platform:

• Images without alt text – common even on new websites, and the easiest to fix.
• Contrast that is too low – light grey body text, white text on light photographs and buttons in brand colours that have never been measured.
• Menus that do not work with a keyboard – especially mega menus and mobile menus that only open with a mouse or touchscreen.
• Removed focus indicator (outline: none) – keyboard users cannot see where they are.

Almost everything can be fixed within the existing design and existing content. Menus and forms may require the component to be rebuilt – rarely the whole website.

Five minutes is enough to see whether the website has basic problems – and whether a full audit is justified.

• Put the mouse aside and press Tab through the homepage. Can you see where you are? Can the menu be opened? Do you get stuck anywhere?
• Zoom to 200 per cent in the browser. Does content disappear, or do elements overlap?
• Open the contact form, leave the fields empty and submit. Do you understand what went wrong without seeing the colour?
• Run a Lighthouse report in Chrome and read the accessibility section. It finds what can be measured by a machine, not the rest.
• Turn on the screen reader on your phone (VoiceOver on iPhone, TalkBack on Android) and try to find your phone number.

If the website fails these tests, there are more issues below the surface. If it passes them, it is still only a start – WCAG 2.2 AA covers considerably more criteria than a quick test can reach.

Much of what makes a website accessible also makes it readable for search engines and AI assistants: the heading hierarchy, the alt texts, the link texts and the semantic HTML. We do not promise that better accessibility in itself raises your rankings. But technical SEO and accessibility are in practice two audits of the same foundation – if you do one, there are good reasons to do the other at the same time.

It depends on the scope. A website with around ten page templates and a contact form usually takes one to a few weeks from start to finished report, because the manual review with a keyboard and screen reader takes time. An e-commerce website with checkout and account pages takes longer. We give a timeline together with the quote.

A report left in a drawer does not make any website more accessible. That is why the same team does the audit and the fixes, directly in your platform – Webflow or a coded website with a headless CMS. We fix in order of priority – blocking issues first, cosmetic ones last – and ideally in the design system or component library, so that every page inherits the improvement, including the ones built later.

If the issues are so extensive that a rebuild makes more sense, we recommend one and give you a basis for comparison. The audit is often combined with a review of the user experience as a whole – how one works is described in the guide to how a UX audit works. Once the fixes are in place, we produce the material for your accessibility statement. New pages and features can be followed up per job or within a maintenance agreement, if you want.

Rarely. The most common issues – contrast, alt text, form labels, focus styles and heading structure – are fixed within the existing design and existing content. Menus and forms may need to be rebuilt as components. Only when the basic structure is wrong, for example a website built entirely on images or a platform without control over the HTML, is a rebuild the better option. The audit shows which applies.