Accessibility Guidelines

Use of Colour (WCAG: 1.4.1)

Colour must not be the only way of conveying information to help people with different kinds of colour blindness understand the intended message. Instead, use additional text or icons to convey the information.

Text Contrast (WCAG: 1.4.3)

The text and background color should have a contrast ratio of at least 4.5:1 to remain readable for people with low-vision or vision impairments, with the exception of:

• Large Text (24px or 19px bold) have a contrast ratio of at least 3:1
• Text that are inactive or pure decoration have no contrast requirement
• Text that is part of a logo has no contrast requirement

See the text colour combinations that we use.

Non-text Contrast (WCAG: 1.4.11)

The adjacent colours in UI components and graphical objects should have a contrast ratio of at least 3:1. Meeting this contrast ratio allows users with vision impairments to see these components and objects.

Alt Attribute (WCAG: 1.1.1)

Images should have an alt attribute to describe what they are. There are exceptions such as decorative images that do not add information to the content on the page or the information is communicated elsewhere on the page, which an empty alt="" attribute will be used instead. This allows screen readers to read the text in place of the image, and for browsers to display the text if the image cannot be rendered.

Do:

Descriptive, specific, and succinct alt text: 5 story building 3D model

Don't:

Alt text is not descriptive: Building

Image of Text (WCAG: 1.4.5)

Images of text should not be used as it is a problem to users who are not able to view the image. If you must use an image of text, write the text in the alt attribute.

Do:

Alt text explains the image of text

<img src='https://images.safe.com/photos/customers/testimonials/calimapnerd.jpg' 
alt='Dale Kunce tweet: I love one piece of proprietary 
software and it is SafeSoftware #FME'>

Don't:

Text in the image is unknown to users who cannot view it

<img src='https://images.safe.com/photos/customers/testimonials/calimapnerd.jpg'>

Heading Levels (WCAG: 1.3.2)

Avoid skipping heading levels as it can confuse users who navigate the page with assistive technology. Correct heading hierarchy ensures content is presented in a meaningful order. Use CSS to change the heading sizes instead of using the h tags.

<h1>This is a heading</h1>
<h2 class='u-f-h4'>This is a smaller heading</h2>

<h1>This is a heading</h1>
<h4>This is a smaller heading</h4>

Correct Elements (WCAG: 4.1.2)

Use the correct HTML for all structural elements as most modern browsers implement the accessibility features outlined in the specs for these elements. Incorrect use of elements may lead to assistive technology users not being able to access the element.

Code Errors (WCAG: 4.1.1)

Ensure that there are no major code errors, which includes making sure that elements have a start and end tags, nested according to their specifications, and that they do not contain duplicate attributes. Code errors may lead to compatibility issues with assistive technologies.

<p>I’m a paragraph</p>
<ul>
  <li>I’m a listed item</li>
</ul>

<ul>
  <p>I’m a paragraph</p>
  <li>I’m a listed item</li>
</ul>

Keyboard Accessibility (WCAG: 2.1.1)

Every interactable element on the website should be operable by using the keyboard to account for different ways of navigating due to physical limitations. Usually, this means making content and interactive elements tab-key accessible. If there is an element that cannot be tabbed with the keyboard, set an attribute for tabindex="0".

Keyboard Trap (WCAG: 2.1.2)

Keyboard focus should be able to get in and out of areas of a web page. If it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. This will prevent keyboard users from getting stuck on areas of a page when navigating with the keyboard.

Focus Order (WCAG: 2.4.3)

Make sure the focus order is logical and is not jumping all over the place for users who are navigating with a keyboard. The focus-state is generally accessed by tabbing to that element. A wrong focus order can be due to HTML structured in a way different from the visual presentation, or javascript interference.

Focus Visible (WCAG: 2.4.7)

Any keyboard operable user interface must have the keyboard focus indicator visible. For aesthetic reasons, sometimes the default focus state isn’t desirable; instead of removing it, consider designing a custom focus state. The indicator will allow the user to know where the focus is set on a page.

Form Labels (WCAG: 2.5.3)

Form fields should have a label element describing the expected user input. The label can be associated with the form control explicitly by having a for-attribute associated with the id, or implicitly, with the control nested in the label. Placeholder text is not a replacement for labels. A missing label or incorrect label may cause confusion for what goes inside a form field.

<label>
  First Name:
  <input type='text' name='fname'>
<label>

<label for='name'>First Name:<label>
<input type='text' name='fname' id='fname'>

<label>First Name:<label>
<input type='text' name='fname'>

Autocomplete Attributes (WCAG: 1.3.5)

Where applicable, input fields should have valid autocomplete attributes so it allows a more fine-grained definition or identification of purpose than the type attribute. A list of supported attribute values can be found on MDN Web Docs. This helps browsers and assistive technologies to have a better understanding of what goes into the fields.

<label for='name'>Name</label>
<input id='name' type='text' autocomplete='name'>

<label for='name'>Name</label>
<input id='name' type='text'>

Form Errors (WCAG: 3.3.1)

When an error occurs, clearly identify the error and suggest a fix for it. This will allow the user to be aware of the error and determine what they need to do to fix it.

Page Title (WCAG: 2.4.2)

Web pages should have titles that describe topic or purpose. It should allow the user to quickly and easily identify whether the information contained in the web page is relevant to their needs.

Status Message (WCAG: 4.1.3)

Provide status message through "aria roles" when something on the page dynamically changes. Common attributes are role="status" for a change in state, and role="alert" for something that conveys a suggestion, or a warning on the existence of an error.

Display Orientation (WCAG: 1.3.4)

Ensure that the page is able to be properly displayed in the orientation preferred by the user. Restricting the page to be only displayed in portrait or landscape creates problems to users who want to view it in the unsupported orientation.

Do:

The orientation of the page is rotatable between portrait and landscape.

Don't:

It is bad practice to restrict the page to be only viewed in one orientation.

Two Dimensions Scrolling (WCAG: 1.4.10)

For screen dimensions, 320 pixels and above in width, ensure that the page can be presented without loss of information or functionality, and without scrolling in both horizontal and vertical dimensions. Exceptions to these are content that cannot reflow without losing meaning. This includes images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.