Accessibility Statement

Public bodies are subject to regulations on universal design of ICT solutions, which implement the EU Web Accessibility Directive (WAD).

Requirement: All websites and mobile applications must have an updated accessibility statement published on the national accessibility portal.

Deadline: For websites, the deadline passed in 2023. For mobile applications, the requirement takes effect February 1, 2026.

Sanction: Missing publication or grossly deficient completion can result in corrective orders and daily fines (coercive fines).

The EU's Accessibility Directive, the European Accessibility Act (EAA), was adopted in 2019 and came into force in the EU/EEA on June 28, 2025. The directive aims to harmonize accessibility requirements for selected products and services in the internal market. As of today, EAA is not fully implemented in Norwegian law, but Norway is obligated to incorporate the directive through the EEA Agreement, and this work is ongoing.

EAA does not apply to all digital services, but to a defined set of products and services, including e-commerce, banking and financial services, transportation services, e-books, and electronic communication services. For digital services, this means requirements that the entire user journey – including purchase, payment, and customer dialogue – must be universally designed. Norwegian businesses offering such products or services to the EU/EEA market must therefore comply with the requirements now, even though Norwegian legislation is not yet finalized.

Unlike the public sector, private businesses should not use national accessibility portals. EAA instead requires compliance documentation (Declaration of Conformity), which must be included in terms of service or the product's technical documentation. This documentation must demonstrate that the solution meets accessibility requirements, often based on standards such as WCAG and EN 301 549.

• Scope: E-commerce, banking and financial services, transportation services, e-books, and electronic communication services.
• Documentation requirement: Declaration of Conformity in terms of service or technical documentation.
• Technical standard: WCAG 2.1 AA and EN 301 549.
• Consequence: Products and services that do not meet the requirements can be denied market access in the EU/EEA.

For digital solutions delivered to the public sector, separate and stricter requirements apply. Public organizations are fully covered by regulations on universal design of ICT solutions and are responsible for publishing accessibility statements via national portals. Although the formal responsibility lies with the contracting authority, vendors who develop and deliver software to the public sector have a clear obligation to deliver solutions that meet the requirements. In practice, this means that universal design must be ensured in the code itself, and that necessary documentation must be available so that the accessibility statement can be completed correctly.

A modern web solution can consist of thousands of pages. It is rarely practical to test them all. We select a representative sample based on WCAG-EM (Website Accessibility Conformance Evaluation Methodology). This typically includes:

• The homepage and navigation menus.
• Login and "My Account" functionality.
• Critical user journeys (e.g., application forms, shopping cart, booking).
• Pages with different content types (tables, video, maps, forms).
• Contact information and help pages.

We use tools like Axe-core or ARC Toolkit to identify syntax errors and programmatic violations.

What the tools find: Missing lang attributes, empty links, severe contrast errors, invalid HTML nesting (parsing), missing labels on form elements.

The limitation: Automated tools statistically find only 25-30% of all errors. A page can pass an automated test with zero errors and still be unusable for a blind user.

This requires deep technical insight. We inspect the code directly in the browser (DevTools) to verify semantic integrity.

Semantics: Is button used for actions and a for navigation? Are headings (h1-h6) coded logically, or just styled visually?

ARIA usage: Are WAI-ARIA attributes (e.g., aria-expanded, role="dialog") used correctly to convey state to assistive technologies? Incorrect use of ARIA is often worse than no ARIA.

Responsiveness (Reflow): We test that content scales correctly up to 400% zoom without information disappearing or requiring horizontal scrolling (WCAG 1.4.10).

This is the most critical phase. We test the solution as users actually experience it.

You must specify whether the statement is based on an external assessment (third-party audit), self-assessment, or a vendor assessment. An external assessment from a professional environment like PXL gives the statement higher credibility during inspections.

For each of the 47 success criteria in WCAG 2.1, status must be indicated. In case of deviation ("Non-compliance"), the system requires a free-text description.

Precision: It is crucial to describe the error technically precisely so that developers can reproduce it, but also understandably for users.

• Poor: "Images missing text."
• Good: "Informative graphics on the 'About Us' page lack alt attributes, making the information inaccessible to screen readers."

Consequence: You must describe the consequence for the user. This shows that the organization understands the severity.

Progress plan: Regulators expect known errors to have a remediation plan. Declaring errors without a plan can result in sanctions over time.

The law allows for exceptions if the requirements constitute a "disproportionate burden." This is a narrow exception that is often misunderstood. That it is expensive or technically challenging to fix an error is rarely valid grounds alone. The exception primarily applies if the organization would have to shut down core operations to afford the adaptation, or if the required technology does not exist. This must be thoroughly documented in the statement.