Skip to content

Universal design for developers

Developers have a particular responsibility for universal design, as most of the functionality that increases accessibility is controlled by code.

The Web Content Accessibility Guidelines

The Gjensidige brand is inclusive and people-friendly, making accessibility one of our personality traits.

As our digital solutions share resources across of Norway, Sweden and Denmark, we are required to comply with Web Content Accessibility Guidelines 2.1. While we must comply with A and AA, we aim to satisfy AAA.

As a developer in Gjensidige, you should be broadly familiar with its contents and consult it when in doubt.

Your checklist

Keep these questions in mind when working on your code:

  • Have you validated the HTML (W3C Validator)
  • Do you use semantic HTML?
  • Does keyboard navigation yield visible focus markers with a logical tab sequence?
  • Do you use empty alternative text for decorative images and a short descriptive alternative text for informative images?
  • Is the heading structure correct?
  • Are clickable areas large enough, and with enough space around them?
  • Do changes happen without the user asking for them?
  • Are error messages visible and specific enough?
  • Are landmarks used to organize the page?
  • Is the correct language code defined in the code?
  • Can you enlarge the text up to 200% without losing information?
  • Have you tested the code using both automatic and manual tests?

Useful tools

Use both automatic and manual tests as a part of the development process. 

Use the design system

Gjensidiges’ design system is developed with accessibility in mind. However, it is not perfect, but a great starting point. We are constantly working on improving accessibility. If you discover any issues with the accessibility, please notify us in the slack channel #builders-core or create a PR with suggested improvements.

Semantic HTML

Semantic HTML adds meaning to the content beyond just the presentation. Browsers create an accessibility tree when using semantic HTML, which is used by screen readers. Writing semantic HTML will also add quality to our SEO.


  • Non-semantic elements: <div> and <span>. 
  • Semantic elements: <h1>..<h6>, <label>, <strong>, <table>, <article>, <ul>, <ol>, <li>, and more (around 100 semantic elements exists).
  • Landmark-specific elements (semantic): <header>, <footer>, <aside>, <main>, <nav>, and more.


WAI-ARIA is a specification written by W3C that adds additional HTML attributes to improve accessibility. The first rule of ARIA is not to use it in cases where there exists a native HTML element.

While adding ARIA can improve accessibility, it needs to be added with intention and tested thoroughly. Using ARIA can potentially cause accessibility problems if not used correctly.

Keyboard navigation

Some users depend on keyboard navigation (using the tab button to move from one element to another). For these users, it’s important that

  • the focus marker is highly visible at all times – ideally even more so than any markers created by the mouse hover effect
  • all areas are accessible with keyboard
  • that the tab sequence is logical

Alternative text

All images should contain an alternative text. If it is merely decorative (as opposed to informative), alternative texts might create unnecessary noise for screen reader users, lessening their experience. To avoid such noise, images that are considered decorative – either in a particular context or because of its motive – should have an empty alternative text (alt=""). Informative images that adds context to the page should include a short, descriptive alternative text.

Heading structure

Headings must be formatted with the correct level and should not be chosen based on visual preferences. Users will skim the page using heading levels. All pages should contain one <h1> title followed by <h2> titles and then <h3>, and so on. Don't skip heading levels. HeadingsMap is a plugin that can be used to view the heading structure of the page. 

Clickable areas

All areas that are meant to be clicked must be easy to click. Touch screen users and users with impaired coordination benefit from large clickable areas and with some space around them.

Example: A code that defines checkboxes and radio buttons should allow the user to take action by clicking on the text as well as the checkbox/radio button.

Error messages

If a user enters an invalid input in a form, they must be alerted. The alert should include information about

  • where the error is located
  • the nature of the mistake (e.g. incorrect digits for a phone number)
  • how the user can fix the mistake and continue the process

All error messages should be highly visible, and remain so while the user corrects the mistake.


Using landmarks can help to organise the page and will enable screen readers to navigate the page more efficiently. 

Some available landmarks include <header>, <nav>, <footer>, <main> and <aside>. The <section> element will become a landmark if used together with aria-labelledby or aria-label. Make sure to read about each of the landmarks to see if they will be appropriate to use. 

If using multiple <nav> landmarks, each should be given an accessible name using aria-label or aria-labelledby. 

Screen readers

Screen readers enable people with visual impairments to use a computer. Many of the topics covered in this article will improve the experience for people using screen readers. However, it is important to test with an actual screen reader. 

Mac OSX has an integrated screen reader called VoiceOver. JAWS and NVDA (free) are the most used screen readers for Windows.

Automatic tests will only detect 20-30% of all accessibility errors, so it's important to also do manual tests 

Language defined in the code

Relevant language codes for Gjensidige

  • English: en
  • Norwegian bokmål: nb
  • Norwegian nynorsk: nn
  • Swedish: sv
  • Danish: da
  • Lithuanian: lt
  • Estonian: et
  • Latvian: lv

For users of screen readers, it is important that the correct language is defined in the code. Language codes consist of two letters, as given by the ISO 639-1 standard.

If a word or phrase of a different language is used within the text, it must be identified with the correct code for this particular word or phrase. This ensures correct pronunciation.