Designing accessibly is an important step in making a web application accessible. However, learning accessibility and making design decisions is only part of the process. Providing developer artifacts, such as headings, tab order, and links guidelines, will help developers code accessibly.

Here are some high-level recommendations for various artifacts that I’ve put together based on my own learning and experience working with A11y:

Headings

A heading describes the content that follows it. For sighted users, this helps to quickly find what they want on the page. Screen readers and other assistive technology often have capability that allows users to skip from heading to heading.

It is best to plan out a heading structure before composing a page.

WAI-ARIA (Accessible Rich Internet Applications) Specifications Labels

According to Mozilla, ARIA is “a set of roles and attributes that define ways to make web content and web applications…more accessible to people with disabilities.” When designing labels, ask yourself:

• Type: What type of thing is this?
• Label: What is the name of this thing? How would you describe it succinctly to a user with visibility impairments?
• States and values: Does this thing have other properties that are critical to understand? This can help you decide whether to use native or custom components. (Note: If a native component exists, the recommendation is to use that instead of repurposing it as an ARIA component.)
  
  

Landmarks

ARIA ca­n defin­e roles when working with sig­nifican­t page areas or regio­ns. These are iden­tified by screen­ readers a­nd help with orientation and navigation in the page. There are eight lan­dmark roles, each represe­ntin­g a block of con­ten­t that commonly occurs on­ web pages. If a role is used more tha­n o­nce on­ a page, the aria-label attribute should also be used in­ order to disti­nguish between­ the two regio­ns.

Tab Order

[image source: BBC UK]

Focus (tab) order is the order of interactive elements users can access by selecting Tab or via screen readers. Non-interactive and visually hidden content should not be included in the focus order. If the reading order is illogical or unintuitive, the content will not make sense, or it will be difficult to navigate or understand.

Skip to Content Link

[image source: UX Movement]

For most pages, the main content rarely comes first in a layout. Providing a way to skip past all the features at the top of a web page helps save keystrokes for keyboard users. The Skip Navigation link allows screen reader users to directly access the main content of the page without repeatedly going through the navigation on each page.

Skip links are only visible on focus.

States

[source: Figma]

States communicate the status of UI elements to the user. Each state should be visually similar and not drastically alter a component, but must have clear affordances that distinguish it from other states and the surrounding layout. When multiple states occur at once, such as selection and hover, both state indicators should be displayed.

Links

[source: Figma] 

While screen readers can read a full page to a user, users may prefer to skip around or hear a list of links. In that case, a screen reader may only read the link text and not the surrounding text. The link text alone should convey the function and purpose of the link. Link text should also be unique and easy to speak out loud.

Ensure that interactive components have a minimal target area of 44px.

Non-text Alternatives

[source: Figma] 

Since blind users cannot see images and graphics, they depend on the alt-text to describe graphics to them. The alternative text must be meaningful and serve as an effective substitute for the image in a way that makes sense. If the information is purely decorative or redundant with text content on the page, make the alternative text value be empty (alt=””).

Keyboard Interactions

[source: Figma] 

People who do not use a mouse will most likely use a keyboard to access a website, instead. Making all functionality achievable using the keyboard allows for the use of a wide variety of assistive technologies and expands access to more user populations. (Keyboard shortcuts are enjoyed by disabled and abled users alike!) Provide keyboard alternatives in design and test them in the development process to ensure your site or app can function without a mouse.

For more component keyboard patterns see ARIA Authoring Practices

Designer-developer collaboration supports accessibility

Accessibility is a collaborative effort. By providing artifacts to developers, designers can help ease the path to A11y and reach the ultimate goal of opening access to a wider group of users.