Accessibility guidelines

Visual identity ͏

Downloads and resources

#p10 #st1684229163534-2{ overflow-y: auto; }

height: 4px;

Accessibility guidelines

For developers

Our accessibility guidelines for digital formats cover topics like HTML5 landmarks, click and focus states, WAI/ARIA labels and keyboard navigation.

HTML5 landmarks

There are seven landmarks that should be considered if the site uses the HTML5 standard. If this is not possible, then the equivalent ARIA roles should be used. Read more about HTML5 landmarks and equivalent ARIA roles on the WCAG website.

WAI/ARIA labels

Use the correct WAI/ARIA labels (roles) to make content more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with HTML, JavaScript and related technologies. Without WAI-ARIA, certain functionalities used on websites are not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. Find more labels/roles guidelines on the WCAG website.

Add "skip to"

Add "skip to content/navigation" for repeating elements so the user doesn’t need to tab through every element on every single page. Read more about bypassing block on the WCAG website.

Keyboard navigation

Support keyboard navigation. This is a crucial part of web accessibility, because many users who are unable to use a mouse will depend on their keyboards to navigate your content. Those with motor or visual disabilities who rely on screen readers, as well as power users, will also expect your website to support keyboard navigation.

Ensure a logical tab order to support keyboard navigation.
Consider creating accelerators or keyboard shortcuts for your application. This can ensure that both newer and more advanced users (who might want faster ways to complete tasks) are accommodated.

Continue reading about keyboard accessibility guidelines on the WCAG website.

Correct mobile keyboard layout

Give users the right keyboard on mobile forms. Most mobile operating systems have designed separate keyboards optimized for specific form field inputs:

Email address fields
Web address fields
Number fields
Telephone fields

These optimized keyboards are there to use and will give the user a more pleasant experience.

Tab order (Focus order)

As a keyboard user navigates through the page, the order in which interactive items receive keyboard focus is important. The default keyboard navigation order must be logical and intuitive. This generally means that it follows the visual flow of the page—left to right, top to bottom. For most pages this means header first, then main navigation, then page navigation (if present) and finally the footer. This navigation order (and the reading order for screen readers) is determined by the web page's source code. For best results:

Structure your underlying source code so that the reading/navigation order is correct.
Then, if necessary, use CSS to control the visual presentation of the elements on your page.
Do not use tab index values of one or greater to change the default keyboard navigation order.

More information on focus order on the WCAG website.

Form fields

Provide labels to identify all form controls, including text fields, check boxes, radio buttons and drop-down menus. In most cases, this is done by using the "label" element. Labels need to describe the purpose of the form control.

A label and a form control should be associated with each other either implicitly or explicitly. Web browsers provide the label as a larger clickable area, for example, to select or activate the control. It also ensures that assistive technology can refer to the correct label when presenting a form control. Find more labels/roles guidelines on the WCAG website.

Click area

Click area is the clickable or tappable part of links and buttons on the websites. It is the area that changes the mouse icon or gets highlighted while hovering over a button or link. Providing an adequate size to these click areas is critical for easy use of any interface. The click areas should be designed to be functional, easy and accurate to make it easy for the user to click or tap them. In WCAG 2.1 the preferred size is a minimum of 44 px (AAA level) but we recommend a similar click area for our users. Read more about click area on the WCAG website.

Resize text

A user should be able to zoom in up to 200% without the assistance of a screen magnifier and without losing any content or functionality. The layout should remain intact, and there should not be any overlapping or strange-looking content as this could be confusing and difficult to read.

Checklist

A few simple things regarding UX and accessibility that you as a developer can take into account when writing code:

☑

Ensure all content is accessible via keyboard:

Keep in mind that some visitors are physically unable to use a mouse.

☑

Use WAI-ARIA for dynamic elements:

Any changes to content that occurs without the page reloading should be clearly communicated to users of assistive technology.

☑

Use structural and semantic HTML:

Let browsers know what kind of content is on the page and help users of screen readers who are unable to follow visual cues.

☑

Include a "Skip to Main Content / Skip to Menu" link:

This will help non-mouse users access your content quickly and easily.

☑

Design forms for accessibility:

Your forms should be effective, usable and logical. Clearly label fields to provide pertinent/instructions and identify any form entry errors, such as required fields being empty.

☑

Allow text resizing:

Ensure your visitors can increase and decrease text size without affecting the function or content of the page.

☑

Allow users to pinch and zoom:

Allow visitors to zoom in on images and/or photos so that they can view them comfortably.

You can find more learning opportunities on accessibility on our Hub page.