Accessibility
Language attribute
The language attribute declaration in HTML allows screen readers to read the text on the page with the correct pronunciation.
Specify the language using the lang
attribute inside the element html lang="en"
.
Document structure
Use semantic headings and structure the page logically.
Element roles on the page
Most of the HTML elements already have default roles and don’t need a role attribute. That is, if you're using native HTML elements, you usually don't need to assign a specific role to them. Refer to the Document conformance requirements for use of ARIA attributes in HTML section of the ARIA specification for a full list of HTML elements and their implicit roles.
In case you are using a non-native element, be sure to assign a role
attribute to it, depending on its function in the interface, so screen readers can tell the user which part of the interface they are in.
Notes to consider:
- The area of the page that contains information about the site should be wrapped in the
header
tag. - Areas with links to different pages of the site, application screens or sections of the same document must be wrapped in the
nav
tag. - Use the
main
tag to wrap the main content of the document. This tag should only be used once per page. - Use the
article
tag for independent content items. Screen readers can follow these tags when navigating through sections. - Use the
aside
tag to wrap blocks visually separated from the main content but associated with it. - The area that contains information about the document (copyright, meta information, company information, etc.) must be wrapped in the
footer
tag. - For the main search block, use
form role="search"
. - When using the
abbr
tag, note that most screen readers don’t read thetitle
attribute of theabbr
element, only the child text. The tooltip generated by thetitle
attribute is also inaccessible from the keyboard, which could impact keyboard-only users. Thus, it's recommended to expand abbreviations as visible text on the page.
TIP
If there are multiple zones with role
equal to navigation
or complementary
on the same page, use the aria-label
attribute to describe their purpose in a text caption.
Section elements that have an accessible name have the region role by default (otherwise they have no default role). Refer to "Using the region role to identify a region of the page" technique for more details.
Note that there's no point adding aria-label
attributes to non-semantic elements (for example, span
).
Controls and inputs
Controls and inputs should support navigation using a keyboard, touch devices and voice assistants.
- Make sure that controls and inputs have a recognizable
focus
state. - Make sure that interactive elements are easy to recognize.
- Use "Skip to main content" links.
In the case when you need to create a visually hidden element that should be read only by screen reader, use the following CSS:
position: absolute;
top: auto;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
width: 1px;
height: 1px;
white-space: nowrap;
Forms
Make sure that your markup and keyboard focus order are consistent and logical.
- Bind
label
to all form controls (input, select and others). For example:
<label htmlFor='name'>Name:</label>
<input id='name' type='text'>
- Make sure that the
placeholder
attribute isn’t used in place of thelabel
tag. Refer to WHATWG to learn more. All form fields should have valid labels that don’t rely on placeholder text. In the case of a search field, a magnifying glass icon can serve the purpose of a visual label, as long as the search input still has a programmatic label that isn’t derived from placeholder text. - Groups of form elements (for example, checkboxes and radio buttons) must be combined by
fieldset
and described inlegend
. It's important forinput type="radio"
andinput type="checkbox"
. Fieldsets and legends can also be used to group sets of related inputs, and they should be used when there are multiple fields with the same label. For example, fields for a shipping address can be distinguished from fields for a billing address by grouping them in fieldsets with distinct labels.
Dynamic content (live regions)
When content on a webpage updates without needing to refresh the page, it's called dynamic content. This could be a region or a widget. If the change is simple and not interactive, it should be labeled as a live region using the aria-live
attribute.
Dynamic content usually includes:
- chats;
- progress bars and timers;
- news and weather widgets;
- various errors and notifications: new messages, likes, subscriptions;
- tickers (stock market information, exchange rates);
- sports stats;
- other similar elements.
Live regions need to exist in the DOM from the initial page load. And they shouldn't be overused. There shouldn't be too many live regions within a single page, and the content within a live region should be short. Live regions shouldn't be used for entire sections of content.
To mark an area that has dynamic content, use the ARIA attribute aria-live=""
with a special ARIA role, learn more about in the section below.
TIP
It's recommended being careful with using redundant attributes like role="alert"
with aria-live="assertive"
. These roles are very well supported without the redundant aria-live attributes, and in some cases using the redundant attributes may do more harm than good.
ARIA roles
ARIA role | Description |
---|---|
Alert | A type of interactive area that contains information that is important at a particular point in time. It can be an error message or a warning that appears on the screen after some user action or without the user's involvement (a server error, for example). For maximum compatibility, use role="alert" in conjunction with the aria-live="assertive" attribute. This will prompt the screen reader to announce the change immediately. |
Status | Areas with this role contain additional information that isn’t particularly important and describes the status of changes (for example, a status bar). It can be information about a successful or unsuccessful user action, an error, or that the user needs to wait for a process to complete. Role="status" has built-in behavior for the aria-live="polite" attribute, and it's recommended to use them together for maximum compatibility. |
Log | A type of interactive area that contains logs. For example, chat history, a list of errors, or similar information. Note that for logs, the order in which the information is presented is very important. It's recommended to use the role="log" role in combination with the aria-live="polite" attribute. |
Marquee | This type of area contains information that changes rapidly. This role is similar to log , but in this case, the order in which the information is updated doesn't matter. Good examples of where you can use role="marquee" are tickers and currency rates. It's recommended to use the role="marquee" role in combination with the aria-live="off" attribute. |
Timer | This role is needed for areas with counters that count down time in a normal and reverse order. The role="timer" element should have the aria-live="off" attribute for full compatibility with all devices and browsers. |
Non-text content (images, media)
General requirements
- Images should be described in text in such a way that screen reader can adequately describe the content of the picture. Use appropriate
alt
text. Alternative text can be as long as it needs to be to sufficiently describe the image, but it's recommended to keep it concise and not too long for better user experience. - Provide a text alternative to the audio content.
- Add names to all elements of controls and information entry (such as
Search
orSubmit
). - Synchronize subtitles with audio in videos content.
- When you have forms that include tests, provide a brief description at the start explaining the type of test and possible outcomes.
- Don't autoplay audio.
- Avoid pictures and icons in pseudo-elements.
Decorative elements
Elements that are purely decorative and don't have any meaning in the user interface - such as background images, icons, and dividers - don't require a text alternative.
To exclude specific images, leave their alt
attribute blank and screen readers will ignore them instead of trying to read the filename.
Complex images and visualization
Complex visualization presented in the form of charts, maps, and others formats, should include a textual representation of the data. This could be in separate paragraphs or tables that are easily accessible to all users, or in some cases, hidden from sighted users.
Useful links
To write effective alternative text and decide whether or not an image requires a text alternative, check out these resources: