Skip to main content

Guides

The Norwegian accessibility statement on uustatus.no

What a Norwegian accessibility statement (tilgjengelighetserklæring) is, who must publish one, how to complete it on uustatus.no, and how Synli findings map straight into it.

By Eivind Pihl Martinsen, Synli.aiLast updated June 5, 2026

An accessibility statement tells the public how accessible a website or app is, which requirements it meets, and what is not yet in place. In Norway this statement (tilgjengelighetserklæring) is mandatory for the public sector, and it is created and published through the official government solution uustatus.no. This guide walks through what it requires and how Synli shortens the work.

What is an accessibility statement?

The statement is a standardised self-report based on the EU Web Accessibility Directive (WAD). It documents status against the WCAG requirements, lists content that does not conform, and provides a feedback channel for users. It is not a guarantee of full accessibility — it is an honest, verifiable status report.

Who must have one?

  • Every public-sector body must publish an accessibility statement for each website and app.
  • The requirement arrived with the Web Accessibility Directive and applies to the public sector in addition to the 48 success criteria they must meet.
  • Private organisations currently have no equivalent legal duty to publish a statement, but many do so for transparency and to be ready for future requirements.

The uustatus.no workflow

From audit to published statement
  1. AuditTest the solution against the WCAG criteria that apply to your sector
  2. Assess each requirementMark as met, not met, or not applicable — with a rationale
  3. Complete it on uustatus.noSign in, register the solution, and record status per requirement
  4. Publish and maintainLink the statement visibly and update it when the solution changes

How Synli feeds findings into the statement

The slow part is not the uustatus.no form itself — it is knowing what the status actually is for each requirement. That is where Synli does the heavy lifting: a scan links every finding to a specific WCAG success criterion, with a confidence level and code location, and separates tool-verified findings from items needing human review.

  • Synli groups findings per WCAG criterion, so they map directly to the rows of the uustatus statement.
  • Each finding is labelled verified or needs-human-review, so you know which rows you can set confidently and which need a human judgement.
  • AI vision analysis judges whether alt text actually describes the image — a classic source of error in self-reporting.
  • Structured Markdown export lets you take findings straight into an AI coding assistant to fix them before you record status.
A Synli report with findings grouped per WCAG criterion, ready to transfer into a uustatus.no statement.
Findings grouped per WCAG criterion map directly to the rows of a uustatus statement.

Practical steps

  1. Run a Synli scan of the solution and clear the deterministic failures.
  2. Review the findings marked needs-human-review and reach a judgement.
  3. Create or update the statement on uustatus.no and record status per requirement.
  4. Publish the statement somewhere visible (typically the footer) and link the feedback channel.
  5. Set a routine to re-scan and update the statement on significant changes.

Sources