ICT Accessibility in Norway: What Web Designers Need to Know

Most designers meet accessibility as a checklist item near the end of a project: check the contrast, add alt text, tab through the page, ship. In Norway it is closer to a legal baseline. ICT accessibility there is regulated, and the rules apply to far more than government portals. If you design websites, apps or self-service screens that Norwegian users will touch, it is worth knowing what the rules say and how they change your daily work.

This article is a practical read for designers, not legal advice. It explains who the Norwegian rules cover, which standard they point to, and what that means for colour, type, structure and testing. Always check the current text of the regulations and the latest official guidance before you rely on any detail below.

What ICT accessibility means in the Norwegian context

In Norway the topic is usually called universal design. The idea is that a solution should be usable by as many people as possible, regardless of disability, without needing special adaptations. Read more about ICT accessibility at the Tilsynet for universell utforming av ikt, the Norwegian authority that supervises digital accessibility. It describes its goal as a society without digital barriers, and it provides information and guidance to the organisations that have to follow the rules.

The term matters for designers because it changes the starting point. Universal design is not a special mode for a small group. It is the default way of building, and the people it helps include users with permanent disabilities, people with temporary injuries, older users and anyone using a screen in difficult conditions.

Who the Norwegian rules cover

According to the authority's English page on the Norwegian regulations on universal design of ICT, the regulations apply to private sector businesses, organisations and public sector bodies. They cover websites, mobile applications and self-service machines. Non-commercial use of social media, such as blogs and personal Facebook or Twitter accounts, is not covered.

That scope is wider than many agencies expect. A small online shop, a booking page for a local business and a banking app all fall within the idea of the rules. If you build products for clients in Norway, it is sensible to assume accessibility requirements will come up, and to discuss them at the start of the project instead of at the end.

Which standard applies

For websites, the regulations on that page point to WCAG 2.0 at level AA, with exceptions for three time-based media criteria: 1.2.3, 1.2.4 and 1.2.5. For self-service machines, a list of international standards applies. The page also gives the timeline: the regulations were approved on 21 June 2013 and took effect on 1 July 2013, with new ICT solutions expected to be universally designed from 1 July 2014 and existing ones from 2021.

Two practical notes follow. First, standards evolve, and the authority's current guidance may refer to a newer WCAG version than the one described on that page, so check the latest requirement before you write a specification. Second, even if a project only needs level AA, designing to the newer success criteria costs little and usually improves the product.

What this means for colour and contrast

Level AA includes contrast requirements for text, and this is where most designs fail first. Our guide to the WCAG contrast ratio explains the 4.5:1 and 3:1 thresholds in detail. In short: check every text and background pair, including buttons, placeholders, disabled-looking links and text over images. Light grey on white is the classic failure, and brand palettes with pastel accents often need a darker variant for text.

Do not rely on colour alone to carry meaning. A red error message with no icon or text label is invisible to some users. Pair colour with a symbol, a label or a pattern, and test the result with a colour-blindness simulator.

Typography, structure and navigation

Readable type is part of universal design. Use a comfortable base size, generous line height and a sensible line length, and let users scale text without breaking the layout. We cover the basics in how typography shapes the way people read. Structure matters as much as style. Use real headings in a logical order, label form fields, and make sure links and buttons say what they do.

Keyboard access is the next big test. Every interactive element should be reachable with the Tab key, have a visible focus state and follow a logical order. Many custom components, such as dropdowns, carousels and modals, fail here because they were built only for the mouse.

Universal design guidelines you can apply from the first sketch

Universal design guidelines are easiest to follow when they live in your process, not in a last-minute audit. A few habits make the difference:

• Put contrast, focus and target-size rules into your design system components, so every new screen starts compliant.
• Write alt text and link text as part of the content, not as an afterthought.
• Review prototypes with a keyboard and a screen reader before development starts.
• Test on real devices in poor light, with large text settings and with zoom at 200 percent.
• Keep a short accessibility log for each project, so decisions and known issues are documented.

If you are starting a system from zero, our article on building a design system from scratch shows where to put these rules, and the practical checklist for accessible websites gives you a working list to run through before launch.

Testing and documenting your work

Automated tools catch only part of the problems. They are good at missing alt text, low contrast and missing labels, and poor at judging whether a flow makes sense. Combine an automated scan with manual checks: keyboard-only use, a screen reader pass, zoom and text-scaling tests, and a read-through of every error message.

Write down what you tested, what failed and what you fixed. Clients in Norway may ask for evidence of accessibility work, and a clear record is also useful for your own team when the product changes. Because supervision is handled by an authority, being able to show a reasoned process is more useful than a vague claim of compliance.

Common mistakes designers make

• Treating accessibility as a plugin or overlay instead of fixing the underlying design.
• Checking contrast only for body text and forgetting buttons, icons and form borders.
• Using placeholder text as the only label for a form field.
• Hiding focus outlines because they look untidy.
• Shipping animated or auto-playing content with no way to pause it.
• Assuming that English-language guidance is enough for a Norwegian project. Parts of the official guidance, including WCAG materials, are available only in Norwegian, so plan time for translation or local support.

How to talk about accessibility with a Norwegian client

Clients rarely ask for accessibility by name, and when they do, they often mean different things. Some want a statement they can show to customers. Others worry about a complaint. Others simply want a site that works for older visitors. A short conversation at the start of the project, before any visual work, saves a lot of friction later.

• Ask whether the product falls under the regulations: is it a business or organisation site, an app or a self-service screen?
• Agree on the target standard and level in writing, and note the date and version you used.
• Decide who owns content accessibility after launch, since editors can break a compliant design by uploading images without alt text or by skipping heading levels.
• Budget time for testing and fixes. Accessibility work is cheapest when it is planned and most expensive when it is added after the build.

Presenting accessibility as part of quality, rather than as a legal threat, usually leads to a better conversation. It improves usability for everyone, tends to help search visibility through cleaner structure, and reduces support questions.

A simple accessibility timeline for a design project

Universal design guidelines fit naturally into the stages you already have. Here is one way to map them:

1. Discovery: confirm the rules that apply, the target level and who the users are, including those with access needs.
2. Visual design: build a palette that passes contrast checks, choose readable type and define focus and error states.
3. Prototype: check heading structure, labels and reading order, and tab through the flow.
4. Build: hand developers clear specifications for components, including keyboard behaviour and accessible names.
5. Test: run an automated scan, then manual keyboard and screen reader checks, then fix and retest.
6. Launch and maintain: document known issues, train editors and schedule periodic reviews.

This is not a heavy process. For a small project it can be a page of notes and a few hours of testing. What matters is that accessibility decisions are visible and made early, while changes are still cheap.

Frequently asked questions

Do the Norwegian rules apply to private companies?

Yes. According to the authority's regulations page, they cover private sector businesses and organisations as well as public bodies. Check the current text for exact obligations.

Does a personal blog need to follow them?

The regulations page says non-commercial use of social media such as blogs and Facebook is not covered. A business site is a different matter, so the purpose of the site matters.

Which WCAG level should I aim for?

Level AA is the standard referenced on the authority's page. Confirm the current WCAG version in the latest guidance, and treat AA as a floor, not a ceiling.

Are mobile apps and kiosks included?

Yes. The regulations cover websites, mobile applications and self-service machines.

In short

ICT accessibility in Norway is a regulated baseline that reaches private businesses, public bodies, websites, apps and self-service machines. For designers, the practical response is simple: build contrast, structure, keyboard access and clear language into your components from day one, test with more than a scanner, and keep a record of your decisions. Check the current requirements before every project, and treat universal design as part of good craft rather than a compliance chore.