The current state of accessibility for HEY, and future plans.

The HEY of today represents a “version 1” culmination of two years of effort. It is far from complete. We know there are many areas in which we can make the software better and fully inclusive — especially in terms of accessibility. HEY currently does not meet the requirements of fully accessible software. We have full WCAG AA 2.1 compliance as our target and commit to improving HEY until we get there.

First principles

• It should be easy to get around. We offer keyboard-based shortcuts to navigate throughout HEY and structure the app’s layout with function in mind.
• We design with legibility at the forefront. HEY uses easy-to-read fonts and we prioritize high contrast in our designs.
• Accessibility is a constant requirement. We’re never “done” working on the accessibility of HEY.

Current accessibility review process

At Basecamp, our Accessibility Lead is also our Quality Assurance Lead, Michael Berger. Michael works with a team at Aspiritech to to test every new feature and workflow before it is shipped. Michael has also developed — and continues to maintain — an internal Accessibility Handbook as a resource for designers.

The following outlines some of the ways we review the accessibility of new features and flows:

• We begin with a general usability scan. For this step, we use browser extensions such as axe, reviewing on both desktop and mobile viewports.
• We check for visible indicators of focus for every focusable element on a page.
• We check that headings do not skip levels, such that they give an overview of the structure of a page.
• We check color contrast with the aim of passing at least WCAG 2 level AA standards.
• We hide decorative elements from assistive technology. We work to hide visual elements that are repetitive or purely decorative from the accessibility tree.
• We provide a “skip to main content” link at the top of each page so users can skip repetitive navigation links.
• We test that everything works with keyboard navigation, ensuring that a mouse isn't required for performing any action throughout the product.
• We test views with a screen reader. Currently, we test across the following screen readers and platforms:
  • On macOS we test VoiceOver in Safari (latest) and the HEY Mac app.
  • On Windows we test NVDA in Firefox (latest) and the HEY Windows app, and also test JAWS in Firefox (latest).
  • On iOS, we test VoiceOver in mobile Safari and the HEY app
  • On Android, we test Talkback in mobile Chrome and the HEY app

Future plans for accessibility improvements

• Ongoing work: we will continue to fix our backlog of documented a11y issues, adding new issues as we discover them.
• VPAT: we will publish our first voluntary product accessibility template in the coming months, and will update it on a quarterly basis, if not more frequently.
• External auditing: we commit to hiring external WCAG 2.1 AA compliance auditors on a periodic basis to help us catch what we’ve missed.
• Process improvements:
  • In the future we will begin a formal user research program centered on customers who live with disabilities to further inform our accessibility reviews and product design.
  • We would like to add an additional automated layer of accessibility testing into our build pipelines.

Feedback and support

If you have suggestions or would like to share accessibility concerns you have with HEY, please reach out to us at accessibility@hey.com.