Accessibility statements backed by a WCAG audit

An accessibility statement is a public self-declaration of how well a website or app meets the requirements for accessible ICT. Every public organisation in Norway must publish one in uustatus.no. It shows the status of each of the 48 requirements, explains what doesn't work and gives users a way to report problems.

A statement is only as good as the testing behind it. Below we cover what the statement is and what it must contain, and the rules for the public and private sectors, including the EAA. We also explain how a WCAG audit is done, and how to keep the documentation up to date so it stands up to an inspection.

We're developers. We fix the issues the audit finds in the code, or we show your developers exactly how to do it.

What is an accessibility statement?

An accessibility statement is a public document that describes how far a website or mobile app meets the requirements for accessible ICT. In Norway, the requirements are based on the international standard WCAG 2.1 (Web Content Accessibility Guidelines), levels A and AA.

The statement is useful to several groups:

• Users: it tells people with disabilities about barriers on the website or app, so they know what to expect, and it gives them a simple way to report problems.
• Your organisation: you have to go through the website or app systematically, and that shows you what to fix first.
• The regulator: it's the basis for the inspections and statistics of the Norwegian Authority for Universal Design of ICT (Uu-tilsynet).
• Legal protection: a correctly completed statement shows that you take the law seriously and have a plan to fix the findings. That lowers the risk of sanctions.

For public organisations in Norway, publishing the statement in the national uustatus.no service is mandatory.

The statement isn't the same as the audit report. The report is written for developers and says exactly where the issues are and how to fix them. The statement is written for users and says what works, what doesn't and what you're doing about it. You need both.

What goes in the statement?

A good statement is honest and specific. It should answer what users want to know without them having to understand WCAG. It usually contains:

• Conformance status: whether the website or app fully conforms, partially conforms or doesn't conform to the requirements, and the status of each individual criterion.
• The failures: which criteria aren't met, and where the issues are.
• The impact on users: which groups are affected, for example users who are blind, have low vision or have limited fine motor control.
• The basis for testing: how the website or app was assessed, and when.
• Feedback: how users can report issues or ask for the content in another format.

The link to the statement must be easy to find, ideally in the footer of every page. A statement you can only find if you already know where it is helps nobody.

Write for the user. "Failure of 1.3.1" means little to most people. "The appointment booking form can't be filled in with a screen reader, because the fields have no names. Call us and we'll book for you" tells users what's wrong and what they can do in the meantime.

Public sector: the regulation and uustatus.no

To understand the requirements, you have to separate the rules for the public and private sectors. The technical WCAG requirements often overlap, but the documentation duty and the legal basis are different.

Public bodies are covered by the regulation on universal design of ICT solutions, which implements the EU Web Accessibility Directive (WAD).

• Requirement: all websites and mobile apps must have an up-to-date accessibility statement published in uustatus.no.
• Deadline: the deadline was 1 February 2023 for websites and 1 February 2024 for apps. Each app needs its own statement.
• Sanctions: failing to publish a statement, or publishing a seriously deficient one, can lead to an order to correct it and daily fines.

Private sector and the EAA

The European Accessibility Act (EAA) was adopted in 2019 and has applied in the EU since 28 June 2025. Its aim is to harmonise accessibility requirements for selected products and services in the single market. The EAA isn't yet fully part of Norwegian law, but Norway is obliged to adopt the directive through the EEA Agreement, and that work is under way.

The EAA only covers a defined set of products and services. For digital services, it means every step a customer takes, including purchase, payment and customer contact, must be accessible. Norwegian businesses offering these products or services in the EU therefore have to deal with the requirements now, even though Norwegian law isn't final yet.

For a Norwegian online shop or bank, it makes sense to do the work before the requirement arrives. An audit now shows how far you have to go. A voluntary accessibility statement on your website also makes it easy for customers to see that you take it seriously. When the requirement comes, most of the documentation is already in place.

Private businesses don't use uustatus.no. Instead, the EAA requires businesses to document how their service meets the requirements, either in the terms of service or in the product's technical documentation. The documentation is often based on standards such as WCAG and EN 301 549.

• Scope: e-commerce, banking and financial services, transport services, e-books and electronic communication services.
• Documentation duty: a description of accessibility in the terms of service or the technical documentation.
• Technical standard: WCAG 2.1 AA and EN 301 549.
• Consequence: products and services that don't meet the requirements can be refused access to the EU and EEA market.

How we carry out a WCAG audit

A valid accessibility statement rests on a thorough technical audit. A statement based on assumptions or simple automated tests doesn't meet the legal requirement for the assessment to be "based on an actual evaluation". We follow a fixed method that combines automated scanning with manual testing.

Sampling. A large website can have thousands of pages, and testing all of them rarely makes sense. We choose a representative sample using WCAG-EM (Website Accessibility Conformance Evaluation Methodology). It typically covers the homepage and navigation menus, sign-in and "My page", and critical user flows such as application forms, shopping basket and booking. It also includes pages with different content types, such as tables, video, maps and forms, along with contact and help pages.

Automated testing. We use tools such as axe-core and ARC Toolkit to find syntax errors and programmatic failures. Examples are missing lang attributes, empty links, serious contrast failures, invalid HTML structure and form fields without labels. The limitation is that automated tools can only check about 20–30% of the WCAG criteria (Deque). A page can pass an automated test with zero errors and still be unusable for a blind user.

Manual code inspection. This is where technical depth matters. We inspect the code directly in the browser with DevTools to check that the semantics hold up. Is button used for actions and a for navigation? Are the headings h1 to h6 coded in a logical order, or just styled to look like headings? Are WAI-ARIA attributes such as aria-expanded and role="dialog" used correctly to convey state to assistive technology? Wrong ARIA is often worse than no ARIA. We also check that content scales correctly up to 400% zoom without information disappearing or needing horizontal scrolling (WCAG 1.4.10).

Testing with keyboard and screen reader. This is the most important part, because it's where we test the website the way users actually experience it. With the keyboard, we check that the tab order follows the reading order, that focus is always visible, that every interactive element can be reached and that there are no keyboard traps. With the NVDA, JAWS and VoiceOver screen readers, we check that forms announce error messages correctly, that dynamic content is announced with aria-live, and that images have meaningful alternative text.

How to create an accessibility statement in uustatus

Public organisations create the statement in uustatus.no, the accessibility statement service run by Digdir, the Norwegian Digitalisation Agency. The steps are always the same:

1. Test the website or app. Go through a representative sample of pages and user flows against WCAG 2.1 AA, manually and with tools.
2. Log in to uustatus.no and create a statement for the website or app.
3. Fill in the status of each requirement: met, not met or not applicable.
4. Describe the failures and what they mean for users, with a plan for when they'll be fixed.
5. Publish the statement and link to it from the website footer or from the app.
6. Update it when the website or app changes, and at least once a year.

Steps 3 and 4 are where most statements fall short. Pasting in the audit report won't get you far. This is what counts:

Basis for testing. You must state whether the statement is based on an external assessment (a third-party audit), a self-assessment or a supplier assessment. An external assessment gives the statement more credibility in an inspection.

Non-conformance. You state the status for each of the 48 WCAG 2.1 success criteria. Where there's a failure, the system requires a free-text description. Describe the issue precisely enough for developers to reproduce it, and clearly enough for users to understand it:

• Poor: "Images are missing text."
• Good: "Informative graphics on the About us page are missing an alt attribute, so the information isn't available to screen reader users."

Impact. You must describe what the issue means for users. It shows that your organisation understands how serious it is.

Remediation plan. The regulator expects known issues to have a plan for fixing them. Listing issues without a plan can eventually lead to sanctions.

Common mistakes in accessibility statements

We see the same mistakes again and again when we review statements others have written:

• Conformance without testing: criteria are marked as met without anyone testing them manually. That falls apart quickly in an inspection.
• Automated scan only: the statement relies on a tool that finds less than a third of the issues, so it paints too rosy a picture.
• Vague failures: "Some forms have issues" helps neither the user nor the developer. Each failure must say where the issue is and who it affects.
• No plan: known issues stay listed year after year with no date for when they'll be fixed.
• Third parties forgotten: maps, chat and video players haven't been assessed, even though the organisation is responsible for them.
• Hidden link: the statement exists, but users can't find it.

Most of these go away when the statement is based on a proper audit.

How often must the statement be updated?

The statement must be updated at least once a year. It should also be updated whenever the website or app changes so much that the status no longer holds, for example after a redesign, a new form or a new sign-in flow.

We recommend planning the next audit as soon as the statement is published. That makes the update a fixed routine. It also stops the statement listing issues that were fixed long ago, or missing new ones that have crept in. Between audits, automated tests catch the simple issues on every change, and a manual review covers the rest once a year.

The disproportionate burden exception

The law (section 18) allows an exception where meeting the requirements would be a "disproportionate burden". The exception is narrow and often misunderstood. A fix being expensive or technically demanding is rarely a valid reason on its own.

The exception mainly applies if the organisation would have to shut down core operations to afford the change, or if the technology needed doesn't exist. If you use the exception, it must be thoroughly documented in the statement. We help you assess whether it actually applies before it goes in.

Suppliers and third-party services

One of the most common causes of non-conformance is third-party content. That can be maps such as Google Maps, chatbots, video players from Vimeo and YouTube, or recruitment systems embedded in an iFrame.

The main rule is that the organisation that owns the website is legally responsible for all its content, including third-party services. That means you have to set requirements for your suppliers. A thorough WCAG audit uncovers issues in these modules, and you can use the report in contract negotiations and supplier follow-up to demand fixes.

If you supply software to the public sector yourself, it works the other way round. Formal responsibility for the statement lies with the client, but the supplier has a duty to deliver software that meets the requirements. In practice, accessibility has to be built into the code itself, and the client needs documentation to complete the statement correctly.

That's why uustatus.no has its own supplier portal. Suppliers can enter a finished supplier assessment there, which customers can import straight into their own statement. It saves customers a lot of work, and a green supplier assessment is a strong competitive advantage.

What does an accessibility statement cost?

The accessibility statement is the end result of a thorough technical audit. It isn't a form you can fill in on its own. The work requires manual testing and technical understanding. For smaller websites, a full WCAG audit with an accessibility statement starts at NOK 35,000.

For larger websites and systems, the price depends mostly on how large the sample has to be:

• Number of page templates: each template is tested, however many pages use it.
• User flows: sign-in, multi-step forms and checkout take longer to test than plain content pages.
• Apps: an app needs its own audit and its own statement.
• Remediation: how much is wrong decides what the fixes cost.

We fix the findings at an hourly rate from NOK 1,500, or at a fixed price once the audit has made the scope clear.

If you only need to update a statement we've written before, the job is smaller. We test what's changed since last time, check that the fixes hold and update the status of the criteria affected.

From audit report to fixed code

We audit as developers. A long list of issues doesn't help much on its own, so we put the weight on fixing them. When we help you with your accessibility statement, you get:

• Technical audit: a full review of code and content against WCAG 2.1 AA.
• Prioritised action list: issues sorted by severity, from blocking failures to minor findings.
• Code examples: we show your developers exactly how to fix each issue in the code, in React, Vue or HTML.
• The statement itself: we write the text for uustatus.no or the EAA documentation, make sure it's precise and help you publish it.
• Retest: when the issues are fixed, we test again, so the statement shows the real status.

Everyone on our team has more than ten years of experience, and we build our own systems to WCAG 2.2 AA. A correctly completed statement shows users and the regulator that you're in control of your website.