A11Ry

Proactive Web Accessibility

I'm a lead contributor at a large organization, embedded in our centralized design system team where I manage a group of interface designers that specialize in web accessibility. We collaborate daily with research, engineering, and our visual design team to support our globally-adopted system. Before we heightened accessibility as a business priority, accessibility considerations were mostly ad hock, and sort of chaotic. In this post, I'll share a bit of what I've seen and learned while advocating across global product teams and driving universal design practices through our design system.

Getting started #

Leaving WCAG links in a Jira story for development engineers to decipher during a two week sprint is way too late to start considering accessibility. Often times I've seen this surface a halfbaked interaction design that becomes more evident from the flood of questions you receive from annoyed developers that are just trying to bring their work to completion, while being prodded daily by a scrum master. A grooming session is hardly enough time to consider keyboard accessibility for something like a tree navigation, let alone the learning curve involved in testing that it works across popular assistive technologies. Even if the story is spiked, the likeliness that a developer unfamiliar with accessibility will have the time to absorb all the necessary information to accurately implement the accessible feature is an unrealistic expectation. Practices like this stem from the common misconception that accessibility responsibility falls primarily on developers, because they write the code that makes it real. For a group of people that do Jackie Chan backflips whenever developers get too creative, we designers sure do leave a lot of the interaction thinking up to our engineering teams. While engineers share the responsibility of producing an accessible end-product, accessibility considerations are most effective when explored early in the design process. First, you'll need to ensure your entire product team is aligned on the priority of accessibility. Without this shared understanding, accessibility work runs the risk of being sidelined due to "higher priority" items. This often stems from fundamental misunderstandings around accessibility, or, the empathy gap, as Dyan Barrell discusses in his book, The Agile Accessibility Handbook. Expect to spend some time identifying and collaborating with other accessibility champions to gain perspective and piggyback on solutions that may already be working in other spaces. Also expect that you'll need to convince your project stakeholders of the value of proactive accessibility.

Identifying champions #

Your colleagues may already be serving as accessibility advocates in their respective spaces. Try to connect with accessibility champions either on your own team or across other internal business units. Connect with people that have relevant job titles similar to your own. Chances are, they've encountered the same challenges. Inquire about any solutions they've managed to implement and how they went about gaining support. Observe people that may have personal connections to disabilities, maybe an employee or an employee's family member. I've found collecting personal employee stories can help support the broader business case for accessibility and help draw internal empathy with stakeholders (these stories can be anonymous, but definitely seek approval with the individual first).

As you make connections, consider starting an MS Teams or Slack channel dedicated to conversing on digital accessibility topics. Proposing a monthly sharing webinar on accessibility-related topics is also good way to spread awareness and make connections with collagues that are facing similar challenges. Determine a manageable frequency for the webinar to ensure attendance. Gather topics and speakers ahead of time, utilizing your connections and the knowledge shared in your accessibility messaging channel. You can use the channel to promote future sessions.

Establishing a small community of practice is an effective way to share obstacles, knowledge share, and collaborate on proactive solutions. Surfacing the struggles of others will ultimately help support your business case.

Obtaining stakeholder support #

A bottom-up approach to accessibility can be disruptive (in a bad way), as mentioned in the beginning of this post. It's critical for the entire product team to understand that accessibility is a project priority, otherwise your well-intentioned efforts can be steamrolled by product managers or owners that are unaware of the benefits gained through universal design. If you are the accessibility champion in your space, consider how you can articulate the benefits of proactive accessibility to project stakeholders. Fortunately, the W3C has a wealth of business cases you can read as a starting point for communicating the customer benefits of universal design or the negative impacts of inaccessibility. Incorporate any relevant data you collect from your partners or your accessibility community of practice to further support your business case.

Which case to lead with? #

While we can all agree prioritizing accessibility is simply the right thing to do because it literally benefits everyone, leading with this argument alone likely won't be enough to convince stakeholders to invest in accessibility initiatives, unfortunately. If your company sells in highly regulated markets where procurement laws clearly apply (such as section 508 in the US), consider the revenue at risk as a result of non-compliance (especially for B2B's that sell to organizations that receive federal funding). Even if your organization isn't bound by procurement laws, consider the growing trend of global accessibility awareness and the impact on the market. Many companies are beginning to implement diversity and inclusion initiatives not just for customers but for their own employees, which directly influences their purchasing decisions. I hear this concern from customers at my current organization on a monthly basis. Consider the cost effectiveness of addressing accessibility early in your design process vs remediating accessibility debt that ultimately disrupts both design and code. Think about accessibility inaction as a melting ice cream cone. It just gets messier the longer it waits and the end result is expensive remediation. Even worse, there are major costs associated with possible lawsuits or damage to your company's brand.

"Ain't nobody got time for that!"

- Kimberly Wilkins

A proactive accessibility process takes time to adopt. Top-down support doesn't need to come from the highest levels of the organization at first (but this is certainly the most ideal situation). Depending on the size and maturity of your organization, this may take a considerable amount of time and effort so try to be patient while remaining diligent.

Takeaways #

Stayed tuned for my next article, Practicing Proactive Accessibility in a Large Organization, where I'll share more on the roles, responsibilities, and processes I've found to be effective for designing for universal experiences.