Accessibility Advocacy Takeaways from Humu

Set a Baseline

Before anything, it is important to establish awareness that different users have different abilities and that these differences can affect the web browsing experience. Without establishing this, your team might not understand why you were asking them to do certain things (and may not do them as a result). In my experience, when a company has no accessibility program, the lack of accessibility stems from a lack of disability awareness rather than willful neglect. Once they know about an issue, most engineers are happy to make changes so the resulting feature can be more accommodating.

Introducing people to accessibility one by one is not particularly efficient, so if there is an avenue for presenting on accessibility, take it. You can uniformly set a baseline for accessibility through an introductory presentation that covers the above topics in addition to how to test, tools for catching usability issues, and common ways products can come up short (like the classic alt-text/button examples). You can also share the related slides and meeting recordings so they can be viewed asynchronously. This is what my fellow engineer, Andres Sanchez, and I did in March 2022, and then once again in June after we had significantly increased our team size.

Make Learning Easy

There are other ways to share information outside of presentations. Ultimately, you want to make it as easy as possible to find and apply knowledge.

At Humu, I created an accessibility drive and training materials and referenced some of these materials in widely used documents. For example, Humu’s quality assurance (QA) process (known at Humu as ‘bug-bashing’) not only contained an explanation on how to bug-bash with the screenreader and keyboard but also linked to the longer and more in-depth videos. I also included practices that would address common accessibility issues in a style guideline document, which is something that one of our most tenured engineers, Kat Slump, suggested.

(Engineering specific) Another place to distribute knowledge is directly in the code as comments. Some reusable components need to be composed a certain way, and you want to call this out to teammates. An example of this would be mentioning that a tooltip trigger needs to be a button so non-mouse/trackpad users are able to interact with it. Also, you may find that the codebase has 3 different tooltips, but only one of those tooltips is accessible. You could also prefix the inaccessible tooltips’ names with ‘deprecated’, and at the top of the files note the reasons why the tooltip from a certain library is preferred.

(Engineering specific) You can also share knowledge within pull request reviews. Sometimes a bit of code may need just an additional attribute to make it more perceivable or navigable. When this happens, it’s useful to write out the exact change required so that the author of the pull request can directly apply this comment. Explain why you’re suggesting the change and how it is improving the experience for users so the author will remember the suggestion in the future. It also saves time and can prevent confusion and frustration when the original author does not have the knowledge to fix the issue and feels the need to investigate further to correctly apply review suggestions as a result.

Tickets can also be a place to call out features that were already released that need work, the reasons behind it, and the potential approaches for it. This is useful for granular, one-and-done tickets. In these tickets, I generally included the following:

• What the desired behavior was
• What the current behavior was and how it may have been under-serving users
• What a potential approach could have been to address it
• The particular Web Content Accessibility Guidelines (WCAG) success criterion that had more information on the particular issue
• A label tagging it as an accessibility (“a11y”) issue so that we could easily find all of the accessibility issues

Create Communities For Learning

There are a lot of considerations to take into account while creating an accessible product, and not all of them were captured in the Humu documents. Luckily, we had different places available for the team to seek out additional help.

Andres Sanchez, the engineer mentioned earlier, created a Slack channel dedicated to accessibility which became a key safe place for anyone to ask questions or share knowledge in the flow of work. It also generally became the hub for us to share resources, interesting news, or tools.

We also had multiple office hours throughout the week for those who might need help with implementing inclusive experiences. This is an idea that I got from a former coworker at Hello Alice, Marianne Masculino Bethel, that worked well at Humu too.

If you create enough opportunities and spaces for learning, eventually making an inaccessible product becomes harder and harder.

Share Your Favorite Resources

Not all content needs to be custom! For those who are interested in learning more about web accessibility beyond our organization’s context, I like to share the following resources (which are mostly specifications):

• Google's Intro to Accessibility
• A11ycasts with Rob Dodson
• Mozilla Foundations's HTML elements reference
• HyperText Markup Language (HTML)
• World Wide Web Consortium (W3C)'s Accessibility Standards Overview
• Accessible Rich Internet Applications (ARIA) Standards

Cheers for Peers

That said, I’m not done shouting people out. There are both more people I want to honor, and people I want to honor more:

Autumn Coyle , the senior designer at Humu, who was and is still an invaluable advocate. She cared deeply about accessibility, and it was apparent even to me as a person who never worked on a feature project with her. She always promptly and thoughtfully answer any questions I had on her desired keyboard and screenreader flows. She also organized a monthly design and engineering collaboration session. Autumn and I would share with each other our findings on some global components that we had in our system, the pattern it most resembled, and how to make it more inclusive for all. The results of these meetings were decision documents and detailed tickets.

Andres Sanchez (again), who on top of calling out every accessibility issue he found (and fixing many of them) and creating the #a11y Slack channel at Humu, also had an amazing ability to identify opportunities for us to work on and promote accessibility items. Just one example of this is when we had an internal tools hackathon in early 2022 (potentially even before then). There were already suggestions of what to work on but making the product more accessible was not one of them. He immediately suggested that we team up and work on that, and also spread the word regarding this work at Humu’s recurring Demo Day (a meeting where people would share what they had been working on).

Trevor Biller and Michael An, two engineers who encouraged my accessibility feedback when I had felt most discouraged. This meant a lot to me as it was after the time that I had been publicly told that accessibility was not a priority. This had given me the signal that Humu’s values and my values did not align. When they expressed that they found these reviews useful, it showed me that there were others who cared about inclusivity and equity. If not for their comments, I might have eventually returned to my previous company and the engineering side of this work would not have been done, or at least until Vincent joined in March, which leads us to…

Vincent Colavin (again), who in addition to hosting office hours, configured our Ladle (a component library/playground) to show accessibility errors in our components so we could address them earlier in the development process.

Efrain Ferrer, a designer who volunteered to become an office hour host when I first announced that Vincent and Jason were joining the office hours roster.

Sophie Alpert, the VP of Engineering, for many reasons. She gave me tons of advice, like sharing a bit of the history of accessibility at Humu, refining my strategy on choosing which pages we should focus on auditing first, and also suggesting practices that fell within the norms of Humu, as well as being another resource for accessibility. She also cultivated and maintained a culture where sharing information was easy and expected. It was incredibly easy getting the first accessibility presentation on the engineering team’s calendar because of how we would essentially have biweekly lunch-and-learns. I have difficulty asking for things so this was one less stressor in my life.

Diana Viglucci, who I already mentioned as being the current steward of the accessibility documents and strategy. I also wanted to highlight their contributions before that. For context, most of the engineers who had prior accessibility experience were on a different team (Vincent, Jason, and myself with Kevin as our manager). Diana became their team’s accessibility expert, and it was exciting not just seeing the accessibility work they were doing via their pull requests, but also hearing about the presentations they were giving on the work that has been done for their team’s newest features.

Eric Robinson, who eventually became my team’s product manager and made certain process changes frictionless. I am so used to hearing no, that the thought of asking to do things cause me more stress than actually doing the thing. This is why I am so grateful to Eric for breezily saying yes when I wanted to introduce processes related to accessibility.

Will Doolittle, who made a requirement that the latest features needed to meet WCAG A compliance. This was a huge win and finally solidified accessibility as a priority at Humu.

Miriam Connor, who also encouraged and supported my mission in public and private settings, and always advocated doing the right thing when the topic of speed versus equity for all came up.

Kevin Ball (again), who helped me in a lot of ways beyond what I had mentioned in the earlier sections. He always had a way of finding exactly who to also best talk to about certain situations, presented the perfect frameworks for different issues, and offered me a wealth of valuable insights.

And again, anyone who ever called out any sort of accessibility issue or asked or answered clarifying questions on accessibility. This includes essentially everyone who has been mentioned so far, but I am sure there were more.

I do want to also thank two people whose work or influence I would come across though our times at Humu never overlapped. The first person is Robbie Tillieard, who created an accessibility goal document, which gave me an idea of where Humu was in terms of vision. The second person is Carlos Lopez, an engineer who left about a year before I joined. Most of the time I was pleasantly surprised by something in the code base (usually even the presence and correct usage of ARIA attributes), it was Carlos’s doing.

Finally, I would not have been able to play the part I did when working at Humu without the support I had received at the place I worked prior, Hello Alice. Thank you, Jillian Fortin Burtnett, my mentor in accessibility, and Kelsey Ruger, my previous boss who gave me the resources, space, and confidence to learn and apply those learnings.