Having worked closely with Selenium for the past 7 years, I love the idea of getting as much value from functional UI tests as possible.<\/p>\n\n\n\n
One way to do that is to add accessibility testing, as well. This allows us to shift a11y testing left discovering issues earlier when they are faster, easier, and cheaper to fix. Add to this the power of the Sauce Labs Selenium grid with its instant scalability and actionable test insights and we have a solution that will help us dramatically improve end user experience for everyone.<\/p>\n\n\n\n
The advantages of the Evinced Selenium SDK over other accessibility tools are two fold. First, there is no need alter individual test code!! <\/p>\n\n\n\n
(Go ahead and read that again.)<\/p>\n\n\n\n
Anyone that has used other a11y Selenium integrations understands the pain of having to add an accessibility scan after every interaction with the page that causes a significant DOM shift. An end to end test might have 10+ scans! Not only does this cause continual maintenance and reliability issues, but every time you add a scan to a test it creates a report that must be managed. This means organizing dozens of reports and wasting time with a mess of duplicate issues. Evinced provides a single detailed report at the conclusion of your tests with all the details you need to understand the issues and fix them quickly.<\/p>\n\n\n\n
Additionally, unlike other tools that rely on syntax analysis, our Automation SDK for Selenium uses computer vision to model the UX intent and actions to the actual implantation. This approach allows Evinced to find more critical accessibility issues that were once only found with manual testing.<\/p>\n\n\n\n
In this post we will discuss how easy it is to take an existing Selenium test built to run on Sauce Labs and add the Evinced accessibility scanner to pinpoint accessibility issues along the way.<\/p>\n\n\n\n
So, let\u2019s take a look at our Sauce Labs example test:<\/p>\n\n\n\n