Web accessibility and WCAG for websites

We audit websites and apps for accessibility, and because we're developers and designers, we also fix what we find. We fix the issues in the code, the design and the content, or we show your developers exactly what needs to change.

Many organisations treat web accessibility as a checklist to get through to avoid fines. In practice, it's about people being able to use what you've built. It's a quality requirement for the whole website, and it affects far more people than most expect.

When a website is accessible, the code is clean, the design is logical and the language is clear. That makes it work better for everyone. It helps someone who's blind and uses a screen reader, and someone with a broken arm who has to navigate by keyboard. It also helps someone on the bus with the sun on the screen and their glasses at home. An accessible website is usually better coded, faster and easier to maintain as well.

Is accessibility a legal requirement?

Yes. Under the Equality and Anti-Discrimination Act and the regulation on universal design of ICT solutions, Norwegian law requires ICT systems aimed at the public to be accessible. The requirement applies to public and private organisations alike, and it covers websites, online shops, apps and self-service systems.

Many have seen this as mainly a public sector concern. With the European Accessibility Act (EAA), the rules are getting stricter for private businesses too. The directive covers e-commerce, banking, transport, e-books and electronic communication services, among other things. It has applied in the EU since the summer of 2025, and Norway is due to adopt it through the EEA Agreement. If you run an online shop, it's worth getting ahead of it.

The Norwegian Authority for Universal Design of ICT (Uu-tilsynet) carries out inspections and can impose daily fines on organisations that don't fix what it finds. We explain how the rules apply to the public and private sectors on our page about the accessibility statement.

WCAG and the rules in Norway

To measure whether a site is accessible, we use the international standard WCAG (Web Content Accessibility Guidelines). Its criteria are split into three levels: A, AA and AAA. The law requires level AA, which covers the barriers that affect the most users.

In Norway the current requirement is WCAG 2.1 level AA, and the regulator checks 48 criteria when it inspects a public website. WCAG 2.2 is the latest version and has 55 success criteria at levels A and AA. Among other things, it adds criteria saying that focus mustn't be hidden behind other elements and that buttons and links must be large enough to hit. It also says signing in mustn't require the user to remember or solve something. We build our own systems to WCAG 2.2 AA, so they'll still comply when the requirement is raised.

It can look technical, but it all rests on four principles:

1. Perceivable: users must be able to take in the content. That means good contrast for people with low vision, and text descriptions on images so blind users can have them read aloud.
2. Operable: everything must work with a keyboard. If the mouse doesn't work, or the user has a motor impairment, the site must still be fully usable.
3. Understandable: navigation must be predictable, error messages must make sense and the language must be clear. A button should look like a button.
4. Robust: the code must be good enough to work with different assistive technologies, such as screen readers, and across browsers and devices.

Why accessibility pays off

We prioritise accessibility in all our projects. The law requires it, and it makes business sense.

You reach the whole market. Between 15 and 20% of people in Norway have a disability, and the population is getting older. If your website doesn't work for them, you're effectively sending one in five customers straight to a competitor.

Google reads your site much like a screen reader does. Search engines care about semantic code, logical headings and good descriptions of content. That's why good accessibility often goes hand in hand with good technical SEO.

The curb-cut effect. When cities lowered kerbs for wheelchair users, it turned out to help parents with prams, people with wheeled suitcases and cyclists too. The same goes online. Good contrast and clear language help people with low vision, and everyone reading on their phone in sunlight. Forms with clear error messages mean fewer abandoned purchases, whoever the customer is.

Common accessibility mistakes to avoid

The market is full of quick fixes for accessibility. These are the ones to steer clear of:

• Accessibility overlays: you may have seen a small icon that opens a menu for changing contrast or font size. Experts and users alike warn against them. They don't fix the issues in the code, and they can make the site harder to use for people who already have their own assistive technology.
• Relying on automated tests alone: "We ran a scan and got a green light." Unfortunately, that doesn't mean the site meets the requirements. Automated tools can only check about 20–30% of the WCAG criteria (Deque). They can check whether an image has a text description, but not whether the description makes sense, and they don't notice when focus disappears as a dialog opens.
• Treating it as the developer's job alone: accessibility depends on the design and the content as much as on the code. More on that below.

Who is responsible?

Legally, the organisation that owns the website is responsible. The supplier still has a duty to deliver systems that meet the applicable requirements. If you write WCAG into your contract with the supplier, it's clear who has to fix what.

In practice, accessibility happens in three places:

• Design: contrast, font size, clear buttons and visible focus.
• Development: semantic code, keyboard control, focus and the right names and roles for screen readers.
• Content: plain language, alternative text, meaningful link text and captions on video.

If the designer delivers low contrast, the developer can't code around it. If an editor adds images without alternative text, a correct template won't help much. That's why designers, developers and editors all need to be involved from the start.

How we carry out an accessibility audit

First we choose what to test. We don't need to test every page, only every page template and the most important user flows. That means the homepage, an article, search, forms, sign-in and the whole checkout in an online shop.

Then we test in two rounds:

• Automated tools quickly catch the simple issues, such as missing alternative text, low contrast and empty links.
• Manual testing catches the rest. We go through the site using only a keyboard, with screen readers such as NVDA and VoiceOver, and with zoom up to 400%. In an online shop, we complete a whole purchase without looking at the screen.

Each finding gets a reference to the WCAG criterion it fails, a description of what the user experiences and a suggested fix. We rank the findings by severity, so you can see what stops users completely and what can wait.

How we fix the issues in the code

We work directly in the code, whether you use React, Vue, WordPress, Optimizely or Sanity, and we fix the issues where they start.

• Technical clean-up: we replace meaningless markup, known as div soup, with semantic HTML and make sure focus management works. This matters most in single-page applications (SPAs), where page changes often confuse screen readers.
• Components first: an issue in a button or a form field often appears on a hundred pages. Fix the component, and the issue disappears everywhere at once.
• Closing findings: if you have a report from the regulator or an auditor, we deal with the issues that block use first and then work systematically through the list.

Do you need to rebuild everything? Rarely. Typical findings are missing ARIA labels, broken form validation and images without alternative text, and we can fix those without breaking the design. If the site is being rebuilt anyway, we build accessibility in from day one. That costs far less than fixing it afterwards.

Can your own developers fix the issues?

Yes. If you have your own developers or another supplier, we write the report so they can work straight from it. Each finding points to where the issue is, which criterion it fails and how to fix it.

Many clients choose a middle ground. Your team fixes the simple issues, and we take the hard ones, such as focus management in dialogs, accessible menus and complex forms. Once the fixes are in, we test again and confirm what's been closed.

Accessibility statement

An accessibility statement is a legally required document that has to be visible on the website. It must say honestly where the website stands:

• How accessible is the website?
• Which known issues haven't been fixed yet?
• How can users report it if they get stuck?

All public organisations must have one today, and it's filled in through uustatus.no, the reporting service run by Digdir, the Norwegian Digitalisation Agency. With the EU directive, the requirement will also reach large parts of the private sector. Saying "we're working on it" is no longer enough: you have to document the work. We help you through the whole process, from the technical assessment to a completed statement.

What does an accessibility audit 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 four things:

• Number of page templates: ten templates take longer than three, however many pages use them.
• Complexity: sign-in, multi-step forms and dynamic content need more testing than plain article pages.
• Number of user flows: each flow is tested from start to finish with a keyboard and a screen reader.
• How much is wrong: this decides what the fixes cost, not what the audit costs.

We fix the findings at an hourly rate from NOK 1,500, or at a fixed price when the scope is clear after the audit.

Staying accessible after the audit

A website changes every week. New pages, images and features can introduce new issues, so accessibility has to become part of everyday work.

• Training: we train your editors, designers and developers, so you can keep the website accessible yourselves without depending on consultants forever.
• Design system: we build accessibility into your design system. That way the buttons, colours and forms are right before they're ever used on the website.
• Regular checks: automated tests catch the simple issues on every change, and a new manual review after larger changes keeps the statement up to date.

Why choose PXL?

What sets us apart from pure advisory firms is that we're developers and designers at heart. Where others hand you a PDF full of problems, we deliver working code.

We understand why an issue happened, and we know how the architecture has to change to remove it for good. We deal with the issues that stop users first, then work systematically through the rest. Everyone on our team has more than ten years of experience, and we build our own systems to WCAG 2.2 AA. Our website scores 100 for accessibility in Google Lighthouse. Read how we went from 90 to 100.