Get started with accessibility annotations

Accessibility is often left out of the design process, so developers have to make their best guess based on how they understand the designs. Indeed, accessibility has been historically considered as a developer or QA’s responsibility, when considered at all. Yet this is slowly changing, thanks to concept such as “Shift Left” applied to accessibility testing, which postulates that the earlier accessibility is taken into account, the less expensive it is to fix it.

But there is still a lot of work to be done in order to bridge the knowledge gap of designers when it comes to accessibility. Unlike developers, very little tools have been created to help them take accessibility into account during their workflow. Particularly when it comes to people relying on assistive technologies, many designers are uncertain what they should do to ensure the usability of their product for these user groups as well.

It is in this context that Include — Accessibility Annotations from Ebay has been released a few months ago. This open-source and free Figma plugin allows designers to annotate their design in a semi-guided way.

ℹ️ This post is not sponsored by Ebay. I found the tool by chance as I was looking for a quick way to annotate designs. I was so pleased by the functionalities of the tool that I decided to use it for this article. That’s it.

What can this plugin do?

Once designs are ready for development, the Include — Accessibility Annotations plugin can be used to guide you in the documentation process of your designs for web or mobile-based projects. The annotations you add will provide valuable information on how the experience should be like, especially for people relying on assistive technologies such as screen readers.

In the following paragraphs, I detail what you can specifically document for screen reader users with this tool and why it is important. Images I use as examples come from the website Peerback, a Futurice internal tool to praise colleagues. It has been developed primarily by Denis Washington followed by Theresa Glanzberg, Thuy Duong Nguyen and myself.

Landmarks

Landmarks are areas of a webpage that have a distinctive role. They enable screen reader users to understand the structure of the page but also to jump from one section to another very quickly. This video from MSFTEnable explains really well how it works.

Landmarks can be specified preferably in HTML or using ARIA. As of today, the plugin lets you define 8 different types of landmarks:

• <header> or role=”banner” which generally highlights the beginning of a page and contains a logo and a main navigation. Note that there can only be one header per page.
• <footer> or role=”contentinfo” which generally signals the end of the page and contains copyrights, sitemap, privacy statement, etc. Note that there can only be one footer per page.
• <main> or role=”main” which contains the most important section of a page. Note that there can only be one main per page.
• <aside> or role=”complementary” which covers non-necessary or less important parts of the page compared to the <main>. If you have multiple aside sections on a page, they must have distinctive labels. You can specify distinctive labels with the plugin.
• <nav> or role=”navigation" encompasses menus and lists of links. If you have multiple navigation areas per page, they must have distinctive labels, unless they serve the same purpose.
• <search> or role=”search” identifies the search functionality on a page. If you have multiple search areas per page, they must have distinctive labels, unless they serve the same purpose.
• <form> or role=”form” indicates a group of questions that a user can or must answer. Each form on a page should have a unique label, describing the purpose of the form.
• <section> or role=”region” is a generic landmark one can use to label a section of a page that would be specifically important to your users. As it is a best practice to keep the page structure simple, I avoid using regions.

Example: For Peerback’s home page, I used the plugin to document the banner including its 2 navigations, the main area and the search bar.

For more advice on landmarks, I recommend reading the MDN documentation.

Headings

When encountering a webpage, screen reader users often go through the list of headings to understand its structure. Akin to landmarks, a logical heading order is key to create a mental model of a page and helps screen reader users to easily jump between sections.

In HTML, headings are ordered from <h1> (the most important) to <h6> (the least important). It is considered best practice to have only one h1 per page (but you can have as many h2, h3, etc… as you need).

Example: For the Praise Wall page which contains collections of praise, I specified 3 levels of headings: a H1 for the title of the main section, a H2 for a sub-section of the page and H3 for each list item titles.

Note: “Admin settings” in the navigation could be implemented as a heading. If this decision were to be made, it might make sense to add an invisible heading as well for the main navigation. This specific point could be a great topic to test with users.

Reading & focus order

When using the keyboard to browse a website, interactive elements such as buttons, text inputs, links etc, will receive focus, meaning they are “preselected” and can be activated. The order in which elements will receive this focus is what we call the focus order.

In comparison, the reading order defines the order in which all elements of the page (not only the interactive ones) will be disclosed to screen reader users. It usually follows the writing standards of the page language. For English interfaces, the reading order is set by default from left to right and top to bottom, while in Arabic, it would be from right to left and top to bottom.

By default, focus order is set to follow the reading order. But in certain cases this default focus order doesn’t provide the best experience for people relying on keyboard. In this video (starting at 8:01), developers at Flutter share the example of a shopping cart floating button in the context of a mobile application. According to the writing system of the interface, it should be announced last. But as it is a fairly important piece of information on the page, the focus order has been modified by developers to announce the shopping cart within the first items of the page.

Example: After someone submits a praise, we move the focus to the main title of the confirmation page. As a consequence, the focus order is modified to match user needs: before accessing the navigation, they would first get the confirmation that the praise they wrote has been successfully submitted.

The current version of the plugin only lets you add arrows to indicate the path of the focus order. I added numbers in order to clarify which items should be read first. According to their Github documentation, the team will explore possibilities to dissociate the documentation of reading and focus order.

Alternative text

Alternative texts convey the purpose and contextual description of a graphic, be it an icon, an image or a simple graph in a textual form. These alternative texts appear in place of images when they couldn’t be loaded due to, for example, a poor internet connexion. They also provide information through screen readers to people who cannot see or read what is displayed inside a graphic.

The first step when defining alternative texts is to list all the images on a page.

Then, you decide for each of them: does the image in its context convey meaning that is not already conveyed through text? If yes, an alternative text must be written. If not, the alternative text must be left empty (alt=””). This way, screen readers will not announce the image to users, considering it as “decorative.” Careful here! If you don’t add an empty alternative text, the screen reader will announce the image using the name of the image file as alternative text. This turns out to be a confusing at best — frustrating at worst — experience for screen reader users.

The next step is to write a relevant and concise text for the graphics that need one. There are multiples recommendation depending on the nature of the content you need to convey. I recommend you to go through this alternative text decision tree to see which one applies to your case.

Include — Accessibility Annotations somehow reflects this process. You start by running a scan that will list all the images on the page you are annotating.

Example: Result of an image scan for the “Give a praise” page. The detection seems a bit buggy with SVGs, as it lists the different groups of a same SVG image. Also, shapes tend to not be detected, so always double check which graphics you have on your page.

By default, detected images will be set as “decorative.” You can change this in the pop-over of the plugin and add the alternative text you defined for each “meaningful” graphics.

Example: For the “Give a praise” page, I annotated Peerback’s logo and the notification badge next to the “Unpublished praise” menu item in the navigation as informative. The profile picture and each of the recognition icons are set as decorative as they are supplementing text on the interface.

What else can this plugin do?

Beyond the annotations for assistive technologies, the plugin also performs colour contrast automated check and colour simulations for different types of colourblindness, similar to what other tools offer.

Example: You can run an automatic scan of your design to verify its contrast. A preview is then available for you to see where contrast issues have been detected. You can then fix and re-scan the design or ignore the issue if it is a false positive. In this case, a contrast issue has been detected on a button which is disable: it’s a false positive.

Besides, you can also specify a touch target for components that have an invisible target area (typically, standalone links).

Example: The “Give a praise” page has an explicit touch target area for the “Back to selecting peers” link. I added a “touch target” label to clarify what this annotation is about.

Interestingly, designers can also generate a version of the designs with fonts that are twice their original size. Ensuring that the interface is usable even when enlarged is key for people relying on screen magnifiers. As of now, this feature rarely outputs perfect outcomes which means that you’ll have to invest a bit of time to correct the automated result. Still, it is very nice that designers are reminded to check their design at a different level of zoom. The tool also encourages designers to specify how the elements on the page should adapt to different devices sizes.

Example: The “Account & rights” page in 3 different versions: one for desktop, one for desktop zoomed at 200% and one for mobile. Ideally, a version also documents when mobile is zoomed at 200%.

As of now, I have used the plugin only for web-based project, but you can also use it to annotate designs for mobile technologies. Indeed, you can document the focus grouping and complex gestures in addition to all the other features mentioned above.

Going further…

This Figma plugin doesn’t support all accessibility requirements and good practices. For instance, it doesn’t cover anything related to motion design, although encouraging designers to think about reduced motion animation for people with motion sickness would be a great additional feature.

Nevertheless, it is a great starting point for designers who want to implement more accessible practices into their workflow. Besides, the plugin is being actively developed, so I hope new features will come in the future to support other accessibility requirements.

Conclusion

More and more tools are developed to help designers take accessibility into account. It’s an encouraging sign that accessibility is becoming an essential topic in the realm of interface design. Nevertheless, a key challenge remains: when it comes to accessibility, there is a huge knowledge gap to fill.

This is where semi-guided tools like Include — Accessibility Annotation are very efficient, as they provide contextual instructions that support knowledge transfer. Thanks to such tools, we can remain hopeful that in a near future, we, as designers, won’t only provide basic accessibility features, but rather aim for the best experience also for people relying on assistive technologies.

Dear designers, in the end, it’s up to you to take the initiative to learn and build practices around accessibility. It’s ok, not to get things right the first time. If you remain curious and open, you will progress!

Thanks for reading! Do you have a favourite accessibility tool? Let me know in the comment section below. Looking forward to hearing your questions or feedback.

Special thanks to Étienne Ndiaye for proofreading.

Additional resources

• Daniel Henderson-Ede created an Advent calendar composed of 24 daily accessibility annotations challenges. A great game to exercise your annotation skills!
• Stephanie Walter has written an awesome deep dive article about everything you can annotate to clarify your designs for handover.

Image credit

• Cardi B: Cardi B in interview in 2021 by Anthony Kane, licensed under CC BY-SA 3.0
• Doja Cat: Doja Cat demonstrating a makeup routine for Vogue Taiwan in 2020 ****Condé Nast (through Vogue Taiwan), licensed under CC BY-SA 3.0
• Franck Ocean: Frank Ocean by Andras Ladocsi licensed under CC BY-SA 4.0
• Janelle Monàe: Janelle Monae at Paris Fashion Week Autumn/Winter 2019 by Myles Kalus licensed under CC BY-SA 4.0
• Kendrick Lamar: Kendrick Lamar at the Pulitzer Prizes 2018 award ceremony by Andrew Lih, licensed under CC BY-SA 4.0
• Nas: Nas in 1998 by Mika Väisänen, licensed under CC BY-SA 3.0.
• Nicki Minaj: Nicki Minaj Headlines the T-Mobile Arena Grand Opening in Las Vegas in 2016, by Pure DOPE Magazine, licensed under CC BY-SA 3.0
• Queen Latifah: “Queen Latifah” by Affiliate Summit, licensed under CC BY 2.0
• Snoop Dogg: Snoop Dogg in Hollywood California on July 22, 2019 by Glenn Francis licensed under CC BY-SA 4.0
• Solange Knowles: Solange Knowles at Bonnaroo Music and Arts Festival 2019 by Raph_PH, licensed under CC BY-SA 2.0
• Tyler, The Creator: Tyler, the Creator in September 2012 by Incase from California USA, licensed under CC BY 2.0.