Intro
Conduct the following tests with the latest version of browsers and units
Automatic test
You can perform automatic web site tests that will catch basic errors such missing alt-tags and contrast issues. Be aware though that these tests catch only about 30% of errors.
For example:
https://wave.webaim.org
Test all the way from the main page to the listed destination.
Navigate through the site or service using the TAB, SPACE, UP, DOWN, ENTER keys. Make sure all important links and elements can be reached and that the user can use the options presented to them. Also check the following:
Think about how you can arrange content in a meaningful order, so that the user can easily follow the flow through the information. Avoid filling all available space. Unused space (white space) is important in order to not overwhelm the user with visuals and letting the eyes rest.
Make sure there is a clear hierarchy and that elements do not compete for attention. By doing so, you help the user to be naturally drawn to important information and interactions.
Some users memorize the structure in order to understand the content and how the site functions. When content and functions are not consistent it can be difficult for the user to interpret the content and navigate the site. Therefore, follow a common site structure for all pages. Not all pages need to look exactly the same but they should follow the same general structure.
Functions should be performed the same way regardless of where on the website the user is located. The same rule of consistency applies to names and appearance of functions. For example, a button called “approve” should not be called “OK” on a different page. A “save” icon should have the same appearance everywhere.
Not all people have the ability or possibility to rotate the screen. Some have to choose between portrait or landscape and stick with it, for example when the screen is mounted on a wheelchair. Therefore, design content and functions that are accessible regardless of screen orientation. The user should be able to choose orientation after personal preference.
Hiding important information in PDFs decreases searchability and makes it harder for the user to get an overview of the content. Find a balance between presenting information on the web versus keeping it in downloadable documents.
As much as possible, critical information should be available on the web. Make sure to divide the content into relevant pages so you avoid walls of texts.
A screen or a window should be able to present a page at 320 pixels width without side-scrolling.
Not all people are able or willing to call a company for help. Some may have trouble communicating in writing. Reasons for this can range from a physical or cognitive disability to simply being unfamiliar with the language. Give people the option to choose a method they are comfortable with. Avoid only having a phone number. Always provide a phone number and an email address whenever possible.
In some cases you may only be able to provide one option. In that case, think about how you can reduce the need for contact. One solution could be answering the most common questions in a “frequently asked questions” section.
Contrast varies depending on the size of text and icons. Create designs the user can zoom in on, in order to see better. Components and text should pass a contrast ratio of 5:1 and you can test this with automatic tests. Yes, the WCAG 2.1 recommendation is a ratio of minimum of 4.5:1, but we’ve rounded it up. It’s easier to remember and gives us a little extra margin.
You can check contrast on a page here: Contrast Checker
Try passing the contrast level by a good margin. The components in our library should follow these recommendations. If you find a component that isn’t up to standard, contact us.
There are cases where a component could have a contrast above 5:1 but still be illegible or difficult to interpret. Therefore don’t assume automatic tests are 100% correct, use your own judgement.
Colors are great for improving usability and aesthetics. Be aware though that using strong colors too frequently can steal focus from the most important information and interactions. Use our red color (#E30613) sparingly, for example when you need a “call-to-action” button.
Content that appears when the user focuses on it with the keyboard or mouse should be accessible and controllable for all users. This includes users that zoom in on a page or take their time to get to the content. It is especially important that users are able to close or remove the pop-up content.
Examples of such content can be sub-menus, tool-tips or non-modal pop-ups.
Support the user in searching on our website by proactively providing search word suggestions. This results in better search hits and makes it easier for users with writing or typing difficulties. It also saves time and simplifies the process for all other users.
For performance and efficiency reasons, wait until the user enters two characters in the search field before presenting suggestions.
You should generally avoid placing text in images as screen readers cannot read text on images. If you do have text in an image and the text is highly relevant to the user, make sure the text is included in the alt-text.
Images included in the design for more than just decoration (graphs or diagrams) need to have an alternative-text. The user should be able to understand what the image conveys even if the image is not visible because of a bad connection, the image link is broken or the user is using a screen reader. One good way of doing this is describing the image the same way you would do it in a phone conversation.
If a CMS system is being used, make it easier for the editors by making the alt-text field mandatory.
Decorative images don’t need an alternative text because they don’t communicate important information to the user. However, an empty alt-tag is still needed in order for the page to validate.
If the image or icon is linked, add a description of the destination as an alt-text. The description should be short and clearly communicate where the user will be taken.
People prefer to navigate the web differently, based on personal preference, physical or mental abilities. Therefore, we offer several ways to navigate our website.
Consider user needs and the complexity of the site when designing ways to navigate.
Possible functions could be a search function, main menu, in-page navigation, support for tab navigation or traversing through links.
Focus on helping the user to their goal. For example, when a user uses the search bar, help the user get to the results quicker by skipping the menu.
Some navigation aids use only links or headlines to navigate.
Make sure components in the interface and infographics have sufficient contrast. Use good contrast for informative parts of illustrations and other graphic content, as long as it’s possible.
The contrast ratio for components and graphics should be at least 3:1.
Check contrast here: Contrast Checker
Users that navigate with the tab-key need to clearly see which element is in focus by seeing a surrounding border. The standard border is often a thin, dashed line that can be difficult to discern, especially if the surroundings are busy or the contrast between elements is low.
Make the border clearly visible by using a CSS-rule.
To the extent it is possible, make interactions predictable and avoid introducing new fields or interactions when the user focuses or interacts with an element.
You can also prepare the user for the change by using copy or icons. For example, a link to an external site should have an icon that signals that the site will be opened in a new tab.
Sometimes you may need to include a sudden change in focus. An example of this could be when a user answers a question in a form, and you need a contextual, follow-up question to
appear. In that case, make sure the user takes notice of the change by having the new question appear in close proximity and directly after the previous question.
Swiping and gestures that require use of multiple fingers (such as pinching) can be difficult to perform for people with reduced motor or cognitive function. Some users may also be unable to perform them because of the navigation aids they’re using or simply because the interactions aren’t immediately obvious. Avoid therefore having complex gestures as the primary or most discoverable way to perform crucial tasks. This includes tasks like paying bills, transferring money or cancelling a debit card. They should be doable with simpler, easy to discover interactions, such as single tap, double tap or press.
Tables can be tricky to read, especially for users with screen readers. Let the html-code define the different parts of a table and how they are connected. For example, use th-elements to define which cells are rows and which are columns.
The attribute “scope” on a th-element creates a connection between header cells and data cells.This enables the screen reader to read the associated header before the content in a data cell. Doing so relieves the user from having to remember the table structure. This is especially important for tables with many columns or with several header levels.
When icons are used to represent buttons, they should be accompanied by explanatory text. The exceptions to the rule are icons of the universal kind, (think “go back” arrow).
Copy should be written in a simple, short and clear manner. All users should be able to understand it, so make sure to check the readability of the text. Complement the text with appropriate images.
You can also create checklists, bullet points or tables to break up and organize the text.
Use quotes and subheaders to keep the user interested.
Things to avoid:
To increase readability, body text should always be left-aligned. Avoid hyphenating words, except for extremely long words that may cause awkward line breaks. The exception to the rule is of course languages where the reading order is the right to left.
Left-align also the text in main menus and other vertical menus. It will make it easier for the user to browse the menu items, since the user’s eyes can wander along the left edge of the menu.
Avoid capitalized headlines. If you have to use them, use them maximum of one or two words. All capitalized headlines and texts decrease readability because we are not used to them. The exception being when caps are used for special purposes such as warning text like “THIN ICE” or acronyms like “CIO” or “EU”.
Headlines communicate how the content is structured on the page. Browsers, plug-ins and navigation aids use them to navigate through the content. Structure headlines according to their level in the hierarchy. The most important headline is H1 and the least important is H6. Jumping over levels can be confusing for some navigation aids, so make sure an H1 is followed by and H2. You can jump over levels if the page is divided into sections (see following example).
(missing image)
Screen reader users may have trouble following directions such as “click on the button to the right”. In addition, rotating the screen can alter the layout of the page so the spatial directions become incorrect.
Color blind users may have trouble telling the difference between red and green or green and blue. Avoid therefore referring to elements on page by color.
In order to add emphasis to tagline, you can highlight a specific word in an H1 headline with the color red (#E30613). Highlight the word that is most meaningful to the user.
You can also highlight keywords in body text by making it bolder but keep the color the same as the rest of the text. Avoid italicizing text.
Do not underline text that isn’t linked. The user may mistake the text for a link.
Users with dyslexia or of limited vision need to be able to adjust the spacing between paragraphs, rows, words and characters for readability. Make it possible for the user to adjust spacing without content or functionality clashing or hiding behind other content.
The user, at minimum, should be able to increase distance at the following relative thresholds:
Many people with limited vision need to enlarge the text in order to read it. Make it possible
to enlarge text to at least double the height and width without hiding text behind images or clashing with other texts.
Some best practices to keep in mind:
Make sure documents have file names that clearly describe the content. Don’t use internal working titles as file names. You should generally avoid naming documents after article numbers, registration numbers, form numbers or other numbers of that nature. Only if the article number or form number is known by the users, should it be part of the file name.
When creating accessible PDF:s, do the accessibility adjustments in the original document (perhaps in Microsoft Word or Adobe InDesign). Otherwise you’ll have to adjust the settings in Acrobat Professional, which may not be accessible to you. Here are some basic guidelines:
<h1>, <h2>, tables <table>, table headlines <th>, columns <colgroup>, bullet point lists <l> and table of contents <toc>.Use only active, clickable buttons and support the user with error messages that clarify what the user needs to do. Make sure the user doesn’t miss required input fields by automatically scrolling up to the top input field that needs to be corrected.
In an absolute majority of cases, avoid using greyed-out, unclickable buttons because they make it difficult to explain to the user why they aren’t available.
An exception when a disabled button can be used is during the choice of payment methods in our purchase flows. In this example, the option “Månad” is clickable when the customer chooses “Autogiro”, but not when “Faktura” is chosen.
{missing image}
Place buttons in close proximity to their context, so that the user understands the relationship between the information and the buttons.
The users should be easily able to distinguish between regular text and linked text. Make sure linked text visually stands out from regular text by using underscores, placement, color or size. Active links can be made to stand out by, for example, changing background color. Avoid only using color to distinguish a link from the rest of the text. Users with colour blindness will have trouble seeing the difference.
When using “Show more” links or buttons, make sure to describe the hidden content in the name. For example: “Show more funds”. It makes it easier for users with screen readers to get an idea of the content before they interact with the link or button.
Don’t use the url of the page as a link name.
Feel free to use colors, but make sure color is not the only way to distinguish objects or pieces of information from each other. Combine color with text, patterns or other visual indicators. Also, check out how we use universal icons like the “x” for close and the “i” for information.
Avoid making link and button texts too long. Buttons should contain no more than 2-3 words. We have a two-row button that can be used if necessary, but first, try shortening the text.
Link text should be a maximum of 100 characters long, while clearly telling the user of the link content. For example: ”How to renovate your bathroom with the right waterproofing” (58 characters).
All of our users need to easily understand what elements are clickable. Make sure that links have a consistent appearance across the entire web site.
Things to keep in mind:
When users use voice control to operate a button, they usually read out loud the text on the button. Make sure the text on buttons and other UI elements matches the corresponding machine-readable tags used by voice control. This makes for a smoother experience for voice control users.
Occasionally, all of us accidentally press a button we did not intend. People with limited motoric function or impaired vision are especially affected by this. The option to reverse an action is very important because it makes the user feel more secure interacting with a service. The user can confidently take action without fearing doing something that can't be easily reversed.
When the user interacts with a button that reveals a new, contextual interaction, place the new
interaction below or next to the previous interaction. The new interaction should directly follow the previous one in the tab order.
Every input field should have a label. Labels are usually placed above the input field, where the user can easily see them. If the design does not have a label, the developer should add a hidden label that can be read by a screen reader.
Avoid making the solution dependent on title-attribute and placeholder texts.
Field label copy should be kept short, preferably not longer than two rows. If you need extra space for more detailed instructions you can add them at the beginning of the form.
When the user doesn’t fill out input fields in the way we expect them to, or forgets to do it, we should guide them with simply worded, positive and constructive messages. The focus should be on helping the user move forward rather than telling them what they did wrong.
Example 1:
The user types only 9 digits in the personal number field. Validate the field with “Personal number should contain 10 or 12 digits.” rather than “Incorrect personal number”.
Example 2:
The user forgets to fill out a personal number. Validate the field with “Please enter your personal number” instead of “This field is mandatory”.
**\
Make it easier on the user to by making sure clickable areas around objects like checkboxes or radio buttons are sufficiently large. The user should be able to click the area around small objects like checkboxes and not only on the function itself. In the case of radio buttons or checkboxes, you can also make the corresponding text clickable. By doing so, we don’t require fine motor skills unnecessarily from our users. On mobile, an average area for the index finger should be 44x44 pixels.
Transactions of legal, economical or health-related nature may have large and troublesome consequences for all involved parties. Therefore, help the user avoid making or correcting potential mistakes.
Avoid creating interactions that don’t allow the user regret, correct or confirm. When the user enters larger amounts of information (think forms), give the user an opportunity to preview the entered information.
Make sure field labels and supporting copy are closer to the field they belong to, than other input fields or text.
When we know that there are several ways of writing the same thing, accommodate the users by allowing multiple formats. For example, a personal number could be written with 10 or 12 digits, with or without a dash. Do the same with calendar dates in date pickers, to the extent it is possible.
The user should be able to navigate via all interactive elements on a page, from top down and left to right (for Swedish and English web pages). It is crucial that the focus path is logical in relation to how content is presented on a screen or to a screen reader. When the focus shifts to an unexpected element it can confuse the user and make them more prone to errors. Avoid using tabindex greater than “1” in the code.
Help the user fill out input fields by defining expected input in the code. This enables browsers or navigation aids automatically suggest input based on examples from other fields with the same definition (for example a street address and zip code). The code can also help by presenting the input field in a manner the user recognises.
Tagging input fields helps all users, but especially people with cognitive/motoric disabilities or people not familiar with the language. Adding the attribute “autocomplete” on input fields adds another layer of accessibility.
Complement text with video or animated material for those that have trouble reading text. Don’t forget to use sound for people with visual impairments.
In general, we avoid automatically playing sound or video.
There should always be ways to pause a video or control its volume. A user that navigates with a screen reader may not hear the content if other sounds are being played simultaneously. Users with a lower ability to focus or filter external stimuli may find it hard to use a service if they cannot turn off the sound easily.
Before you create an animation, you should define a purpose for it. For example, the animation will guide the user, direct their attention to a piece of information or provide feedback. Animations can also be used to add visual flair to a design. Generally, the animations should be kept short and non-looping. Users with ADHD may find looping animations to be confusing and distracting. Since animations should not be looping, they also should not be critical to functionality.
There are many reasons why people use subtitles when consuming video content. It ranges from a hearing disability, noisy environment or the need to watch without disturbing others. Users for whom Swedish isn't their first language sometimes use subtitles as support.
Structure is everything when you present content to users with navigational aids. Valid and semantic HTML makes the structure of the content presentable in a meaningful way. CSS, written for accessibility makes the web site easier to consume for all users. Correctly written CSS can also be used to provide extra information that isn’t visible to screen readers.
from design - use external style sheets to control presentation and layout.
For users navigating with a screen reader, tabbing, or other aids it may take a while to get through a menu. In addition, when content is repeated on several pages it adds additional mental strain on the user. Physical pain can become an issue if the same movement needs to be repeated over and over. Therefore, you should always offer the option to skip repeating content.
The backward-button should always work and let the user return to a previous page. In some cases, when a user is in the process of making a purchase, you may need to inform the user that they’ll lose progress if they go backwards. This is OK, as long as the user understands the consequences. If you’re creating an SPA-app this has to be resolved programmatically.
Shortcuts can make navigating through a website faster but they should be used with care.
There is a risk that the websites’ short cuts could be confused with the shortcuts of the browser, operative system or navigation aid. In addition, short cuts that consist of only one key press can cause problems for users with limited motoric skills or users using voice navigation.
There are several aids that can make it easier for developers to follow standards.
Code validation
Validating the code helps you find errors that can be hard to discover on your own. It could ID’s with non-unique values, fields with missing labels or errors in the html code.
If you want to validate a local page, you can copy/paste the code or download a plugin for your browser.
The W3C Markup Validation Service
Validate accessibility
Chrome has a built-in validation for accessibility in its development tools. If you wish to go to a bit more detailed level, you can download a plugin called “Axe” for Chrome. You can use it straight from the developer tools menu.
A part of great usability is a page that loads quickly, minimising the wait times and avoiding shifting elements as the page loads. Users today expect a page to be loaded and ready for navigation within 3 seconds. Some images can be loaded afterwards, but in general it is difficult for the user to navigate a page if the content constantly shifts because of long loading times.
It’s especially difficult for visually impared users, as they may have a hard time noticing content that is still loading.
Research has shown that users lose concentration if they have to wait too long. Nielsen-Norman have documented the following consequences of web response times:
Test your page here:
Pagespeed insights:
Verify that all functionality works using a keyboard alone, since many aids in practice function like a keyboard. Users that only use a keyboard or aids that connect to keyboard shortcuts, are dependent on the system not requiring a mouse or a touch screen.
In order to facilitate correct hyphenation, automatic translation and increase the likelihood of screen readers presenting content correctly, define the language in the html code. This is done with lang-attribute and language code.
Make sure users with aids like screen readers and magnification software can be alerted to important messages even if they appear outside of where the user has focus. Define where important messages may appear by using role or aria-live attributes. The aids can then recognise them and present them to the user at an appropriate time.
iOS guidelines: Introduction - Accessibility - Human Interface Guidelines
Android app guidelines: Build more accessible apps