Request demo
Try it now

Additional information

What assistive technology do you test with to review accessibility of your product(s)?

While a large percentage of our accessibility testing is manual, we use a combination of tools — like Lighthouse, Siteimprove Accessibility Checker, and axe —  to review accessibility in the Collective. We’ve also started incorporating VoiceOver and NVDA screen reader and keyboard accessibility as part of our testing.

Do you test your software with actual users with different abilities?

Empathy for users is part of our culture. We build empathy through continuing education and professional development opportunities (e.g., attendance at conferences, use of altered vision glasses) so that when we design, develop, and test features, we’re always considering accessibility. While we currently don’t yet test with users with different abilities, we hope to include that into our process in the future.

How do you account for accessibility in your policies and practices, and how do you track and prioritize accessibility issues?

With support from our leadership team, we have a cross-functional team of developers, quality assurance (QA) test engineers, user experience designers, and product managers devoted to making the Collective fully accessible. During bi-monthly accessibility sessions, any Widen employee can participate in hands-on activities with vision simulation glasses to walk through several scenarios using a variety of accommodations on the screen. Sessions have shown us where we can improve and where we’ve been successful.

Our developers and QA test engineers use a combination of automated tests, unit tests, and manual testing using keyboard tabbing and screen readers, along with the assistive technology tools described above, to ensure the Collective is accessible.

We’ve set an engineering standard that all software that’s developed meet a Lighthouse score of 100%. Currently, most development projects incorporate the automated running of Lighthouse in the build process.

When an accessibility issue is found, a ticket is created, then prioritized for work. We have a reusable component library, of which many components are accessible, and new features that are developed use the components from the library. If we update a component, the update is then available for other teams to use.