Easier pipeline integration
Scaling accessibility requires that you build it directly into the development process. But it’s tough to ask engineers to add accessibility tests directly into their builds, since each change in the project code requires updating the accessibility test as well. And doing accessibility tests after a release leaves the problems in place and the company exposed.
What Evinced offers is a middle ground: engineers can simply make a single call to Evinced from inside their builds and Evinced will ride along during each functional test. Once added as a dependency, all your engineers need to do start is type ev.Start().
167 times easier
Using a typical tool like Axe or Lighthouse requires the insertion of accessibility testing code manually into EVERY single functional test. If you have 10,000 tests, that’s 10,000 manual insertions. If you add a new test, or even edit an existing test, that’s another instance where you must add an accessibility test declaration.
By contrast, Evinced is declared once in your framework, with just three lines of code. It automagically runs alongside all your functional tests, even those you add or edit later.
Whether one test or 10,000, Evinced is the same three lines of code.
More ways we’re easy
Write once, test forever
Let’s say you’ve configured a functional test to check to make sure that a meeting request can be submitted on your website.
With traditional accessibility tools, you’ll have to develop that test for each permutation on the web page — every DOM mutation. And if you should make a change? You’ll have to write new tests all over again.
Evinced is dramatically easier. Once it’ set to run, it handles testing for every DOM mutation, and even automatically adjusts as you make changes.
Configure Evinced to test the entire page, or focus on specific components.
Configure which rules to run, whether and when you want to fail a build based on its accessibility results. You can even configure which kinds of accessibility errors will fail a build.
Decide how you want to the output to be displayed, including with CI systems like Jenkins, CircleCI, etc., and with a broad range of output formats, from JSON and JUnit to CSV.
Runs where you need it
Or, initialize the SDK from your application’s main entry point for testing dev, staging, or qa builds.