Annotating Designs for Headers, Lists, Regions, and Grouped Form Controls


One of the most common accessibility problems that comes up in website audits is the lack of clear and logical structure, as required by WCAG Success Criteria 1.3.1 Info and Relationships. This can require several annotated copies of your wireframes and mockups. Combining headers, lists, and regions into a single wireframe is useful because it presents lots of information without becoming too confusing. It also consolidates how things that are meant to be together are represented to all users as being together.

Use Standardized Annotations

While you can choose any style of annotations that you wish, it helps to standardize on a specific set in your designs. For instance, in the screenshot below, we have a wireframe with the regions identified with a dotted blue line and the type of region (e.g. search, navigation, and main) indicated in the colored box. Also, each heading is identified in a magenta circle with the heading level (e.g. H1, H2, etc) indicated in the circle. Lastly, we have identified lists in green boxes.

Wireframe showing headers, regions, and lists-- described in accompanying text

Of course, you can choose whatever color scheme you want as the colors are not really important– instead, it’s the structure conveyed in the text. Here, we have a banner section at the top of the page. The first item is a brand selector, which we marked as a navigation region. This makes sense because it’s intended for navigating the site. Inside of the navigation region, we indicated that the three brands form a list. This also makes sense because the user needs to know how many options are available and which one they are focusing on. Below the brand selector, we have the site logo, which we marked as an H1 header because this identifies the purpose of the page– it’s the page for Brand X. Next, we have another set of menus, which we put in a navigation pane. We’ve also identified the list of options as just that– a list. Next, we’ve identified the search tool as yet another region. That completes the banner section– below that is the main section. The first header we have here is the H2 header “Great Deals on Popular Items”. Obviously, these deals relate to the Brand X, so we made it subordinate to the Brand X H1 header. Below that, we have a carousel control. Again, because this presents a list of options, we identified this an a list on the wireframe. So in one set of wireframe annotations, we’ve captured a ton of accessibility information that will make a world of difference for users with disabilities.

Appropriate Types of Regions

While you don’t have to memorize the list of ARIA landmarks and HTML region elements, you should identify the purpose of each of your regions from the standard list of such regions based on ARIA and HTML. These purposes are:

  • Main
  • Search
  • Navigation
  • Form
  • Banner (aka “Header”)
  • Complementary (aka “Aside”)
  • Footer (aka “ContentInfo”)
  • Region (an all-purpose region in a page)

Within a Form region, you can also add another region called Group, which we will get to next.

Handling Lists

Our wireframe example above illustrates the importance of lists. Typically, when we visually think of lists, they are either unordered lists (e.g. bullet lists, where order is not important, such as a grocery list), ordered lists (e.g. lists with numbered items, where order is important, such as a recipe), and definition lists (e.g. a list of terms and associated definitions).

When a visual user encounters series of menu options, they also view the series of options as a list (at least subconsciously). Anytime items are arranged in some kind of order– either in parallel or serially– we need to remember that this is a variant of a list structure.

In addition to identifying the elements that can form lists, it’s also important to make sure that the lists are represented as a single list. For instance, in the list above, you may want to increase the spacing between the lines. In this case, a developer may achieve this extra spacing by making each bulleted item into a separate bulleted list. While visually acceptable, this makes it impossible for screen reader users to understand that the different list items and which item in the list they are in.

As shown in the screenshot above, however, by enclosing all of the list options in a single box marked “list” in the annotation, this “single list” structure is made clear to the developer.

Grouping Form Elements

You should also use this same technique for grouping form elements. This comes most clearly in two situations.

In the first situation, we need to group radio buttons and checkboxes. Of course, radio buttons are usually mutually-exclusive, so only one radio button can be checked in a group of radio buttons. By contrast, checkboxes normally allow you to select any number of checkboxes from the group presented. In the screenshot below, we have a screenshot of the wireframe for our product details page. We’ve identified the label (“Size”) and the available product sizes as a group on our wireframe and we’ve given the group a name (also “Size”). This tells the user that the following grouping of five radio buttons are used to select a size.

Screenshot described in accompanying text.

Developers commonly do not group radio buttons– the mutually-exclusive nature is enforced just through the name attribute associated with the radio buttons. But this gives scant information to a screen reader about the purpose of the radio buttons. Ideally, there are one of two ways that they can code this sample. One is to encase the region in a heavily-stylized fieldset element using the caption “Size:”. A second way is to add the “role=radiogroup” attribute to the container (e.g. a <div> that contains the group of radio buttons and the title (“Size”).

The second situation involves other kinds of form elements– and while the strategy is exactly the same from a UX perspective, it changes a little bit on the developer end. In the screenshot below, we have the wireframes for the checkout section of an eCommerce site. In this case, we want to group “First Name”, “Last Name”, and “Address” in a group named “Shipping Address” as well as placing “Email” and “Telephone Number” in a “Contact Info”. This will let screen reader users know, for instance, which address (e.g. shipping versus billing) and which telephone number (e.g. work or home) makes the most sense to provide. And, to reinforce the principles we’ve already talked about, we have identified the other regions of “Form”, “Main” and “Banner” accordingly as well as identified the header structure on the page.

Screenshot described in accompanying text

Tips and Tricks

  • Don’t Clutter Your Page with Unnecessary Headings. You can definitely go overboard in trying to add structure in your headings. As shown in the example above, you’ll want to keep your headings simple enough that the structure doesn’t overwhelm the content and make things unnecessarily cluttered.
  • Follow Proper Heading Structure. Of course, you’ll want your headings to follow a proper numeric heading structure. For instance, don’t add an H3 heading immediately after an H1 unless you have an H2 between them. You should ideally start the page with an H1 or H2 heading. Plus, it’s also valid to have an H1 in the banner and header content and then start your main page inself with another H1 heading.


The Figma Community Page includes a number of great community resources that you can use in your designs. Just by searching for the term “accessibility” yields a ton of useful templates and icons that are free to use and easy to implement. For the regions and headings in this example, we used the Fluent Accessibility Notation design toolkit in the community page contributed by Microsoft.

Screenshot of Fluent Accessibility Notation title page in Figma Community Page