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

GitHub Actions: Run accessibility checks on additional pages #1278

Closed
1 task
afeld opened this issue Feb 16, 2023 · 8 comments
Closed
1 task

GitHub Actions: Run accessibility checks on additional pages #1278

afeld opened this issue Feb 16, 2023 · 8 comments
Assignees
Labels
actions Related to GitHub Actions workflows front-end HTML/CSS/JavaScript and Django templates tests Related to automated testing (unit, UI, integration, etc.)

Comments

@afeld
Copy link
Contributor

afeld commented Feb 16, 2023

We currently run Lighthouse on a couple pages:

- name: Run Lighthouse tests for a11y
uses: treosh/[email protected]
with:
urls: |
http://localhost:8000
http://localhost:8000/help

It would be helpful to have it (or some other automated accessibility checker run against other pages as well.

Acceptance Criteria

  • Get automated reports of accessibility violations on [at least the majority of] pages in Benefits

Additional context

Some options:

@afeld afeld added tests Related to automated testing (unit, UI, integration, etc.) front-end HTML/CSS/JavaScript and Django templates actions Related to GitHub Actions workflows labels Feb 16, 2023
@indexing
Copy link
Member

indexing commented Aug 8, 2023

@machikoyasuda The other day you mentioned we are running Lighthouse checks, so I believe we can close this issue?

@machikoyasuda
Copy link
Member

@indexing This issue is referring to adding automation to run Lighthouse checks on every page on every PR. So far, we're only running it on the home page and the help page. Not sure if this Issue is a priority anymore though.

@machikoyasuda
Copy link
Member

@indexing To me, this seems like something that could be a 1-week stretch ""fun"" ticket for a developer to work on during a slush week, if there aren't any other similar tickets. It's definitely not a must have.

@indexing
Copy link
Member

indexing commented Aug 8, 2023

@thekaveman What are you thoughts? Is it worth expanding the views we're checking via Lighthouse?

@thekaveman
Copy link
Member

I agree with @machikoyasuda this seems like a good exercise to timebox for a Stretch week.

Generally it would be good to do more automated checking like this (I rarely if ever remember to run Lighthouse myself locally). Let's see what we can accomplish in a reasonable amount of time using just Cypress and one of the plugins above, but without worrying about mocking all the external services or getting through e.g. Login.gov just yet.

@machikoyasuda machikoyasuda self-assigned this Aug 16, 2023
@machikoyasuda
Copy link
Member

Beginning preliminary research on this. May continue it into next week/stretch week.

@machikoyasuda machikoyasuda changed the title Run accessibility checks on additional pages GitHub Actions: Run accessibility checks on additional pages Aug 21, 2023
@machikoyasuda
Copy link
Member

machikoyasuda commented Aug 24, 2023

After extensive testing #1675 last week, I've come to the conclusion that, at this time, we shouldn't add the cypress-axe or cypress-audit tests to our continuous integration GitHub Actions. The tests worked perfectly well locally, but resulted in false positives when run on GitHub Actions.

Steps we can take now:

  • Fix the current known accessibility errors:
  1. Skip nav color contrast - Affects every page.
  2. Headline hierarchy bug (Refactor templates and includes #1528 bug reported here) for pages that use a Media Item, but don't have a H2. - Affects 1 page.
  3. Aria labeling for Modals - Affects all pages with modals.

Either way, we have to remember that automated testing only provides so much reassurance - and we'll always need some manual testing. And also, that certain accessibility issues (like color contrast) should be detected earlier at the design level.

As an example, both of the aforementioned tools weren't able to catch that a button had insufficient color contrast - because aria was set to disabled for that button! When I took aria-disabled=true out from the button, both tools were able to notice the button's issues.

cc @thekaveman @angela-tran

@thekaveman
Copy link
Member

@machikoyasuda what do you think about closing this issue now that you've done the research and made recommendations?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
actions Related to GitHub Actions workflows front-end HTML/CSS/JavaScript and Django templates tests Related to automated testing (unit, UI, integration, etc.)
Projects
Archived in project
Development

No branches or pull requests

4 participants