Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate WCAG testing #1577

Merged
merged 20 commits into from
Oct 21, 2021
Merged

Automate WCAG testing #1577

merged 20 commits into from
Oct 21, 2021

Conversation

yen-tt
Copy link
Contributor

@yen-tt yen-tt commented Oct 19, 2021

  • add new Github Action to run WCAG tests on push or pull request to develop, hotfix, and support branches
    • will add this to generator-slapshot repo after pr approval
  • add pageNavigator, similar to theme's pageNavigator, which uses puppeteer API to automate browser navigation.
  • use axe-core/puppeteer library to generate WCAG report on each page, exit with error if there are violations
    • this library have license of type MPL-2.0 (reviewed and approved, for test environment only)

Note:

  • This pr does not include all possible ui components in the test yet, should make a new item/pr!
  • This pr does not address all violations listed in the report, should make a new item/pr!

J=SLAP-1634
TEST=manual/auto

  • run npm run wcag locally, and see that a wcag report is properly generated for each url, and listed out the violations to be addressed.
  • See that github action ran on this pr

Yen Truong and others added 2 commits October 19, 2021 12:49
- add new Github Action to run WCAG tests on push or pull request to develop, hotfix, and support branches
- add pageNavigator, similar to theme's pageNavigator, which uses puppeteer API to automate browser nagivation.
- use axe-core/puppeteer library to generate WCAG report on each page

J=SLAP-1634
TEST=manual/auto

- run 'npm run wcag' locally, and see that a wcag report is properly generated for each url, and listed out the violations to be addressed (should have another item(s) to do so)
- testing github action on this pr..
@coveralls
Copy link

coveralls commented Oct 19, 2021

Coverage Status

Coverage increased (+0.01%) to 61.223% when pulling 26559e9 on dev/automate-wcag-test into 383fb3d on develop.

.github/workflows/wcag_test.yml Outdated Show resolved Hide resolved
.github/workflows/wcag_test.yml Outdated Show resolved Hide resolved
tests/acceptance/wcag/index.js Show resolved Hide resolved
tests/acceptance/wcag/index.js Outdated Show resolved Hide resolved
tests/acceptance/wcag/pagenavigator.js Outdated Show resolved Hide resolved
@@ -0,0 +1,44 @@

/**
* Waits until the content of the page stops changing.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my own edification, the goto method does not wait until the DOM of the page is fully loaded? Instead of rolling our own wait here, could we use page.waitForNavigation()? It's referenced a couple places:

Copy link
Contributor Author

@yen-tt yen-tt Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, goto doesn't wait for content to be fully loaded. I think we tried that and with waitForNavigation/other waitFor approach before in theme and it didn't work well so we resolve it with our custom wait. I tested waitForNavigation out locally just now with different network and DOM content loaded options, it's always stuck on the first page.

@yen-tt yen-tt added the WIP Work in progress label Oct 19, 2021
@yen-tt yen-tt removed the WIP Work in progress label Oct 19, 2021
reporter: 'no-passes',
runOnly: {
type: 'tag',
values: ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag2aaa']
Copy link
Member

@cea2aj cea2aj Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would check with Rose, but I think currently we are only trying to meet WCAG AA compliance. (We can leave AAA in here for now, but when we go to address these concerns, we may want to bump down to just AA)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rose said Level AA for WCAG 2.0 and 2.1 should be good!

@cea2aj
Copy link
Member

cea2aj commented Oct 21, 2021

Maybe we should merge this PR into a feature branch rather than develop until we address the failures? If we merge into develop, every PR will fail to pass the tests

@tmeyer2115
Copy link
Collaborator

Maybe we should merge this PR into a feature branch rather than develop until we address the failures? If we merge into develop, every PR will fail to pass the tests

IMO, I would rather we merge this in now. Long-lived feature branches can become cumbersome. Merge conflicts can arise, etc. You have to constantly rebase. Especially here. If we don't rebase constantly, then the WCAG checks wouldn't catch any new failures added in develop. If possible, I think we should ensure that WCAG failures do not block the merging of a PR. They only register as warnings (if that's a thing). Once we are fully WCAG compliant, we can change it so that failure would block a PR.

@cea2aj
Copy link
Member

cea2aj commented Oct 21, 2021

Maybe we should merge this PR into a feature branch rather than develop until we address the failures? If we merge into develop, every PR will fail to pass the tests

IMO, I would rather we merge this in now. Long-lived feature branches can become cumbersome. Merge conflicts can arise, etc. You have to constantly rebase. Especially here. If we don't rebase constantly, then the WCAG checks wouldn't catch any new failures added in develop. If possible, I think we should ensure that WCAG failures do not block the merging of a PR. They only register as warnings (if that's a thing). Once we are fully WCAG compliant, we can change it so that failure would block a PR.

Makes sense. We'll just want to watch out for the boy who cried wolf so that we don't start ignoring tests because they are always failing. It doesn't look like warnings are a thing except for code annotations which probably isn't what we are looking for.

@yen-tt yen-tt merged commit c3ae4b7 into develop Oct 21, 2021
@yen-tt yen-tt deleted the dev/automate-wcag-test branch October 21, 2021 15:03
@nmanu1 nmanu1 mentioned this pull request Nov 16, 2021
nmanu1 added a commit that referenced this pull request Nov 16, 2021
## Version 1.12.0
### Features
- Allow search rate tracking (#1558)
- Add support for setting and changing the visitor and passing it to answers-core (#1564)
- Add support for the auth token that is passed in from the config (#1566)
- Add an `environment` field to support consumer auth in Sandbox (#1597)
- Allow components to override the beforeMount function (#1547)
- Add distance to the card data and a function to format it (#1550)
- WCAG updates (allow pagination with Enter (#1575), identify current page in navigation tab (#1576), update autocomplete screen reader support (#1578, #1579))

### Changes
- Update directAnswers component data to include the searcher (#1596)
- Use custom alerts instead of window.alert (#1549)
- Update Mapbox version to match the Theme (#1551)
- Internal repo changes (#1562, #1577)

### Bugfixes
- Fix console error which would appear on google maps (#1548)
- Fix FAQ expansion when default is expanded (#1553)
- Fix error for searches on page load with no businessId (#1561)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants