Annotation Toolkit

Accessibility Gap

A few key knowledge gaps existed. All FCBers on the Discover account take a course on WCAG standards and principles. Our work was accessibility first, so we wanted to ensure everything we delivered followed the highest standards of compliance. We needed a way to scale accessibility for a large enterprise, so that WCAG is checked early and often in both design and development.

Internal interviews:

Our annotation process had been very ambiguous and nebulous up to this point. We determined the rules as we went, depending on pre-existing client preferences, internal talks and stated resources on a client by client, project-by-project basis. However, often times clients had a lower level of accessibility maturity than ourselves.

We felt there was an opportunity to take initiative in accessibility, starting with documentation.

Stakeholder interviews:

DFS had low accessibility maturity. Developers were reliant on Google for accessibility questions, and uncertain of Discover’s internal compliance guidelines.

Questions to resolve

• Where do we/do we not build in flexibility?
• Where does alt text change versus not change?
• What is the responsibility of the dev team versus the feature team with regard to accessibility?
• Where is the line and what gets lost in translation?

Field Research

The purpose of our earliest research was to identify which existing tools would help our workflow. We paid particular attention towards embedding accessibility features early in our processes.

The core aim of this research was to identify...
• how these tools could streamline our workflow
• how to automate significant portions of our annotation process
• reduce friction in making our outputs universally accessible

We evaluated four Figma Accessibility Plugins:
• Stark
• A11y
• Annotate It
• Annotate Design

We recreated annotations for the Discover app’s landing page, Account Center Home, using all four plugins in order to evaluate structure and performance.

This helped us determine not just which plugins were helpful, but what key accessibility rules they described. From there, we drafted an outline for our own annotation toolkit, which we built in Figma using our field research as a guide.

Questions to resolve:

What makes the process feel intuitive, rather than grating? What features perpetually recur, and which are variable? How does the output visually occupy the frame?

WCAG Reference

We cross-referenced the Web Content Accessibility Guidelines (WCAG) 2.1 with early designs to ensure our toolkit aligned with industry standards and best practices for accessibility. We found that the plugins we tested covered a lot of the same ground as the WCAG guidelines.

Recurring elements:
• Focus Order (Keyboard navigation),
• Reading order (Screenreader voiceover),
• page landmarks,
• interaction details.

Now we had content guidance. We began to draft documentation and UI for our own annotation utility.

Stimulus Testing

We tested the toolkit with internal stakeholders, including designers and developers, to gather feedback on its usability and effectiveness in communicating accessibility features.

After assembling this list, we started by trial-annotating the existing in-app landing page, attending to responsive differences across devices.

Stimulus Testing Results

The stimulus testing revealed that the toolkit was effective in communicating accessibility features to users.

However, it also highlighted areas for improvement, such as the need for more simplified visual cues.

Developer stakeholder feedback clarified some redundancies: e.g., that ARIA affordances are made at the feature level and don't need to be documented in designs. We were also able to drastically simplify our annotation process by confirming with developers that Business-as-usual elements (that is, elements that repeat across a feature) don't need new annotations everytime they appear.

Final Design

The final design of the toolkit is a published Figma library with reusable components that can be easily applied to any design. The toolkit includes a variety of stamps for different accessibility features, as well as enhancements for more complex annotations.

We made sure our documentation followed the same organizational logic used by the rest of the design system.

Usage Examples

The following are examples of how the toolkit can be used in practice:

True to form, our toolkit proved robust and helpful. While building the RDS Design System, we made sure a round of accessibility annotationwas included at the end of the design process for each component we touched. By way of example, below are the accessibility annotations for the “Tab” component I worked on.

Accessibility Considerations:

(Direct quotes from documentation)

Learnings and Takeaways

Annotations benefit large efforts and/or large audiences by providing clear documentation. They encourage collaboration between design, development, and business; and they ensure alignment on the user experience.

This was my first foray into design operations. The result isn't a flashy live feature, but it allowed us to rapidly improve output and consistency in our delivered files. The UX team was able to solve a problem that had been lingering for a while. It was also a great opportunity to collaborate with developers and get on the same page about accessibility best practices.

Pro tip: Annotate at the end of the design process!

After annotating 150+ delivery files, I can safely say that it's a lot easier to deliver annotations with R2 designs, once the design is finalized. That way, you're not stuck adjusting as many as 72 reading order stamps by hand after a new section is added to the top of the page.

In sum:

I'm, grateful for everything this process taught me about thorough, rigorous accessibility planning. Knowing the WCAG Guidelines in theory had been all well and good, but having a deep working knowledge of the details of the requirements has been invaluable in making recommendations to clients, developers, and fellow designers alike.