# Reviewing a design for accessibility

DevFeed: [Reviewing a design for accessibility](<https://devfeed.tech/articles/reviewing-a-design-for-accessibility-9411.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/reviewing-a-design-for-accessibility/>)

Author: Steve Barnett

Published: 2021-08-14T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [Web Accessibility (a11y)](<https://devfeed.tech/topics/web-accessibility.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [HTML](<https://devfeed.tech/topics/html.md>), [Forms](<https://devfeed.tech/topics/forms.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [article](<https://devfeed.tech/tags/article.md>), [forms](<https://devfeed.tech/tags/forms.md>), [guide](<https://devfeed.tech/tags/guide.md>), [web-accessibility](<https://devfeed.tech/tags/web-accessibility.md>)

## AI overview

This article presents an early design-review approach for identifying and addressing accessibility issues before development begins. It recommends explicitly annotating semantics and accessibility requirements, then checking page titles, heading structure, image text alternatives, link and button names, standard controls, form-element names, grouped controls, and error messages.

## Source excerpt

I'm a big believer in shifting left: considering accessibility as early in the process as we can. One way we can do this is by reviewing designs for accessibility. This helps us catch anything we've missed before we start developing it. What to do: annotate By adding annotations about the semantics and accessibility of elements on a page we can remove barriers to access. The best way to do annotations might be sticky notes on a printout or adding comments on a Figma file, or something else. The important thing is that we want to be clear and explicit. Here are a handful of things that I've found give good value / effort balance when reviewing a design for accessibility. Things to check Page title Is the page title unique? Does it concisely describe the page content? Headings Are headings used to divide content up in a logical way? Are the levels shown, without skipping any? Text alternatives Do all images (including icons) have a text alternative (using the alt attribute)? You can see WebAIM's guide to alternative text for more about what this is, and what makes good alternative text. If the image is decorative, is it marked as such (using alt="")? Are we sure it's only decorative? Link and button text Does each link describe where we'll go when we follow it? Does each button describe what will happen when we use it? Where links or buttons have the same text repeated on a page, do they have a longer accessible name that is unique? For example: "View details of Quarter 1 review" instead of "View details". Standard controls Do form controls match standard ones (like selects, radio, and checkbox) where possible? If not, is it possible to use a standard control instead? Are standard controls being used to match the design intent? Names for form elements Do all form controls (one input plus one label) have a name? You can reference MDN's article on the <label> HTML element for an example of how the label and input elements work together with the id and for attributes to