Skip to content


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.


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;
position: absolute;
top: auto;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
width: 1px;
height: 1px;
white-space: nowrap;


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.


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 roles
ARIA roleDescription
AlertA 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.
StatusAreas 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.
LogA 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.
MarqueeThis 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.
TimerThis 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 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.

To write effective alternative text and decide whether or not an image requires a text alternative, check out these resources:

Released under the MIT License.

Released under the MIT License.