Universal design for developers

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.

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 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.

Examples

• 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.

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

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.

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. 

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.

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.