- Semantic Structure
- Alternate Text
- Other accessibility consideration
Use Lighthouse to check your website's accessibility. You will see the same exact information in the Accessibility report.
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.
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.
[aria-*]attributes match their roles Each ARIA
rolesupports a specific subset of
aria-*attributes. Mismatching these invalidates the
aria-*attributes. Learn more
[aria-hidden="true"]is not present on the document
Assistive technologies, like screen readers, work inconsistently when
aria-hidden="true"is set on the document
inputelements 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.
menuitemelements 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 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.
HTML5 landmark elements are used to improve navigation
Landmark elements (
<nav>, etc.) are used to improve the keyboard navigation of the page for assistive technology.
The page contains a heading, skip link, or landmark region
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.
[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
0implies 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
- 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
<li>are contained within
<ol>parent elements Screen readers require list items (
<li>) to be contained within a parent
<ol>to be announced properly. Learn more. Learn more
<dl>'s contain only properly-ordered
<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 (
<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
- 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
<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 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.
- 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
Alternative text is a textual substitute for non-text content in web pages.
- 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.
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
[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
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
idto ensure that they're visible to assistive technologies. Learn more
<iframe>elements have a title Screen reader users rely on frame titles to describe the contents of frames. Learn more
<video>elements contain a
[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