利贯配资_在线配资炒股

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 . Our goal is to have all Widen Collective® apps meet accessibility standards and maintain continuous compliance with Web Content Accessibility Guidelines (WCAG) 2.1 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 jxcgxx.com, such as closed captions and more descriptive alt text. 90% Google Lighthouse accessibility score becomes a Widen development standard., 2019: Widen Accessibility team is formed, Navigation is updated on jxcgxx.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 starts to evaluate accessibility criteria in applications. Using VPATs (Voluntary product accessibility templates). These follow the WCGA 2.1 guidelines and give users and potential users of the software the needed context of where we are at in our compliance journey. VPATs are self-accessed and help us generate areas for improvement., Widen works with organizations for the blind and visually impaired to offer employee learning opportunities, 2021: Made our VPAT documentation public, so buyers and users can see the a11y status of our applications today; and understand where we are going to continue to elevate our experiences. Joined Acquia and have begun strategizing our company-wide accessibility program., 2022: Widen launches our accessibility focused documentation to our patterns project, enabling development teams to more easily create fully accessible experiences out of the gate., 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 jxcgxx.com, such as closed captions and more descriptive alt text. 90% Google Lighthouse accessibility score becomes a Widen development standard., 2019: Widen Accessibility team is formed, Navigation is updated on jxcgxx.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 starts to evaluate accessibility criteria in applications. Using VPATs (Voluntary product accessibility templates). These follow the WCGA 2.1 guidelines and give users and potential users of the software the needed context of where we are at in our compliance journey. VPATs are self-accessed and help us generate areas for improvement., Widen works with organizations for the blind and visually impaired to offer employee learning opportunities, 2021: Made our VPAT documentation public, so buyers and users can see the a11y status of our applications today; and understand where we are going to continue to elevate our experiences. Joined Acquia and have begun strategizing our company-wide accessibility program., 2022: Widen launches our accessibility focused documentation to our patterns project, enabling development teams to more easily create fully accessible experiences out of the gate., 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 incorporated VoiceOver and keyboard accessibility as part of our testing and are looking to incorporate NVDA for screen reading.

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 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 automated end-to-end tests and unit tests for accessibility test coverage that run during our build processes. 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.