Building Accessibility into Adobe Experience Platform

[#1]

Authors: Amy Durocher, Andrew Kirkpatrick, and Jenny Medeiros

This post describes our journey building accessibility into Adobe Experience Platform and our approach to achieving the ambitious goal of becoming accessibility compliant by the end of 2020.

The accessible design has rightfully become the focus of leading organizations worldwide. With almost 20% of the global population living with some form of disability, it should no longer be an afterthought to offer different ways for people with sensory, physical, or cognitive impairments to access online products.

At Adobe, we firmly support and encourage building inclusive user experiences that are accessible to customers of diverse abilities. To further our commitment, we are purposefully designing new Adobe products with human differences in mind, and revisiting past ones to bring them up to standard.

In this post, we share the highlights of our ongoing accessibility journey as we tirelessly work to make Adobe Experience Platform accessibility conformant by the end of 2020. We also offer recommendations for others aspiring to open their content to new markets, enhance their brand, and drive innovation.

The principles of web accessibility conformance

Accessibility enables people with disabilities to perceive, understand and navigate a product or service. If this isn’t reason enough for organizations to become accessibility compliant, here are a few more considerations:

• Adopting an accessible approach to content removes barriers that exclude millions of users, extending the organization’s reach to new customers and new markets.
• Designing for accessibility overlaps with many best practices in user interfaces (UI), user experiences (UX), and even search engine optimization (SEO).
• It is now law in the United States, Canada, and the European Union to provide accessibility on commercial and public websites.

To help organizations reach these accessibility standards, the Web Content Accessibility Guidelines (WCAG) from the World Wide Web Consortium (W3C) provides a comprehensive set of guidelines for accessible design.

For the purpose of this post, we will describe four areas of focus, which are linked to the four main principles of WCAG:

• Content must be accessible in different contexts: Users must be able to perceive and consume content using the senses they rely on. This means the UI must be accessible in various formats, so a user with low vision can view the font in a bigger size, or a user with color blindness can switch the color palette, for example.
• Interface elements must enable keyboard navigation: Blind and low vision users rely on their keyboards — not a mouse — to navigate content. Subsequently, content should allow these users to successfully navigate the UI using only their keyboard.
• UI and language patterns must be consistent: Content must be presented in a consistent and predictable manner by using clear, concise language and excluding jargon or excessive acronyms. This clarity of language is essential for the user’s understanding of critical messages and important features.
• Content must work with assistive technologies: The content must be structured to allow interpretation by assistive technologies. For example, programmatic labels, known as ARIA labels, enable screen readers to describe visual elements, such as the ‘X’ to close a pop-up window.

Our journey to build an accessible Adobe Experience Platform

To begin, we assembled an interdisciplinary team comprised of a product manager, an accessible design lead, and four developers. Each member works closely with the Adobe Accessibility Team to ensure our efforts fully comply with WCAG guidelines.

Next, we invited an auditor to evaluate the current state of Adobe Experience Platform and identify accessibility shortcomings across five key Platform workflows. The accessibility audit resulted in almost 200 accessibility issues, which were logged directly into JIRA. The following image provides an example of some of these issues:

Figure 1: Example of Adobe Experience Platform accessibility issues

As shown in the image above, much of the UI was custom-coded without considering accessibility practices such as ARIA labels, keyboard navigation, and easily distinguishable colors.

With almost 200 issues to solve, our initial task was to categorize and prioritize each issue in JIRA — under the guidance of our Adobe Accessibility Team.

Subsequently, during the first year of this project, we focused on resolving blocking and critical WCAG 2.0 conformance issues that were essential to the five core workflows across Adobe Experience Platform.

Now in our second year, we continue fixing blocking issues in Adobe Experience Platform Query Service, Adobe Experience Platform Data Science Workspace, along with with non-core workflows, non-critical WCAG 2.0 issues, and WCAG 2.1 conformance.

Our process

To work through these issues, we created an iterative process that ensures every new user interface is built with accessibility in mind from the ground up.

Figure 2: Diagram showing our new UI process for accessibility.

Requirements

The product manager begins by creating a checklist of accessibility requirements for designers and engineers. These requirements outline specifications for how certain UI elements should look and behave to be accessible, such as a specific tabbing order or contrast level.

Design

Here, designers must look at the new user interface holistically and funnel down to its individual components. For the actual design, they use Adobe Spectrum — a visual, open-source language with substantial accessibility support built-in. Typically, designers need to go back and translate older UI features into Adobe Spectrum before introducing a new one.

Furthermore, they must warrant the new UI component not only complies with the given accessibility specifications, but also with Adobe’s culture of designing features that can later be reused across multiple products.

Accessibility review

The new UI design is then passed through the Adobe Accessibility Team for a review in terms of WCAG conformance and usability for users with disabilities. If needed, the designs may be returned for modification and resubmission, creating a thorough feedback loop.

Code test

Once the UI has been developed, the product manager conducts quality assurance to verify each accessibility issue has been correctly resolved. For this, we currently employ web browser plugins: axe — Web Accessibility Testing and Accessibility Insights.

To code test, developers execute an automated test known as “code linting” which is designed to catch accessibility issues, such as improper form labeling and missing table headers.

Code linting is run before the team commits any new code — a tactic that has proven highly successful considering the number of accessibility issues rolled from 204 down to four in just five weeks.

Accessibility recommendations

Achieving3accessibility is no small feat, and best practices are equally as important as designing and coding. Below are some key considerations.

Enroll in accessibility training

Before embarking on this journey, those in the team who were not well-versed in the subject enrolled in accessibility training with WebAIM. This significantly enhanced our understanding of what was needed, and broadened our perspective on accessibility conformance tools and practices.

Work with accessibility experts

While every member of our team had some level of experience with accessibility, having close collaboration with the Adobe Accessibility Team has been essential to our success. It’s strongly advisable that organizations looking to enhance their web products consult with accessibility experts every step of the way.

Embed accessibility from the start

Adding accessibility as an afterthought consumes more time and resources than building an accessible product from day one. If, like us, going back to rebuild is inevitable, it’s important to establish a workflow that will guarantee future products can be accessed without barriers.

Continuing our mission of providing equal access to every user

Here at Adobe, we’re constantly working to make the inclusive design the norm. We understand that adopting accessibility standards does not automatically provide equal access and opportunity for all users, but is the best first step toward allowing people with disabilities to participate more actively on the Web.

While there is still a long road ahead, we are confident in our ability and motivation to achieve accessibility conformance throughout Adobe Experience Platform. We are also optimistic that more organizations will join us in bringing down the barriers for users with disabilities, inching the Web closer to its fundamental purpose of providing universal access for all.

Follow the Adobe Experience Platform Community Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products. Sign up here for future Adobe Experience Platform Meetups.

Originally published: Feb 6, 2020