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 the title attribute of the abbr element, only the child text. The tooltip generated by the title 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.

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;

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'>

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

• Make sure that the placeholder attribute isn’t used in place of the label 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 in legend. It's important for input type="radio" and input 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.

ARIA roles ​

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 in order 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 or Submit).
• 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:

• The W3C Web Accessibility Initiative Images Tutorial
• The W3C Web Accessibility Initiative alt Decision Tree