From Nothing to Something: How A Team of 2 Kickstarted an Accessibility Program

Introduction

In this co-authored blog post, Alexis Lucio and Sim K Sidhu will cover how they kickstarted an accessibility program at Splunk. Splunk turns data into doing with the Data-To-Everything Platform, designed to investigate, monitor, analyze and act on data at any scale. Given Splunk’s mission statement of “making machine data accessible, usable, and valuable to everyone,” you’d think that applying accessibility (a11y) best practices is easy; and, as any accessibility practitioner knows, that’s not always the case.

In this blog post, they will  share learnings in developing an accessibility team, especially around:

• What to do when your team is below senior individual contributor level,
• What to do when you’re at an engineering-driven company, versus design or user-driven, and
• What to do when you’re at a mid-sized B2B company, as opposed to a direct-to-consumer.

In the Beginning: An Accessibility Team of One

Sim talks about her experience as the first accessibility subject matter expert (SME) at Splunk.

Sim: When I started at Splunk, I was unfamiliar with the product suite and had never used the product. Not only did I have to learn how to use it, but also map out an accessibility plan for it. Utilizing tools I was already familiar with such as JIRA and Confluence, I evaluated existing test cases, then applied testing for the whole product suite. This process provided me with a complete accessibility analysis report for the product.

After reviewing this report, I realized that these test cases looked great in terms of functional testing but they were missing the a11y basics, such as WCAG best practices. I went ahead and started implementing WCAG 2.1 success criteria into the test cases for all future testing needs and purposes. Through JIRA, I was also able to pull status reports for all the existing open JIRA bugs which helped me analyze how most of these bugs were missing accessibility requirements. I then thoroughly reviewed the severities for existing bugs and went ahead assigning or changing severities as needed. Lastly, I decided to review the available Voluntary Product Accessibility Templates (VPATs) for our products to help me understand the products’ current compliance level and suggest changes for the template.

While I was working on all of these things, I heard that the design team was planning to onboard a full-time accessibility designer. I can’t tell you how excited I was to hear this news – while I was on a QA team, I hadn’t had a chance to work consistently with a designer.

Scaling Accessibility: Educating Employees and Building a Network

Alexis, previously a UX Designer at Splunk, is presented with a new opportunity.

Alexis: In September 2019, my head of design pulled me into a conference room where he posed a question: “How would you like to think of diversity and inclusion beyond race, gender, and sexual orientation?” He said that he had seen my work in employee resource groups (ERGs) and talks I had done on diversity, equity, and inclusion, and based on that, I would be the perfect fit for an Accessibility Designer role. I responded with “hell yeah!” and began ramping up. In February 2020, our team of one became a team of two. Crucial for us as individual contributors was scaling our work: how could we advocate for accessibility within a 6,000 person company, let alone raise awareness that two people were now here to support accessibility best practices and measures?

We decided to take a dual approach in advocacy: while working together on strategy and benchmarking, Sim and I also focused on our own spheres of influence. On the design side, I knew it was important to focus on educating myself as the “accessibility subject matter expert ” and to pass this information to the rest of my organization in a digestible format. I started A11y Hour, a monthly series on topics covering anything and everything accessibility. At first, the topics were dictated by Sim and myself. Later on, we found that there was enough traction to take audience requests. On the QA side, Sim utilized the education I created to emphasize how important SLAs and a remediation process was for engineers. We also emphasized that our customers, more so than us, were raising a11y concerns due to most B2B organizations’ requirement to analyze a product’s compliance level prior to purchase.

More than anything, being a team of two set the precedent at Splunk that web accessibility is a shared responsibility between designers and engineers, something that had been missed until now.

Measuring and Benchmarking

Sim: While performing our day-to-day responsibilities, we were setting the foundation to Splunk’s web accessibility program for current and future employees. After initial research, we still had many unanswered questions, such as:

• How many accessibility tickets do we have? What was the rate of closing a11y tickets versus opening?
• What was a portfolio-wide benchmark we could establish for a11y? Splunk has nearly 10 core products and multiple acquisitions over the past years, making this a tough question to answer.
• Prior to us, had any accessibility work been done in the past? If yes, who worked on it and how did they scope it? We knew the background for a few of our products, but there were still too many of them which we were not sure about.
• What customers, if any, have we lost in the past because of accessibility compliance?
• What percent of our time should we invest into a proactive approach versus the reactive approach for accessibility?

In our search, we communicated with different teams and cross-functional partners, which helped us build a network inside Splunk and create accessibility allies within the organization.

Building an Internal Network of Accessibility Allies

Alexis: One thing unique to our journey was Splunk’s Employee Resource Groups (ERGs), also known as a Business Resource Group (BRG) or affinity group. I had been co-leading the latinx Employee Resource Group for a year and knew the co-leads for disabled=true, an ERG that works to create an inclusive and accessible environment for current and future Splunkers who are disabled, suffer from chronic illness or pain. In June 2020, ERGs had listening sessions with company leadership. Having partnered with disabled=true to better understand the disabled user perspective, we were invited to their listening session, where in the list of suggestions, we saw more headcount for our a11y team. In addition, the ERG gave us space to express our truth about the struggles that we were having from not only a people and culture perspective with regards to accessibility, but programs and operations, as well.

One of the executives on the call was the Senior Vice President of Engineering, and after the call, he asked us to come into his leadership team meeting and present on the importance of accessibility. It took us a while to get over the initial shock, but afterward, we knew that this was a perfect opportunity that we couldn’t miss.

Making the Case for Practicing Accessibillilty to Executives

Sim: Over the next six weeks, we created a deck and started getting feedback from our network of internal accessibility champions. Important to us was tailoring the business case for accessibility based on our audience. As a designer, it’s pretty easy for Alexis to convince other designers that accessibility is the right thing to do; and, we knew it couldn’t be the only perspective to speak to our executive audience with. Brainstorming with our champions, we expanded our philosophy that we had to approach accessibility as something to practice to reduce legal risk, win more deals (especially as a B2B company considering federal acquisition regulation), and, when practiced through the product development life cycle, cost significantly less than remediating bugs post-launch.

In conjunction, our network of accessibility champions pushed us to do better with examples of good accessibility practices. Yes, we could highlight companies like Apple, Google, Airbnb, and Salesforce; yet, some of these companies were not even in our industry, let alone competitors. With this feedback, we found clear examples from competitors and at least products in the same marketplace.

Our last piece of feedback from our teammates was “show, not tell”, or that demonstrating a user experience with assistive technology was much more effective than just talking about it. In this case, we remembered a sales engineer who we recently worked with regarding a public-facing COVID-19 dashboard who had also given us a dollar value to the deal, which would resonate with our audience. I proposed to darken the screen and use JAWS on the dashboard. By taking the interface away, our audience was forced to listen to the exact same experience as screen reader users would have, as opposed to falling back on their sight. We produced a few more examples under this principle, focusing on highly visible and most frequently used pages.

Finally, the day in August came–and we received great feedback! The executives invited us to come back two weeks later with our gap analysis and proposal of how we were going to make a program. After this, we really had to think about how we wanted to transform accessibility into not just a checklist or a project, but a program.

Building an Accessibility Program From a Team of Two

Alexis: Prior to our presentation, we gained traction by reaching out to teams and asking to work with them; suddenly, the role was flipped; teams were engaging with us and wanted to be accessible ASAP. We quickly realized that we needed to build a process to track these requests and, in response, created an A11y Team Request form where teams could describe in what capacity they needed us, any upcoming deadlines, and whether it was related to a customer issue or not. This form also collected quantitative data so we could notice trends over time to identify needs within our own organization.

Sharing accessibility knowledge also became extremely important, as two people to 6,000+ employees isn’t scalable. In response, we created #a11y-questions on our company’s Slack. Instead of answering the same questions that were directly messaged to us, we could pin a visible response to any stakeholder as part of our FAQ.

While handling our overnight success, we noticed that the foundational resources we had built allowed us to further spread education for accessibility. For instance, the presentation we built out for executives was applied to new employee engineering boot camps. This onboarding effort ensures every employee starts with a bare minimum idea of what accessibility is and why it’s important to Splunk. The biggest win, however, was getting part-time resources from other Splunkers to do a weekly core accessibility team meeting. Together, we created long-needed documentation, including a Confluence page dedicated to accessibility. This page contains in progress and internally published RFPs, VPATs, benchmarks across product suites, and objectives key results (OKR) per quarter as a team that connects to the larger organization’s OKRs. Lastly, this page also collects stats around JIRA tickets so we can track remediation progress over time, what components to tackle first, and other needs.

Shift Left Approach to Accessibility

Sim: Having worked as a team for over a year now, we were finally seeing the rewards of a shift left approach to accessibility. Prior, I tested products before release and log bugs, which left little-to-no time for developers to fix reported issues. In having Alexis as an a11y design SME, many a11y bugs are caught at the design phase, making my downstream work easier. In addition, having a11y resources farther up the product development life cycle stream gave us an opportunity to interact with customers, sales engineers, and our field team to determine the most pressing issues.

Shifting left, more than anything, allowed us to take a more proactive approach to a11y with product workstream teams, versus purely remediative. Here’s how we’re helping our product workstream teams with a more proactive approach:

• Release design system documentation that contains a11y best practices and component-based documentation in case a developer needs to customize the component
• Establish a designer a11y toolkit that includes checklists specific to common workflows and non-technical resources for designers (Shout out to design intern Angela, who worked with Alexis to make this happen!)
• Integrate a11y best practices into acceptance criteria for product requirements such that it’s not on the product manager to memorize all guidelines
• Work with product teams to have a mix of live and online (captioned) workshops to learn more about a11y and why it’s important to Splunk.

Summary

• Accessibility is for our users and it’s advantageous to tailor the business case of accessibility to your stakeholder audience.
• Dividing challenges into people and culture vs. programs and operations can help identify pain points faster, determine what should be addressed in a proactive vs. reactive approach, and drive a strategy even if you’re under-resourced.
• Teamwork is critical for the large-scale effort that accessibility requires. Recognize when you’re at capacity and go outside your team for external help.

We want to also thank all of our mentors, past coworkers, and leadership that has contributed to the accessibility success at Splunk. We would not be where we are without you.

Are you a team or one or two working on a11y? Reach out to Sim on LinkedIn or Alexis on Twitter; the conversations we’ve had since delivering this talk at axe-con have been fantastic and while we know it can be daunting to be on a small team, know that you’re not alone and the a11y community is here to help.