[a11y] add initial accessibility functional tests#43584
[a11y] add initial accessibility functional tests#43584spalger merged 34 commits intoelastic:masterfrom
Conversation
|
Pinging @elastic/kibana-operations |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…y-functional-tests
This comment has been minimized.
This comment has been minimized.
|
@spalger Does it make sense having those as a completely separate config? Wouldn’t it be better if we could use that a11y testing function anywhere in any other functional test. That way we wouldn’t need to setup different test paths to get to a specific page just to a11y test it, but just use the regular e.g. discover test suite that brings us anyway to e.g. the context view and then just quickly a11y test this with one call? |
This comment has been minimized.
This comment has been minimized.
|
jenkins test this please |
|
|
||
| checks-reporter-with-killswitch "Kibana accessibility tests" \ | ||
| node scripts/functional_tests \ | ||
| --debug --bail \ |
There was a problem hiding this comment.
Should we remove --bail? We can get all the failures at once otherwise.
CC @dmlemeshko
|
I can't push into your branch so here's a patch of the changes to fix the Discover changes. (Change Not super sure what's going on with the login page... CC @bhavyarm |
This comment has been minimized.
This comment has been minimized.
I'm not opposed to exposing the a11y service to other tests, I just think it would be nice to have the tests isolated for now and maybe merge them later. Ideally most of the setup/navigation logic will be shared with the functional config anyway so that we can merge them later if we like pretty easily. Or maybe we just always have accessibility tests sprinkled about as well as a clump of a11y tests isolated just for easy of development... 🤷♂ either works for me. |
…y-functional-tests # Conflicts: # .ci/jobs.yml # .ci/run.sh # package.json
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…y-functional-tests # Conflicts: # .ci/jobs.yml # .ci/run.sh
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
💔 Build Failed |
|
Retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
1 similar comment
|
retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
retest |
💚 Build Succeeded |
|
@spalger That's 10 green builds! |
|
Huzzah! |
* [a11y] add initial accessibility functional tests * add accessibility jobs * fix config path * remove percy setup from scripts * disable color-contrast rule * apply changes from @myasonik * define aria-controls/owns props even when suggestions aren't visible * [ftr/a11y] only throw error when there are errors * adding tests for management page * add a11y test for management page * adding ignore rules' to a11y * accessibility test for kibana home * 7 passing tests, 0 failures * jest snapshot update * support a11y test in pipeline job * update a11y test script for pipelines * use oss compatible ci setup * fix exclude syntax * add default exclusion syntax
|
7.x/7.6: 9a6724c |
Fixes #43016
In an effort to start doing automated a11y testing in Kibana, this implements to FTR configs, one for OSS and one for X-Pack that both start Kibana and test a single view against the
wcag2aandwcag2aarule sets. This is mostly for the purpose of testing reporting/rules, and see how we want to proceed.