A truly clear accessibility checklist for development teams

Each type of content has a specific tag, so using the tag correctly makes the page understandable for screen readers, search engines, and other assistive technologies.

If you constantly use these tags instead of proper semantic tags, people who read from the screen may not understand what is important on the page and what is just decoration.

The user doesn’t need to use the mouse to get to any interactive element on the page, for example, a button, a link, or an input field. Tabbing should let them navigate through everything they can interact with.

When a user navigates a page using the Tab key, the focus should not jump around, but move from top to bottom in a logical order so the user can easily predict where they’ll land next.

The user needs a visual indicator to understand which element they are on and not to get lost on the page. A button or link can be visually highlighted, for example, by being framed.

If you go overboard with ARIA, screen readers can get confused, repeat information, or read out stuff that isn’t actually helpful.

Buttons, links, and other interactive elements on a page should have clear labels and roles. An aria-label is needed in case a button only has an icon. So the screen reader announces to the user what the button is. The role explains what kind of element it is and how to interact with it. And thanks to alt, the user understands what the image shows, even if they can’t see it.

A name, email, or password field must contain a label: a text that tells the user what to enter in that field.

If a user fills out the form and makes a mistake — for example, misses a required field or enters an incorrect format — the screen reader should immediately read them out loud.

If a user has filled a form incorrectly, such fields should be highlighted on the screen to show where the error is. For example, the field can be outlined in color, or a message with an explanation can be added.

The media doesn’t play automatically without control. Users can play, pause, or set the volume of video or audio via buttons or other controls.

Subtitles or alternative tracks with text or translation help people who cannot hear or understand the video/audio language.

Sound or video should not start automatically when the user opens a page. The user gets to decide when to play the media.

It’s important to comply with the requirements of the web accessibility standard WCAG 2.1 AA to help people with poor vision or on bright screens read text without effort.

For large text — typically 18 pixels and above or 14 pixels for bold — the contrast between text and background can be slightly lower than for regular text, but not less than 3:1, so that the text is still legible for people with poor vision or on bright screens.

Alternative methods to highlight an error are needed because people with impaired color perception may not notice the mistake they have made. It’s better to add an underline or an icon.

Fonts should scale through browser settings without losing the layout structure. If you use custom fonts, check their readability in real conditions — on a small screen or in bright light.

Verify that zooming does not cut off text or cause interface elements to overlap. Make sure that images and icons are scaled or remain readable without spoiling the design. Test on different browsers and devices, because the zoom behavior may differ.

Try to use column widths that naturally fit the text within these frames. On mobile devices, lines are usually shorter due to the small screen — make sure the text is still easy to read. Combine with sufficient line spacing and font size so that the eyes can easily “scan” the text.

Test interactive elements on mobile devices — small buttons are exceptionally inconvenient on a phone. The minimum size is 44×44 px; if possible, make elements slightly larger for even greater comfort. For elements with icons without text, add labels or alternative activation methods to make them easier to find and click.

If there are several buttons next to each other, leave space between them or use visual dividers so that it is clear where one ends and the other begins. 8–10 pixels is the minimum; if possible, give a little more space to make it more comfortable.

On small screens or for people with motor problems, small checkboxes and radio buttons can be difficult to hit. Add text labels, increase the clickable area, or offer another way to select to make it easier for users to interact.

Don’t let videos or animations start automatically. Instead, let the user decide when to turn them on. Add a clear “play” button or the ability to turn on animations at will. If there is sound, don’t turn it on automatically either, so as not to scare the user or disturb others.

Give the user the ability to turn off animation on the site entirely with a simple setting or button if they want. This is especially important for people who are sensitive to motion or get motion sickness from flashing and moving elements.

Static or gently moving elements are easy on the eyes, don’t steal attention, and don’t cause a problem for people with epilepsy. If flashing elements cannot be avoided, make them slow and subtle.

Avoid using flashing banners, animations, or buttons. Instead, replace them with static or smoothly animated elements. If flashing cannot be avoided, make it slow.

All pages should have the same elements and patterns so that the user does not waste time on retraining. Necessary actions should be located in plain sight; hiding them in unexpected places is confusing. It is very important to keep the navigation of menus, buttons, and links logical and straightforward so that users get to where they expect.

When a modal window is open, keep the focus inside it, so that the user can only work with what is there. After closing the modal, return users to the element from which they opened the window. This makes navigation predictable.

Users should immediately understand whether a button is enabled or disabled. If it is disabled, make sure it is clear to both the user and the screen reader. Use visual cues such as color, shadow, outline, or background changes on hover and focus.

Your checklist for this point should include the optimal size of buttons and controls, the right color and contrast of text for people with visual impairments, as well as hints, descriptions, and alternative ways to interact with the interface that people with cognitive disabilities will appreciate.

Older people find it difficult to learn new things, so the Silver Age generation needs not only optimally selected interface elements that will be convenient for them, but also intuitive navigation and detailed instructions.

A logical structure — the main heading <h1>, <h2> for the main sections, <h3> for the subsections — helps people who use screen readers to quickly “scan” the page and navigate the content. The mistake is to use headings just for style. They should really explain what comes next in the text.

Subheadings are like “road signs” on a page — they show users what’s next and where they are. This is especially important for screen readers: the reader can voice the structure, and the user understands which section comes after what.

It doesn’t matter who is viewing the page — a user or a screen reader. With the help of clear headings, they get simple navigation and can quickly find the necessary information. For example, it is better to replace the abstract heading “Information” with the clear “Shipping and payment”.

Every image on your site should have a text description (alt) that explains what it shows. This helps visually impaired people who use screen readers understand what is shown, even if they can’t see the picture. The alt should be specific and helpful, such as “dog playing with ball” instead of “image”.

If there is a decorative picture with clouds or a pattern in the background, it is also better to put alt="" so as not to distract the user. This helps people interact with the site faster and more comfortably, without all the “noise” being read out loud.

Text descriptions for infographics should convey the essence — the trend, key values, ​​and overall conclusion, in other words, making sense when users hear it, just like when users see it. If you write a description like: “The graph shows the growth of the number of users: in 2018 there were 5,000, in 2023 already 50,000, the growth is stable every year” — then the user with a screen reader can also understand the meaning.

Link and button texts should immediately say what will happen if you click on them. Just “Learn more” or “Click here” is not clear to many people, especially to people with visual impairments. Make link texts specific, for example, instead of “Learn more” it is better to say “Learn more about pricing”.

If you use a link https://example.com/pricing instead of descriptive text, for example, “View pricing”, then screen reader users will hear a set of letters and symbols and may not understand where the link leads. In general, it is easier for any user to click on a clear inscription, rather than a set of letters and numbers.

Extra “asides” and complex phrases overload sentences. Therefore, you need to act according to the principle “one sentence — one thought” and not use long or rare terms. It’s easy to check: if you are tired of reading the sentence, it is probably too complex for most users.

Users may not know the specific words, so it is a good idea to replace jargon with simple words or provide a short explanation of the term when it is needed.

Users need simple words instead of complex formulations and special terms. Instead of “fill out the form correctly,” it’s a good idea to write “enter your first and last name in the Name and Last Name fields”. The goal is to make the instructions clear for a person who is using the interface for the first time.

Captions and sounds should go hand in hand, neither ahead nor behind. If there’s applause or a siren, it should be reflected in the captions like [applause] or [siren].

People with hearing impairments often struggle to perceive the voice track of a podcast, and a text transcript is very helpful here. If time codes are added to the podcast, users can quickly jump to the desired moment.

Visual notifications, such as a flashing button or pop-up message, should be supported by text or audio. If the notification flashes or a colored indicator appears, you can add a text cue to ensure that listeners with visual or cognitive impairments do not miss important events.