What Accessibility means at Hootsuite
Introduction
In recognition of Global Accessibility Awareness Day (GAAD) it’s worth taking some time to reflect on the work that our Development, Design, and Product teams have been shipping over the past few months.
Since mid-February 2023, we’ve had a renewed focus on improving the accessibility of Hootsuite and the Hootsuite mobile app. We have Six Guiding Principles at Hootsuite — including Step Up — show the world what it looks like to live and work by these guiding principles.
Note – all the bold text is one our of six principles.
Well, it’s time for us to do just that. Creating a diverse, inclusive, results-oriented culture requires that we make Hootsuite a place where we all — customers and employees alike — feel safe, welcomed, valued, and empowered to do our best work together without compromising who we are.
Being Customer Obsessed, as One Team with a focus on being a good Neighbor and Ally, means delivering a product that all of our customers can use — regardless of their abilities, understanding what it means to be inclusive and universal in our outlook, and how we design and build for all our customers. We decided to show up, Go Fast, Be Agile, and Play to Win in understanding how we could break down barriers to using Hootsuite.
Learning & Education
As part of our plan to improve accessibility, we began by setting aside two days for learning about accessibility. This was planned to ensure we could build empathy and understand how differing abilities lead to different experiences when using web and mobile apps.
The resources each person used very much depended on their role and the team they were in — this included Designers, Developers, Development Managers, and Product Managers. Some of the resources we used included:
- Udacity Accessibility Course — https://www.udacity.com/course/web-accessibility--ud891
- Google Web Accessibility — https://web.dev/learn/accessibility/
- iOS Accessibility — https://developer.apple.com/accessibility/
- Android Accessibility — https://developer.android.com/courses/pathways/make-your-android-app-accessible
Accessibility Audits
We’ve been working with our friends at Level Access to complete audits across our Hootsuite products to ensure that we have a thorough understanding of the accessibility issues that affect our users. They’ve been a key part of our success to date, and we’d highly recommend them if you’re considering improving the accessibility of your product too.
We provided a test plan to Level Access, so they were aware of what needed to be tested for accessibility issues. Level Access provided a team of auditors to deep dive into each area of our Hootsuite products and create a collection of reports of the outstanding issues to be fixed. Our next step was to distribute these reports across our development teams to spread the workload to the teams with key product knowledge.
Since we’ve come together as a wide group of peeps to address the accessibility issues throughout Hootsuite, we thought it would be useful to let some our Accessibility Champions (read on to learn what they are!) share what they’ve been working on, and how they’ve worked together to greatly improve Hootsuite’s approach to accessibility.
Making New Product Features with Accessibility in mind
It’s worthwhile noting an accessibility improvement we’ve recently added to OwlyWriter AI this week. It’s easy to think that accessibility improvements only affect the usability of the platform, however, here at Hootsuite, we’re all about helping our customers put their best foot forward on social.
With OwlyWriter AI, we’ve shipped the ability to generate simplified captions for the text of a complex topic. Once a user enters the text they intend to post on social media, they submit it to OwlyWriter AI which replaces the text with easier to understand words and sentences — making sure that the message can be more easily understood by a wider audience.
How we report to the wider company
Accessibility is a shared effort across multiple teams, organizations, and most importantly, people. How we communicate to the wider organization is a big part of showing up, and staying accountable.
While we engage with our leadership weekly on accessibility, we also recognize that accessibility is a proactive conversation that needs to happen at all levels. Externally to our Product and Development teams, we provide updates to the wider company on a monthly basis, while we provide updates to key customers on a quarterly basis to ensure they are aware of our commitments going forward.
Accessibility Champions
To reinforce our commitment to accessibility, teams self-appointed “Accessibility Champions” to have ownership of communicating updates, flagging any risks, and ultimately helping us keep the momentum going as we move forward with our accessibility initiatives. Our Accessibility Champions also work with each other to help solve any issues or questions other development teams may have, which has helped us build better best-practices across our business.
Our champions join stand-ups weekly, and are also key representatives in Slack channels. We maintain one channel for general #product-accessibility — open to all Hootsuite peeps, and another channel specific to Accessibility Champions to share their updates and any team-specific learnings.
These weekly updates roll up into our weekly leadership update, which then cascades out to the rest of the company. Our Accessibility Champions are deeply involved in accessibility themselves, and are truly at the forefront of accessibility and lead by example!
Designing for Accessibility
In Product Experience, we’re changing how we work to ensure our experiences and software are accessible. We use a variety of processes, tools, and systems to do this.
When we deliver designs to our development teams, we leverage Stephanie Hagadorn’s Accessibility Annotation Toolkit to help communicate the necessary specifications for accessible workflows. This set of Figma components provides us with a standardized way to highlight key design aspects such as ARIA labeling, tab order, and more. During our design process we also lean on tools such as Stark to test accessibility before we commit to building the feature.
Our systems help ensure that our efforts scale. We recently updated our help center templates to feature colors that deliver stronger contrast, which improved readability for all our articles. We’ve also been working on our Design System — the code components that are the building blocks of Hootsuite. Here, improvements in colors and focus states propagate through all our features automatically, ensuring that users of assistive technologies benefit from a fully accessible experience.
We recently appointed an accessibility champion in the design organization. We’re building design muscle by developing strong design ops, processes, and templates. And we continue to incorporate accessibility into our Design System to ensure all future releases are fully accessible to all our wonderful customers!
Automated testing with Sauce Labs / Grafana
Automated tests serve as an excellent counterpart to manual verification and assistive technology testing — such as screen reader testing. They offer advantages such as cost-effectiveness, ease of setup in our Continuous Integration and Continuous Deployment (CI/CD) pipelines, and consistent metrics. By integrating with cloud testing platforms like Sauce Labs, leveraging comma separated value (CSV) reports in Jenkins, and utilizing Grafana for tracking UI automation testing, the assessment of product accessibility became effortless.
Initially, we relied on Chrome plugins such as the Level Access Accessibility Checker and axe DevTools to complement our manual accessibility testing efforts. While these Chrome tools are user-friendly, they lack the ability to easily share reports, check historical data, and ensure consistent results. To address these limitations and establish a more consistent and independent approach with periodic checks, we decided to expand our UI automation stack (Jenkins/Nightwatch.js/Sauce Labs) to include accessibility testing.
To enhance our Nightwatch.js UI testing framework, we implemented a custom accessibility function integrated with ASLint, a free accessibility testing tool from Level Access. This integration incorporated accessibility testing into our regular UI test flow, allowing us to observe accessibility findings through the console log. We chose ASLint over Nightwatch’s native axe-core library because of the more detailed reports that ASLint offers, which can be customized to meet our specific requirements later in the test flows. Sauce Labs proved to be a valuable resource, providing references such as finding timelines when introducing new components to the UI. We leveraged these tools in Jenkins to set up scheduled daily test runs, enabling us to easily share accessibility reports across teams through the Jenkins report URL console.
We did notice that finding information through the Jenkins console was still not intuitive enough, particularly for teams and individuals who only wanted to download reports for specific pages or monitor accessibility trends over time. To address this, we improved our framework by automatically exporting accessibility test results to a CSV file using the json2csv package and attached all reports to Jenkins’ archive artifacts. To assist each team in tracking their accessibility trends, we upload each daily test result to a Grafana board using Prometheus. These metrics provide quick visibility for team members to identify quality changes related to accessibility resulting from shipping code changes. In the future, we plan to explore integrating a custom threshold-based Slack team channel alert to further enhance accessibility change awareness.
Automated testing can catch a high percentage of accessibility errors, and we have integrated a few different testing strategies into our existing pipelines. Using the Sauce Labs Visual Testing feature, we can accurately test at different font and zoom levels to ensure the design still works with larger text. Snapshot testing can catch things like color contrast, common image issues like alt text, decorative images and accessible svg. We run our snapshots at mobile and desktop sizes, ensuring our website is accessible at all screen sizes! Storybook has accessibility testing as a plugin, and we have added that into our workflow, ensuring at the component level, they are accessible.
Using cypress-axe, we have also integrated some end-to-end tests on large web pages, ensuring that the pages with our highest traffic are continuously being scanned and caught. Axe can help catch structural issues like heading hierarchy, which is important on a Content Management System website where there are always many headings!
Overall, our automated accessibility testing framework, combined with the integration of these tools, has improved our ability to ensure and monitor accessibility in our products.
Changes to our development workflows to include accessibility from the start
On the mobile team, we’ve worked on multiple initiatives to incorporate accessibility into our iOS and Android apps. These initiatives include: educating the team on accessibility requirements, integrating accessibility into our testing practices, and creating accessible components.
Our team members now complete accessibility onboarding before starting any project work. Our onboarding guides cover our motivation for accessibility work, Web Content Accessibility Guidelines (WCAG) guidelines and how they apply to mobile development, how to use accessibility tools like Talkback and VoiceOver, and development best practices.
Hootsuite customers find a lot of value in changing their font sizes — 30% of our customers use a font size other than the default size — so it is important to our team to have comprehensive tests to cover a range of font sizes. We use iOS snapshot tests and Android screenshot tests with different text size configurations to ensure our UI layouts are accessible in default and enlarged text sizes.
Below is an example of some snapshot tests for the iOS app in both text sizes:
These tests help us see that enlarged text is wrapping to multiple lines as expected. If, at some point, labels are changed, we can catch regressions with these tests and fix them.
Our Mobile QA developer also uses accessibility labels when creating UI automation tests with Appium. If the tests are able to successfully navigate the app and interact with UI elements using accessibility labels, then we know that our VoiceOver and Talkback users can use the app successfully as well!
Not only do we have education and test coverage, we’ve integrated accessibility into our app’s reusable components. This gives us accessibility “for free” in most cases and gives us peace of mind knowing that we have accessibility built in.
One example of a reusable, accessible component is our onboarding component. It’s built to scroll when text becomes larger and has accessibility traits for VoiceOver and TalkBack read out. Any onboarding components we create in the future can use this template and automatically inherit accessibility.
On the hootsuite.com marketing side, we begin by creating accessible content before we begin writing code. We have created accessibility onboarding documentation for the development teams to help them easily and effectively ramp up writing accessible code on our blog.
To help make our developer’s lives easier, we created a few “helpers” to assist with common accessibility issues. These include a component for visually hidden text (text that needs to be read by a screen reader but wouldn’t provide any value to a sighted user), and a function that would help announce new state changes to the screen reader (for example, when a form is submitted or has input errors).
When a developer creates a pull request using a template, we have links to Chrome extensions, as well as checklists to ensure they have manually tested for common accessibility issues, such as reviewing the changes using a screen reader, navigating through using the keyboard, etc.
Summary
That’s quite the update. In summary, we’ve moved the needle quite substantially to improve the usability of Hootsuite on the web and in the app, the hootsuite.com marketing website, and the Hootsuite help center.
We’re committed to continuing to improve the accessibility of Hootsuite over the coming months to ensure we deliver the best possible experience to our customers.
If you’ve found an issue with accessibility on any Hootsuite platform, please reach out to support@hootsuite.com and our team will be happy to look at the issues you’ve found.
Attribution note: This article was a collaborative effort between many amazing owls who share a passion for accessibility. I’d like to thank my co-authors Alex Stroulger, Ashley Gadd, Brit Ho, Chase Wen and Colby Garland for bringing this article together.
