Making a website accessible to all is an important practice to ensure we are being inclusive of all people, no matter their abilities or disabilities.
Some reasons for practicing web accessibility:
- In some countries it’s the law.
- You don’t want to exclude any potential customers/visitors from using your site.
- Accessible sites tend to rank higher on search engines.
- You are demonstrating good ethics—something that customers will value.
- Once you build web sites with web standards, it hardly requires any extra effort to make it accessible.
These best practices are based off the Web Content Accessibility Guidelines (WCAG) 2.1 level AA by the World Wide Web Consortium (W3C). More detailed information for each best practice can be found in the linked WCAG pages in each of the best practices below.
Accessible Rich Internet Applications
Accessible Rich Internet Applications (ARIA) help make the web even more accessible than with just plain HTML by providing additional information for assistive technology to interpret, such as screen readers translating a web page’s code into understandable content. These can be additional descriptions, semantic relationships between elements, or status of dynamic content. For example, a screen reader does not know if a slider on a page has been expanded. With some ARIA attributes added, then the screen reader can interpret whether the user has opened or closed a slider. It is worth noting that ARIA attributes do not augment any of an element's behaviour, it is only used to communicate with assistive technology.
Use of Colour: Colour should not be the only way of conveying information.
Text Contrast: Text and background color should have a contrast ratio of at least 4.5:1.
Non-text Contrast: Colours adjacent to each other in UI components should have a contrast ratio of at least 3:1.
Alt Attribute: Images should have an alt attribute to describe what they are.
Image of Text: Images of text should not be used.
Structure and Semantics
Heading Levels: Heading levels should be in a meaningful order.
Correct Elements: Correct HTML elements should be used whenever possible.
Code Errors: There should be no major code errors.
Keyboard Accessibility: All functions should be operable by keyboard.
Keyboard Trap: Keyboard focus should not get stuck within sections of a page.
Focus Order: Keyboard focus order should be logical.
Focus Visible: There should be a clear keyboard focus indicator.
Form Labels: Input fields should have labels with corresponding names.
Autocomplete Attributes: Input fields should have valid autocomplete attributes.
Form Errors: There should be error identification and suggestion for the fix when there are errors.
Page Title: Page titles should describe topic or purpose.
Status Message: There should be a status message when a page dynamically changes.
Display Orientation: Display orientation should not restrict view of content.
Two Dimensions Scrolling: Content should not require scrolling in two dimensions.
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.
Descriptive, specific, and succinct alt text: 5 story building 3D model
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.
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'>
Text in the image is unknown to users who cannot view it
Structure and Semantics
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
Heading level is not being skipped and the size is styled with
<h1>This is a heading</h1> <h2 class='u-f-h4'>This is a smaller heading</h2>
Heading level is skipped from h1 to h4
<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.
Elements are semantically laid out
<p>I’m a paragraph</p> <ul> <li>I’m a listed item</li> </ul>
p not allowed as child of element
<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
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.
For things such as modal dialogs, incorporate a close button as well as a way to close the dialog with the ‘esc’ key. That way keyboard users will be able to close it.
If a modal dialog has no exit buttons and only relies on clicking outside of the modal dialog to close, keyboard users won’t be able to close it and will be trapped inside the modal dialog.
Focus Order (WCAG: 2.4.3)
Having the focus order at the top of the page and working its way down would be the best practice.
The focus order would be incorrect if the tab focus of a page all of a sudden jumps to somewhere in the middle of the page right from the beginning.
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.
Implicitly associate label with input
<label> First Name: <input type='text' name='fname'> <label>
Even better: Explicitly associate label with input
<label for='name'>First Name:<label> <input type='text' name='fname' id='fname'>
Label not being associated with input
<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.
autocomplete='name' helps the browser fill name in the field
<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.
Title describes that the page is about us:
About Us | Safe Software
Title does not describe what information is on the page, if it is the about page:
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.
Notify screen reader users that the state of a page has been changed.
For example, the FME Form Pricing page has a status only visible to screen readers
When there is no status that something has changed, screenreader users will not know.
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.
The orientation of the page is rotatable between portrait and landscape.
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.
Take for example of a page with paragraphs and images. Assuming that the images can be reflowed without losing meaning, the paragraphs and images should break into the next row when needed to avoid two scrolling in two dimensions.
On the other hand, form fields shouldn't overflow when it doesn't fit a page. It should reflow into the next row.
Taking the example with the form, it would be bad practice if the fields are overflowing and causing the page to have scrolling in two dimensions.