Expectations for wireframe accessibility annotations

On this page:

Overview

Accessibility annotations are notes on your wireframe that specifically address information and behavior related to accessibility, such as how interactive items should be announced by assistive technology, such as screen readers. Accessibility annotations help you communicate critical information to stakeholders and developers.

Without these annotations, a developer must make decisions about translating the design. Delays may arise as they may ask for clarification or make assumptions that aren't caught until quality assurance testing or after rollout. Annotations help a developer make the right decisions faster.

Project owners benefit from annotations too. Annotations show that research and accepted standards drove design decisions.

The type and number of annotations you use depends on the complexity of your design and whether you use Rivet. Many accessibility decisions have already been made for designers at IU who follow the IU Brand guidelines and the IU Web Style Guide and use Rivet or the IU Web Framework.

If you must use resources other than those listed above, or create custom components or complex pages, you will need to include more annotations, such as color contrast, language attributes, and so on.

The annotations described in this document are not an exhaustive list of all accessibility-related annotations that might be made. This is a list of common areas IU developers have identified as too frequently leaving them to do design work.

Skip links

Skip links are the first item a keyboard user should focus on when entering a web page. Skip links allow someone using a keyboard to skip repetitive content like navigation menus. Rivet layouts come with skip links built in.

Required annotations

  • If you use something other than Rivet, note which skip links are needed and indicate the target where the skip links should go.
  • At minimum, you should include a link to skip to the main content.

Landmark regions

Landmark regions identify meaningful sections of a web page. Most websites have:

  • A "banner" or "header" which includes the logo and name of the website
  • A "main" content landmark region
  • At least one "navigation" landmark region
  • At least one "aside" or "complementary information" landmark region with information such as related links, RSS feeds, or other content that is not part of the main focus of the page
  • A "footer" with information such as copyright and a link to the privacy and accessibility statements

Annotating the regions for a mobile app still applies, even though the concept of landmarks differs for native mobile apps. For example, the iOS "header" is not the same as an HTML "header" on the web.

Rivet comes with header, navigation, and footer components.

Required annotations

  • If you have more than one navigation component, indicate a unique accessible name for each to clarify what the navigation covers.
  • Example: The accessible name "main" on a "<nav>" element will convey "main navigation" to assistive technology.
  • If you have more than one complementary landmark region, indicate a unique accessible name for each to clarify what the region covers.
  • If you use something other than Rivet, you are responsible for identifying the banner, main, navigation, complementary, and footer landmark regions.

Heading levels and page title

The heading structure of a web page helps visitors understand the purpose and content. The heading structure needs to represent the fundamental organization of each region of a page. A clean hierarchy creates an outline of the content.

The page title appears in the browser tab. Every page must have a title that is unique within the site.

Required annotations

  • Indicate the level of each heading, starting with H1 for the primary (top-level) heading. You can mark the heading level next to each heading or include a text outline of the headings. A text outline is especially helpful for making sure the structure is hierarchical.
  • Indicate the page title for each page. Page titles should be unique within a site. They usually match or are similar to the top-level heading for the page and are the name that appears in the browser tab.
  • If you use something other than Rivet, include the full heading hierarchy with the design. Define both semantic and visual details, if the hierarchy has not previously been outlined.
  • Example: H1 {1.5em; bold; Benton}.

Alt text for images and icons

Alt text provides a description of an image or icon for people using assistive technology. It also appears in place of the image if the image fails to load.

Good alt text describes the purpose (for example, "Menu" for a hamburger menu icon) or the appearance of the image. The text alternative depends on the context. An image or icon may be meaningful or decorative.

Required annotations

  • For any images or icons in your design, indicate the text alternative.
  • For interactive icons, such as a magnifying glass search icon, indicate the text alternative.
  • For decorative icons, such as a pencil icon next to the text "edit", indicate that the icon should not be named.

Tab order, reflow and reading order

Tab order refers to the order in which your interactive elements receive keyboard focus. Identifying this order is essential, especially for complex, multi-column designs.

Reflow and reading order are related to responsive design. Content on a website or app may reflow when viewed on a smaller or larger screen or when the website is zoomed to make text easier to read. For example, content presented in two columns on a large screen may be presented in a single column on a small screen.

If there are any areas where the order in which the content should be read does not match the visual order, make sure to annotate the reading order. An example of this is an article date visually located above the article heading.

Required annotations

  • Indicate the tab order for all interactive items.
  • If you use something other than Rivet, you will also need to include designs for different screen sizes showing how content will reflow.

Interactive elements

Interactive elements (links, buttons, form fields, widgets) must convey four essential pieces of information: their name, role, value, and state.

The accessible name is used to identify an interactive element. In most cases, the name will be the visible label: the link or button text, the form field label.

Use visible text labels whenever possible. They are the most accessible for everyone.

Required annotations

  • Annotations are required if the accessible name is not the visible label.
  • If an interactive item is visually labeled only with an icon, indicate the text alternative for the icon. For example, you may label a magnifying glass as "Search" to indicate what it does.
  • If the visible text is not enough, indicate the name that should be announced. For example, annotate "Edit name" for a button to edit a name with visible text "Edit".
  • Describe the identity, operation, and state of each interactive component.
  • Include the text for any error messages. Good error messages are concise and informative, describing the error and how to correct it.
  • If you use something other than Rivet or design a custom component, include and identify the different states needed for each interactive element. For example, a button can be pressed or not pressed, a checkbox can be checked or unchecked. A form element may be inactive. A form field may have an error.
  • If you use something other than Rivet or design a custom component, include annotations on both the visual and functional design for handling errors.
  • If you use something other than Rivet or design a custom component, include focus and hover states to show how different interactive elements will look when they receive focus or the mouse hovers over them.

Interactions and user paths

Interactions or expected user paths on web or mobile apps and complex websites or forms may not be clear from just the visual design.

Describing the expected paths and interactions will help other stakeholders understand the design. Once the design is approved, the descriptions help the developer build it as intended. The description should consider the various ways someone may interact with the page, for example, with a mouse, touch, keyboard, or their voice.

Required annotations

  • Include a brief text description of how to use the page or widget.
  • Describe the purpose, what actions can be taken, and how particular components should work.

Depending on the complexity of the design, the description can be simple ("This screen allows the user to check their account balances.") or detailed ("The user can select different criteria for their search. Depending on the selected criteria, they...").

Additional resources

The following resources provide further information and examples on how to make accessibility annotations on your wireframes.

Plugins and tools

Related documents

Accessibility for designers

This is document bhpk in the Knowledge Base.
Last modified on 2023-05-15 13:40:38.