How accessibility bluelines shaped Adobe Fresco

Designing the details for a more inclusive application

Fresco's main editing space with tools labeled following an established top-down-left-to-right sequence; in the background a drawing of a potted camellia with a dark trunk, green/teal leaves, and pink flowers.

Illustration by Jinjin Sun

Audits don't conjure warm fuzzy feelings for most people. But Adobe's designers aren't most people. So when Adobe Design's accessibility team contracted independent accessibility audits of Adobe's product portfolio, it provided designers with an unflinching look at how easy it was (or wasn't) for people with visual and motor impairments to use our apps.

Fresco, Adobe's drawing and painting app, was among them. For Fresco, the audit revealed an illogical wayfinding structure and a need for a methodical approach to keyboard navigation order (whereby key presses are used to move around inside the app). Not long after, experience designer Jinjin Sun set out to make Fresco navigable by screen readers and keyboards so it would be useful and usable for as many people as possible.

Her task was to create of a sensible wayfinding structure and to document it for Fresco's engineers.

Accessibility bluelines are the design specifications that define and describe an application's wayfinding (focus order, keyboard shortcuts, content structure and annotations) so it can be engineered for assistive technology (screen readers, keyboards). For designers just beginning to think about and create them, the process that Jinjin and her colleagues followed shed light on the less visible requirements of doing that work.

A solid foundation

When an app's buttons and sliders and menus aren't labeled (so they can be identified by screen readers); when there is no logic to the way key presses move people around inside it (so keyboard navigation is easy and comprehensible); and when there is no identifiable content structure (so hierarchy is evident), it can prevent entire groups of people from using it.

Jinjin began by considering two structural approaches for Fresco's keyboard navigation order: The first a more common top-down-left-to-right (by layout) approach; the second, a less methodical frequency-of-use approach that put the canvas and most-often-used tools, first.

Fresco's main editing space with tools labeled sequentially; in the background a drawing of a potted camellia with a dark trunk, green/teal leaves, and pink flowers.
One of the focus order approaches being considered for Fresco. Keyboard presses follow an established top-down-left-to-right sequence for the main editing space: 1. top navigation, 2. toolbar, 3. brush settings panel for selected brushes, 4. touch shortcut, 5. canvas, 6. layer stack (if open), 7. taskbar. Art by Jinjin Sun.
Fresco's main editing space with tools labeled sequentially; in the background a drawing of a potted camellia with a dark trunk, green/teal leaves, and pink flowers.
An alternative approach to focus order based on the tools that an artist would use most often—the canvas and brushes. The numbering sequence begins with the canvas, moves left to the touch shortcut, toolbar, and brush settings panel, right again to the layer stack and taskbar, and ends at the top navigation. During research testers found this approach confusing. Art by Jinjin Sun.

An artist herself, she thought a frequency-of-use model would be best, but because it would be the foundation on which her bluelines were built, an educated guess wasn't good enough. She called in Adobe Design's researchers.

Questions and answers

Since good keyboard navigation alone can exponentially alter an in-app experience, it was the focus for inclusive design researcher Molly Bloom and Fresco researcher Mary Holland.

For Molly its importance was obvious: "Products that are usable only when accompanied by a trackpad, mouse, or stylus, don't support people with visual or motor impairments or those with overuse conditions. If we're building creativity for all, if we want to live up to our corporate mission, we need to think about the ways products are and are not usable."

To facilitate the research, developers Cameron Cundiff and Westbrook Johnson created a prototype. Their hybrid canvas, with tools borrowed from multiple applications, supported screen readers and enabled any action to be completed using a keyboard and keyboard shortcuts.

Mary and Molly used two versions of the prototype each with one of the navigation structures Jinjin was considering. They spoke to ten people with varying degrees of visual and motor impairments (and different needs for assistive technology) and varying levels of creative output (from hobbyists to students and creative pros).

Chart titled Who We Spoke To with ten names divided among three columns (left to right): Minimum creative activity, Hobbyist, Aspiring/Creative pro and three rows (top to bottom): Blind, Both, Motor.
Researchers interviewed ten people with varying levels of creative activity (from minimal to creative professional) and varying types and degrees of visual and motor limitations.
Chart titled Assistive Technology with ten names (each identified as using a screen reader, switch device & screen reader, switch device, or keyboard/none) divided among three rows (top to bottom): Blind, Both, Motor.
To get the most accurate look at how people used assistive technology, researchers ensured that participants were using a variety of devices. One surprising finding was that several participants who could most benefit from keyboard navigation were either unaware that they could navigate using a keyboard or didn't know how.

They documented their complete findings in Bloom & Smith (2020). Accessibility in the Semantic Canvas but what they learned about keyboard navigation and a coherent focus order (the order in which a screen reader makes its way through a UI) is that they provide an alternative way for everyone to work:

When an app's buttons and sliders and menus aren't labeled (so they can be identified by screen readers); when there is no logic to the way key presses move people around inside it (so keyboard navigation is easy and comprehensible); and when there is no identifiable content structure (so hierarchy is evident), it can prevent entire groups of people from using it.

Naming and context

The first step in blueline creation is labeling everything in the app. Not just assigning names to every button, panel, and tool, but also to their roles, states, and properties so their purpose and associated actions can be known immediately to someone using a screen reader. (Because it documents naming for every tool and action in an app, labeling is useful when creating tutorial content.)

Jinjin named every element in the UI. She also created what's referred to as "screen reader-only content," short descriptions that provide clarity by doubling down on naming. As an example, the image below contains a "Static Text" label in the Settings panel; without context it wouldn't mean much, so Jinjin included "Document size [xx] x [xx] [units]" to signal that dimensions and units of measure could be modified.

Expanded views of Fresco's Color and Document Settings panels with headers and additional screen reader-only content descriptions.
The H3 and H4 headers on these Color and Document Settings panels enable people using screen readers to navigate to a desired section and the screen reader-only content more thoroughly explains the roles and actions of buttons, sliders, and editable fields.

Because most of these labels aren't visible (like "Collapse/Expand" for buttons or "Adjustable" for sliders), anyone using Fresco without a screen reader wouldn't see them; but diagramming this content for developers is important so they can know what a screen reader would read.

Top-down-left-to-right

Next, Jinjin and Fresco experience designer Elissa Welsh set their sights on focus order. Key to these diagrams was creating a logical progression through the UI so people would know "where they are," especially when using keyboard shortcuts to skip around. Jinjin began with Fresco's home page, its main editing space, and its panels and pop-up menus.

Most of this work was straightforward but because panels and other temporary displays could affect screen reader focus, she created a list of exceptions:

The main editing space is greyed-out behind Fresco's App Settings panel with its sections labeled sequentially top-down-left-to-right.
When a modal window is superimposed over the main editing space focus order is concentrated on this foreground content and nothing behind it is recognized by the keyboard.
Fresco's main editing space, with an additional tool option display in the bottom center; in the background a drawing of a potted camellia with a dark trunk, green/teal leaves, and pink flowers.
When a HUD is displayed on the screen, the focus order begins on it so that someone using a screen reader will know it's there. From that point, focus order continues in a traditional top-down-left-to-right order. Art by Jinjin Sun.

Panels, a wayfinding compromise

Panels in Fresco are many and varied. And since it's still a relatively new app, features and functionality (and panels) are added often. Key to this work was not only creating a logical tabbing focus order for them but designating how arrow keys would be used for expandable lists and navigating between tabs.

The image below shows one of Jinjin's deviations from left-to-right constraints to keep focus on the features of the Pixel Brushes panel (note that the first button from the left is the panel grabber and next to it the close button).

Four views of Fresco's Pixel Brushes panel showing a top-down navigation order and left-right-up-down arrow keys for navigating the brushes tabs and lists.
Panel navigation varies a bit from the standard top-down-left-to-right focus order because it focuses on tools first, the brushes More Actions button (1), and finishes with Add Brushes (6), the grabber handle (7) and Close (8). Also key for panel documentation is showing how arrow keys enable movement from left to right between tabs and up and down through expandable lists.

For panels like Fresco's Precision panel, which houses the tools for precisely placing content and for drawing in perspective, the complexities of focus order multiplied because along with a boatload of functionality is an unfolding system of options and menus and checkboxes and sliders. Once expanded, they reveal additional informational headers, buttons, and directional arrows for sliders that dive into different tool states.

Elissa's files give Fresco's developers a step-by-step guide to how a screen reader would navigate by calling out focus order and the naming and context for features, functions, and settings:

Fresco's main editing space overlaid with a perspective grid and tools labeled sequentially; in the background a drawing of a young woman with windswept hair sitting atop a parapet amid fluttering sheets under a storm-gray sky.
Documentation for Fresco's multiple-tool Precision panel is both complex and thorough. The top-down-left-to-right focus order is supplemented by expanded menu views (for Grid Type and Vanishing Point), headers for six sections are clearly marked, any buttons that aren't clear are paired with screen reader-only content, and directional arrow keys show how to adjust sliders. Art by Erin Connally.

The next two images show a more advanced type of documentation that required Elissa to create the focus order for changing perspective, or moving/adjusting a drawing aid (shape) placed on the canvas. Key to these diagrams are the bounding box handles (top) for adjusting shapes and the vanishing points (bottom) for modifying perspective. Because of the complexity of the panels and the tasks, the canvas is treated separately and has its own focus order.

Fresco's main editing space overlaid with a perspective grid and tools labeled sequentially; in the background a drawing of a young woman with windswept hair sitting atop a parapet amid fluttering sheets under a storm-gray sky.
The Precision panel, with a focus on a Drawing Aid (shape) placed on the grid. The panel and the canvas have distinct hierarchies. The canvas hierarchy begins in the upper left corner of the canvas then, so a screen reader is aware of the pop-up tools at the bottom center, down and around the perimeter of the shape's bounding box (marking every point) and ending at the rotation handle at the top of the screen. Art by Erin Connally.
Fresco's main editing space overlaid with perspective tools and vanishing points; in the background a drawing of a young woman with windswept hair sitting atop a parapet amid fluttering sheets under a storm-gray sky.
The top-down-left-to-right focus order begins at the Cancel button (it removes the perspective grid) and moves to the header text identifying the Perspective Grid dropdown menu and the items in it (the ability to switch between 1-, 2-, and 3-point perspective). Each button is also labeled with screen reader-only content context and vanishing points are labeled with left-right-up-down arrow keys for adjusting perspective. Art by Erin Connally

The end of a beginning

What began with an audit ended with an accomplishment.

Creativity for all is a formidable goal. And as it pertains to accessibility, when every accomplishment is followed by a list of things yet to be done (for Fresco, those might be showing the location of content on the canvas or providing a way to draw without a stylus, mouse, or trackpad), it can seem unreachable.

But every step is progress.

The sentiment is summed up by Matt May, head of inclusive design at Adobe, who sees this work as an exemplar of the capabilities of Adobe Design: "Fresco is a way for us to plant our flag, to prove that we can do this, that it enables a lot more people, and that we have the skills to work our way into the heart of our product portfolio."