Carlo Gino Catapang

Posted on Dec 27, 2021 • Edited on Jul 31, 2023 • Originally published at l.carlogino.com

Web Accessibility Cheat Sheet

#webdev #beginners #html #tutorial

Introduction
ARIA
Navigation
Semantic Structure
Visual
Language
Forms
Alternate Text
Other accessibility consideration

TL;DR

Use Lighthouse to check your website's accessibility. You will see the same exact information in the Accessibility report.

Introduction

Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.

You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.

To learn more, check this page where I copy pasted the content above.

ARIA (Accessible Rich Internet Applications)

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

It supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. For example, ARIA enables accessible navigation landmarks in HTML4, JavaScript widgets, form hints and error messages, live content updates, and more.

Warning: Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states. However, if you choose to use ARIA, you are responsible for mimicking (the equivalent) browser behavior in script.

Here are some accessibility guidelines related to ARIA:

[aria-*] attributes match their roles Each ARIA role supports a specific subset of aria-* attributes. Mismatching these invalidates the aria-* attributes. Learn more

[aria-hidden="true"] is not present on the document <body>
Assistive technologies, like screen readers, work inconsistently when aria-hidden="true" is set on the document <body>.
Learn more
button, link, and input elements have accessible names
When an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
Learn more

meter, progressbar, tooltip, treeitem, and menuitem elements have accessible names When an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn more

[aria-hidden="true"] elements do not contain focusable descendents Focusable descendents within an [aria-hidden="true"] element prevent those interactive elements from being available to users of assistive technologies like screen readers. Learn more

[role]s have all required [aria-*] attributes Some ARIA roles have required attributes that describe the state of the element to screen readers. Learn more

[role] values are valid ARIA roles must have valid values in order to perform their intended accessibility functions. Learn more

[aria-*] attributes have valid values Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values. Learn more

[aria-*] attributes are valid and not misspelled Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names. Learn more

Elements with an ARIA [role] that require children to contain a specific [role] have all required children. Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions. Learn more

[role]s are contained by their required parent element Some ARIA child roles must be contained by specific parent roles to properly perform their intended accessibility functions. Learn more

ARIA toggle fields have accessible names When a toggle field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn more

Custom controls have ARIA roles Custom interactive controls have appropriate ARIA roles. Learn more

ARIA IDs are unique The value of an ARIA ID must be unique to prevent other instances from being overlooked by assistive technologies. Learn more

Custom controls have associated labels Custom interactive controls have associated labels, provided by aria-label or aria-labelledby. Learn more

Navigation

Navigation is the way users find and traverse the different pages available on your site. For this reason, it is imperative that navigation is accessible. By their nature, links are tab-able and all keyboard users and screen readers will read them–so, if your navigation is coded with links, a screen reader should find them.

Here are some accessibility guidelines related to navigation:

HTML5 landmark elements are used to improve navigation
Landmark elements (<main>, <nav>, etc.) are used to improve the keyboard navigation of the page for assistive technology.
Learn more
The page contains a heading, skip link, or landmark region
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.
Learn more

[accesskey] values are unique Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more

Visual order on the page follows DOM order DOM order matches the visual order, improving navigation for assistive technology. Learn more

The page has a logical tab order Tabbing through the page follows the visual layout. Users cannot focus elements that are offscreen. Learn more

No element has a [tabindex] value greater than 0 A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies. Learn more

Interactive controls are keyboard focusable Custom interactive controls are keyboard focusable and display a focus indicator. Learn more

The user's focus is directed to new content added to the page If new content, such as a dialog, is added to the page, the user's focus is directed to it. Learn more

User focus is not accidentally trapped in a region A user can tab into and out of any control or region without accidentally trapping their focus. Learn more

Buttons have an accessible name When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers. Learn more

Semantic structure

Structural, semantic HTML is the key starting point toward good accessibility practices. When a screen reader, or any sort of assistive device scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader.

Here are some accessibility guidelines related to semantic structure:

Heading elements appear in a sequentially-descending order Properly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies. Learn more

Lists contain only <li> elements and script supporting elements (<script> and <template>) Screen readers have a specific way of announcing lists. Ensuring proper list structure aids screen reader output. Learn more

List items <li> are contained within <ul> or <ol> parent elements Screen readers require list items (<li>) to be contained within a parent <ul> or <ol> to be announced properly. Learn more. Learn more

<dl>'s contain only properly-ordered <dt> and <dd> groups, <script>, <template> or <div> elements. When definition lists are not properly marked up, screen readers may produce confusing or inaccurate output. Learn more

Definition list items are wrapped in <dl> elements Definition list items (<dt> and <dd>) must be wrapped in a parent <dl> element to ensure that screen readers can properly announce them. Learn more

Cells in a <table> element that use the [headers] attribute refer to table cells within the same table. Screen readers have features to make navigating tables easier. Ensuring <td> cells using the [headers] attribute only refer to other cells in the same table may improve the experience for screen reader users. Learn more

<th> elements and elements with [role="columnheader"/"rowheader"] have data cells they describe. Screen readers have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the experience for screen reader users. Learn more

Visual

Here are some accessibility guidelines related to visual consideration:

Background and foreground colors have a sufficient contrast ratio Low-contrast text is difficult or impossible for many users to read. Learn more

[user-scalable="no"] is not used in the <meta name="viewport"> element and the [maximum-scale] attribute is not less than 5. Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page. Learn more

Language

Here are some accessibility guidelines related to language:

<html> element has a valid value for its [lang] attribute Specifying a valid BCP 47 language helps screen readers announce text properly. Learn more

<html> element has a [lang] attribute If a page doesn't specify a lang attribute, a screen reader assumes that the page is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, then the screen reader might not announce the page's text correctly. Learn more

[lang] attributes have a valid value Specifying a valid BCP 47 language on elements helps ensure that text is pronounced correctly by a screen reader. Learn more

Forms

Forms are constantly being used to collect information from users: signing up for something, buying something, asking a question, or contacting someone. Since forms are so commonly used, it is imperative to make forms accessible for all users.

Here are some accessibility guidelines related to forms:

No form fields have multiple labels Form fields with multiple labels can be confusingly announced by assistive technologies like screen readers which use either the first, the last, or all of the labels. Learn more

Form elements have associated labels Labels ensure that form controls are announced properly by assistive technologies, like screen readers. Learn more

Alternate Text

Alternative text is a textual substitute for non-text content in web pages.

Alternative text serves several functions:

Screen readers announce alternative text in place of images, helping users with visual or certain cognitive disabilities perceive the content and function of the images.
If an image fails to load or the user has blocked images, the browser will present the alternative text visually in place of the image.
Search engines use alternative text and factor it into their assessment of the page purpose and content.

Here are some accessibility guidelines related to alternate text:

Image elements have [alt] attributes Informative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute. Learn more

<input type="image"> elements have [alt] text When an image is being used as an <input> button, providing alternative text can help screen reader users understand the purpose of the button. Learn more

<object> elements have [alt] text Screen readers cannot translate non-text content. Adding alt text to <object> elements helps screen readers convey meaning to users. Learn more

Links have a discernible name Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users. Learn more

Other accessibility considerations

Document has a <title> element The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search. Learn more

The document does not use <meta http-equiv="refresh"> Users do not expect a page to refresh automatically, and doing so will move focus back to the top of the page. This may create a frustrating or confusing experience. Learn more

[id] attributes on active, focusable elements are unique All focusable elements must have a unique id to ensure that they're visible to assistive technologies. Learn more

<frame> or <iframe> elements have a title Screen reader users rely on frame titles to describe the contents of frames. Learn more

<video> elements contain a <track> element with [kind="captions"] When a video provides a caption it is easier for deaf and hearing impaired users to access its information. Learn more

Interactive elements indicate their purpose and state Interactive elements, such as links and buttons, should indicate their state and be distinguishable from non-interactive elements. Learn more

Offscreen content is hidden from assistive technology Offscreen content is hidden with display: none or aria-hidden=true. Learn more

DEV Community