How We Do Accessible Design and Engineering at HashiCorp

In recognition of Global Accessibility Awareness Day (GAAD) two HashiCorp engineers sat down to discuss accessible design and engineering at HashiCorp. Their conversation captures the perspectives of UI infrastructure engineer and product engineer:

Melanie Sumner: I guess we should start by introducing ourselves: I’m Melanie Sumner, a senior software engineer on the Design System Team. My specialty is digital accessibility. I also lead accessibility (a11y) initiatives for the Ember.js Framework Core Team, and am an invited expert for the W3C’s WAI-ARIA working group and co-editor of the Accessible Name specification.

Jamie White: Quite the résumé! I’m a staff engineer on the Waypoint UI team. I focus on enabling our team to build delightful, accessible interfaces that help everyone use Waypoint to its full potential. I’ve been involved with Ember.js for longer than I care to remember and, in that time, I’ve been lucky enough to collaborate with Melanie on numerous a11y initiatives.

Let’s start by talking about your work on the design system. Something I’ve been impressed and influenced by is the way accessibility informs the evolution of the design system. How do you and your team think about that?

Melanie: That’s a great question. Two of HashiCorp’s principles are pragmatism and kindness; they form a great foundation for an accessibility strategy. It’s easy to want to do everything, especially on a new project, and these principles helped us strategically hone our focus. Of course, hearing our CTO and Co-Founder Armon Dadgar talk about the importance of accessibility to our company definitely empowered us to adopt a strategic approach.

It’s a known hard problem to build complex, technical products for the modern web that are accessible and delightful to use. For me, it’s thrilling to help make this happen for HashiCorp products.

Jamie: As an engineer working on a product UI, I feel those principles coming through as we use the design system and figure out what we want it to do for us in the future.

As an example, one time I reached out to you to talk about tabular UIs. I was expecting you to tell me the design system team was working on the one table component to rule them all, but instead you helped me see that there are many patterns for tabular data and data grids and the way they suit different users’ needs. You told me that it was absolutely fine for our tabular UI to have some unique characteristics as long as it made full use of the platform to provide a great, accessible experience.

Something else that struck me during that conversation was how excited you are about the web platform and how much it gives us by default. What else excites you about the current state of web UI engineering?

Melanie: I am always amazed at how much we get from the browser by default. Right now, I am excited about the potential for automation in accessibility; I’ve talked about the potential for Continuous Accessibility and built the A11y Automation website as a side project to track progress being made in a11y-related automation tooling. The most efficient way to craft software is to detect issues as early as possible; automation is a key part of that, so improvements in automated accessibility tooling are the future of the web.

That said, what tools do you use while developing the Waypoint app?

Jamie: We use a combination of static analysis and runtime analysis.

For static analysis, we use ember-template-lint, a wonderful tool that analyzes the templates for our components and pages. It performs a suite of different checks, some of which relate to “best practices”, some to security. My favorites focus on accessibility: ember-template-lint can be run as part of the test suite, as a pre-commit hook, as a CI check, and can also integrate with your editor of choice. That last part is the best bit — as a developer, the moment I type out some inaccessible HTML, I see a red squiggly with an informative message that tells me why I should consider a different approach. It keeps me from making avoidable accessibility mistakes and educates me at the same time.

Melanie: I love using ember-template-lint; its initiatives to add new accessibility-related rules continue, and the tool just keeps getting better. I think it’s a great way to “shift left” and detect issues as early as possible. I mean, it gives you accessibility hints while you are actually writing your code! That’s amazing to me, especially when I think back to the days when you had to wait for an audit to give you a list of things to fix.

Another amazing feature is that ember-template-lint lets you continually implement new accessibility-related linting rules — the linter runs the new rules on existing code, and also creates “to-do” items that your team can plan to incrementally fix. Any new code is immediately subject to the newly added linting rule, preventing issues in your code. This helps you handle the code you already have, the code you’re writing now, and the code you’ll write in the future.

But what about dynamic analysis? What do you use for that?

Jamie: For dynamic analysis, we use ember-a11y-testing, another great tool that automatically integrates axe-core into our test suite. At every step in every test, axe-core runs against the webpage and fails the test if it detects an accessibility issue. Just like ember-template-lint, the real beauty is the error message — it tells you exactly which elements are causing the issue and links to dequeuniversity.com where you can read a detailed explanation of the issue, the effect it can have on users, and how to fix it. axe-core, in case you’re not familiar, is the industry-standard accessibility testing tool, powering Chrome’s Lighthouse check, Microsoft’s Accessibility Insights, and many other tools.

Melanie: You’ve just highlighted something really important: HashiCorp is just one part of a massive effort to improve web accessibility. The community of technologists who are thinking about accessibility is growing fast, demonstrated by the existence of Global Accessibility Awareness Day, Inclusive Design 24, and the increase of tooling created by individual contributors, such as the Colorblindness Emulator by Agathe Badia.

Jamie: Yeah, there’s an incredible community of folks supporting accessibility. Shout out to Inclusive Design 24’s organizer, Lèonie Watson, one of my all-time professional heroes.

Another interesting accessibility trend lies at the intersection of design and development tooling. Design tools like Figma and Sketch are now so much more aware of the target platform, and that opens the door to fully describing the accessibility characteristics of UI at the design stage. Just look at the list of accessibility plugins for Figma!

I’m hopeful that the combination of principles, tools, and community is leading us not only to greater a11y literacy, but also greater empathy not just for users from all walks of life, but also for each other in how we design and build these products.

Melanie: I agree! As we like to say, it takes passion, patience, and persistence to travel this accessibility journey.

The views expressed on this blog are those of the author(s) and do not necessarily reflect the views of HashiCorp.