Request demo
Try it now

Accessibility

In a diverse world, not all users interact with software the same way. To ensure we meet the needs of all users, Widen strives to design and develop our tools in accordance with web accessibility standards.

 

Our journey

As part of our journey to full compliance, accessibility is prominent in all user experience and development conversations for new software and updates to current functionality. Additionally, we incorporate accessibility exercises into onboarding training to begin building empathy and awareness from day one.

Accessibility progress and compliance is regularly measured using various audit tools including Google Lighthouse. Our goal is to have all Widen Collective® apps meet accessibility standards and maintain continuous compliance with Web Content Accessibility Guidelines (WCAG) 2.0 AA.

accessibility graphic circles overlapping

Accessibility and Widen

1996: First web interface is designed, 1998: Section 508 is added to the Rehabilitation Act, 2008: WCAG 2.0 is published, 2016: Widen UX team is formed, 2018: Widen Marketing team begins adding accessibility features to widen.com, such as closed captions and more descriptive alt text, 2019: Widen Accessibility team is formed, Navigation is updated on widen.com and user tests are performed on web updates, 100% Google Lighthouse accessibility score becomes a Widen development standard, Accessibility training sessions added to onboarding for all new Widen Employees, 2020: Widen works with organizations for the blind and visually impaired to offer employee learning opportunities, Future: More improvements and learning to come...
1996: First web interface is designed, 1998: Section 508 is added to the Rehabilitation Act, 2008: WCAG 2.0 is published, 2016: Widen UX team is formed, 2018: Widen Marketing team begins adding accessibility features to widen.com, such as closed captions and more descriptive alt text, 2019: Widen Accessibility team is formed, Navigation is updated on widen.com and user tests are performed on web updates, 100% Google Lighthouse accessibility score becomes a Widen development standard, Accessibility training sessions added to onboarding for all new Widen Employees, 2020: Widen works with organizations for the blind and visually impaired to offer employee learning opportunities, Future: More improvements and learning to come...

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.