Annotating Designs For Accessibility

Annotating Designs for Accessibility by Anna E. Cook

Hi everyone and thank you for coming to my session today on annotating designs of accessibility I’m so thrilled to be joining you all at my first A11yTO in person!

Hi, I’m Anna!

• Pronouns are She/They
• Senior Designer at Microsoft working on accessibility and inclusive design for Azure
• Master’s student studying inclusive design at the ATLAS Institute of CU-Boulder

What we will discuss

• Today we are going to talk about accessibility annotations
• We’ll start off with a quick recap of design and accessibility and then get into what accessibility annotations are, what they can do, when to use them, and the limitations of annotation kits

Recap: design and accessibility

• Let’s start with a recap of design and accessibility
• Now I am going to assume everyone here knows that accessibility matters, and that we need to make our products accessible
• But I want to specifically take a moment to talk about how accessibility and inclusion currently lives in design processes

Few designers are taught about accessibility.

• So, the first thing I want to emphasize here is that very few designers have traditionally been exposed to the importance and practice of accessible design.
• I’ve spoken on this in a lot more depth in the past, but the long story short is that there are still significant knowledge gaps for designers.
• This is changing industry-wide, but far too slowly.

67% of accessibility issues can originate in design

• Every day designers continue to design significant accessibility barriers into experiences without meaning to
• In a study conducted by Deque, they found that 67% of accessibility issues can originate in design.
• The cost of fixing inaccessibility from design mistakes can be amplified as issues move across a product cycle,
• It can take 6 times longer to fix defects in development, 12 times longer to fix them in testing, and 30 times longer to fix them in production.

Shift Left

• Now who is responsible for which accessibility considerations can be up for discussion
• But the reality is that designers are responsible for accessibility considerations.
• We have a huge influence on what is made visually, in interactions, and in content.
• We are far more responsible for accessibility and inclusion than we have been expected to be or taught to be.
• Developers can’t out code inaccessible designs, testers can only document issues not fix them holistically

We need designers to account for accessibility

• The reason I mention this is that I want to make sure we are all on the same page Holistic accessibility requires dedicated support from all team members to be effective.
• Accessibility is a designer’s job as much as it is a developer’s, a tester, or any other role in product.
• To truly shift left, we need designers to account for accessibility

We need designers to account for accessibility beyond visual design.

• Yet so often designers only consider accessibility in terms of visual elements And while visual design does affect accessibility and inclusive design, we need to consider more
• So we also need designers to account for accessibility beyond visual design alone.
• Now the question is, how do we empower designers to do that part of their job and do it well?

What are accessibility annotations?

• There are many things we can and should do to achieve more inclusive design practice
• But we are going to focus on one thing today: accessibility annotations. These are meant to help designers include basic accessibility beyond visuals in their practice
• So, what are accessibility annotations?

Accessibility annotations are specifications that divide gaps in visual designs and prototypes.

• Accessibility annotations are specifications that divide gaps in visual designs and prototypes.
• They are meant to help account for accessible and inclusive design needs that cannot be communicated just through our mockups and prototypes alone, often beyond visual design.

Accessibility annotations have existed for years but have popularized in the past 2–3.

• Accessibility annotations have existed for years, though I can’t personally speak to exactly when we started using them.
• The first accessibility annotation toolkit I could find was the one released by Deque for Sketch and Adobe Illustrator.
• I believe this means that these annotations have been a trend in the last 5 years, but with a significant jump in the last 2.
• Toolkits have more recently emerged for Figma, these include the ones released by Indeed, Twitter, and Microsoft.
• My understanding is that there are organizations that have used these existing kits and customized them and other organizations that have their own that aren’t available for others to use.
• So, these are pretty new, not all teams are using them, and every team seems to be using them slightly differently.

Annotation kits tend to be managed like component libraries

• In Figma and Sketch, these annotations tend to be managed quite similarly to a component library
• Except the difference is that these are purely for internal usage
• Often these kits come with a set of different annotation types
• Our designers can turn the library on to pull individual annotations into their designs
• Designers can also customize these annotations to point in different directions, have custom labels, and the like depending on the kit
• If you use Figma and you search in the community for “accessibility annotations”, you can find kits like these to use right now and try them out yourself.

Specification could not be indicated through the mockup or prototype itself

• Let’s look at an example of annotations in action together
• In this example, we have a set of inputs related to a time period
• The user is meant to set parameters for a time period including a “from” and “to” set of values where each has a month and a year to select.
• Just looking at this design, we might wonder how clear each month and year input is for someone who blind or low vision for example because the month label is from, or to and there is no year label

Annotations tend to be overlaid on mockups, or on individual components used in a mockup

• But when we look at this set of inputs with annotations applied, the experience improves
• In this case, the way the kit is being used is to specify programmatic labels for a set of inputs, as well as a fieldset legend for those inputs to group them together
• As a user moves through each input, they should know that they need to input month from, year from, then month to, and year to for a time period. This specification wouldn’t be apparent in the design alone, so annotations were used to divide that gap

Commonly used annotations

• Now that we get a sense of how annotations tend to look and how they work, let’s talk about some commonly used annotations.
• I’ve developed annotation kits and trained about 90-100 designers to use annotation kits.
• In my experience, these tend to be the annotations I’ve seen them use the most

Commonly used accessibility annotations

• Any annotation you use is going to vary from kit to kit, but there are a few that I tend to notice more consistently.
• We will discuss annotations for alt text, button labels, focus order, form labels and legends, input feedback, heading structure, keyboard interactions, and components in use.
• These are annotations I tend to recommend the most for product designers rather than design system designers
• Keep in mind that every team and organization might find they use certain ones more than others and the context is going to vary

Alt text

• One annotation I notice designers use when they are starting to learn about accessibility is providing alt text for an alt attribute
• What I love about this annotation is it really makes designers think about the intention of the imagery they are using
• It helps them remind them that if an image has meaning, it must be described and the description of that image should be meaningful
• It also challenges designers to think about why they might have included non-essential or decorative images
• In the example on this slide, I have a pixel portrait of myself with the alt text annotation reading “A pixel art portrait of Anna, a white woman with strawberry blonde hair and blue eyes.”

Button labels

• Probably the most common annotation I see designers use from kits is related to button labeling, specifically for icon buttons
• These annotations help for instances where a designer has included a button that needs a programmatic label
• They also help serve as a reminder for designers to include text labels with icon buttons that are too unclear with just the icon alone.
• In the example on this slide, I am showing two inputs for a required password input field.
• On one example, there is a closed eye icon that has a label annotation for “show password.” On the second example, there is an open eye icon that has a label annotation for “hide password.”

Focus order

• Next, annotation kits almost always include focus order specifications.
• I know what you’re thinking. Why would we want designers to specify focus order?
• Well, in most cases designers probably won’t need to.
• These annotations are most useful for more complex page structures, usually where dialogues or elements living outside of a standard focus order are involved.
• Focus order annotations should be used to ensure that requirements for complex document object model structures (or DOMs) are clearly communicated so that they are built properly.
• In the example, I am showing a “Contact Us” form where first name, last name, email, and phone number are all required inputs. The inputs make up 2 columns and 2 rows, and the focus moves from the top row to the bottom row and then to submit button.

Form labels and legends

• We have already talked a little bit about form label specifications in the example I gave at the beginning
• I will say that this annotation can be helpful to get designers to think more about how they can better group inputs and section them out for more progressive input flows
• It also is a good way for designers to understand that not all users can see a viewport the way they might and that inputs should be as clear as possible on their own rather than with the surrounding context.
• In the example, I am showing a footer with a set of radio buttons for theme, including buttons for System, Light, and Dark. Annotated around these inputs is “fieldset legend = “theme”

Input feedback

• Annotation kits are often used as a reminder for designers to specify input feedback
• More commonly, I see these used for error state feedback, but these can be used for any input feedback.
• One thing designers tend to do is think about inputs only using ”happy paths,” so without issues and errors.
• The practice of thinking through potential feedback needs is essential for all interactions, particularly those where users with disabilities are concerned.
• It’s important to note that input feedback messaging tends to be something we have content designers work on, so an annotation tool in Figma may not always be helpful.
• As long as that feedback is being noted somewhere and communicated that is all that matters, it doesn’t have to be through a kit.

Heading structure

• Moving away from inputs, we have annotations that can be used for heading clarification.
• If a designer is using a design system, they should be following the heading structure that is outlined in the system and ensuring that they are mapped to a hierarchical structure.
• But designers can focus too much on the visual hierarchy of their designs rather than what is communicated semantically
• When designers use heading annotations, they often realize that they are thinking only about visuals
• Annotations like these can also be helpful when designers need to specify some elements that may not obviously be headings, or predefined headings, as headings.
• In the example, headings are outlined hierarchically for a taco recipe example.

Keyboard interactions

• Designers also may use keyboard interaction annotations to ensure that any components or functionality requiring more in-depth keyboard specifications include them
• This tends to come up more often for components that do not have semantic functionality and require more in-depth consideration to ensure they are accessible
• The example in this slide includes a menu button that allows a user to hit enter or space to open the menu and down and up arrows to navigate through the menu items before making a selection.

Components in use

• One thing I will mention in regard to these annotations is something I haven’t seen in open-source kits
• However, it has come up in conversations with other accessibility design advocates as important
• When a designer is using a design system to create mock-ups, one thing they need to be annotating for is what components they use
• This is particularly the case when they are using components that could easily be confused for other components by a developer
• For example, if a button is designed to look somewhat similar to a link but behaves as a button, a designer should ensure that they specify that they are using a button.

Other annotations found in various kits

There are more annotations than what we have discussed today, but these are ones I think are most valuable. Other annotations I see tend to be less valuable for the design specifications themselves. This includes ARIA specifications, autocomplete, different interaction states, landmarks, page titles, prefers reduced motion and link providing captions and transcripts In most cases these types of specifications are happening elsewhere or tend not to need overt communication In the example of adding ARIA, which we really don’t want designers to do to avoid having them misusing it or overusing it

How should accessibility annotations be used?

• This leads us to the inevitable follow-up question: how should accessibility annotations be used?
• We’ve talked about how they can be applied to examples, but we haven’t gotten into when they should be used, or how often they should be used.

Accessibility annotations shouldn’t be used on everything everywhere.

• On this slide is an example from Twitter’s annotation kit showing every annotation they have and how it can be applied to a page
• They are showing all of these annotations to show just how many ways this can be applied which is helpful for getting a sense of every annotation available.
• But as you can imagine, designers seeing this tend to expect that annotations should be used on every component of every page anytime they design something.
• I want to emphasize that that is not, nor should it be, the expectation for how accessibility annotations should be used.

Annotations should only be used as needed.

• Accessibility annotations should only be used as needed.
• If a designer is building an entirely new page or experience, they may need a lot more annotations
• But if a designer is working on a new feature in an existing product, they don’t need to annotate the existing parts of the experience.
• They should only be annotating what they are changing or adding to an experience.
• In this example, I’m showing how a Twitter designer might have used the A11yName: annotation on the new downvote Tweet button they added

Annotation density

• When it comes to accessibility annotations, designers should only use annotations to specify behaviors for what is new
• How many annotations should be used depends on the context in which they are applied
• For an entirely new product, designers will need to annotate more because existing components and templates won’t exist yet
• For new features, designers tend to annotate more because they often create new elements and components or use components in new ways.
• If they are creating new functionality, generally minor adjustments to an existing experience, they tend to annotate less
• Remember that these annotations are a tool and like any tool, they need to be used only when it makes sense.
• So if you use them, use them as much or as little as needed

What are the issues with accessibility annotations?

• I wouldn’t be doing my due diligence if I didn’t spend a few minutes talking about the issues with accessibility annotations as they exist today
• Accessibility annotations definitely have room for improvement and should be used thoughtfully

If designers don’t understand accessibility, annotations aren’t useful.Designers must be trained to understand basic accessibility before they use annotations.

• Firstly, accessibility annotations are useless to designers who have little to no understanding of accessibility.
• Any accessibility annotations that we plan to release to designers should be paired with training.
• As we discussed earlier, many designers aren’t trained to think about accessibility.
• So to hand them annotations and say “here ya go!” without any support will set designers up for failure
• If annotations are misused, they can make things even less accessible.
• So these kits should come with training, guidance, and regular support.

Accessibility annotations can’t fix bad patterns.But they can help designers better understand why those patterns are bad in the first place.

• Secondly, accessibility annotations can’t fix bad patterns.
• You can’t stack a bunch of annotations on an animated slider and expect that it’s going to be a better experience, the same way you can’t just add ARIA to bad code.
• That said, what I’ve seen happen is that designers tend to try to annotate bad patterns and come to realize through that process that those patterns don’t work in the context they are designed for.
• So, while annotations can’t fix bad patterns, they can help designers understand why those patterns don’t work and that to me is exceptionally valuable.

Accessibility annotations tend to require manual specing.Maybe they could be less manual if design tools better accounted for accessibility

• The last issue with accessibility annotations that I will call out is how they tend to be very manual
• Accessibility annotations feel a lot like redlining in a way that can feel archaic given the design tool updates we’ve had in the past 10-15 years
• While annotation kits tend to be reasonably understandable, designers tend to have to pull out their designs and annotate them in a separate page of a Figma file.
• Right now, this is an unfortunate inevitability that comes with accessibility annotations.
• I hope in the future that these capabilities will become less manual and that these considerations will be baked into our design tools themselves

Should we use accessibility annotations?

• As we wrap up today, I want to kind of summarize everything I’ve shared into one final question: should we use accessibility annotations?
• You might be thinking “Anna why would you ask this question now, after sharing all of the benefits of annotation kits?”
• But this isn’t me asking this question, it’s you and your team.

Annotations are a communication and thinking tool.

• If you take anything away from this talk, I hope it is this: accessibility annotations are a tool and should only be used as long as they are useful and valuable like any other tool
• In my opinion, the most beneficial thing about annotation kits is not how they could streamline specifications
• What is most valuable about annotations is that they can be used as a way to change how designers think about their work
• It’s about getting designers to actively think about accessibility and inclusion in their process, throughout and beyond visual design It’s about actively asking them to think through what they’re making and communicate it with others.
• In that way, accessibility annotations can be valuable.

It depends…

• That said, I want to emphasize that accessibility annotations are not going to be useful for all teams.
• So should you use them? It depends.
• I encourage teams to look into kits and fit them to your organization’s needs if they make sense
• Partner them with in-depth accessibility and inclusive design training and you’re off to a great start
• But don’t feel obligated to use them if your team has different or better ways of handling these needs At the end of the day, I don’t care if we use accessibility annotations.I care that we build inclusive and accessible designs regardless of the tools and processes we use.

Thank you!

• With that, I want to thank all of you for attending this talk
• I hope I was able to show you something new and helpful today
• I appreciate your time, please feel free to connect with me on * Twitter or LinkedIn @AnnaECook

Credits

Annotation kits referenced

• Deque
• Indeed
• Twitter
• Microsoft Fluent

Sources

*Slide 8

• Accessibility and Automation: Shift Left ROI, Deque, 2020.
• The exponential cost of fixing bugs, Deepsource, 2019.

Thanks to...

• Shell E. Little – for taking the time to help me refine and improve this presentation, your mentorship has been invaluable to me
• Eric Bailey – for taking the time to review my research on accessibility annotations and offer honest feedback
• Everyone at A11yTO for welcoming me into this community