Chrome Lighthouse

[fgomez828]

Breaking out convo about Lighthouse that started on issue #222.

The lowest-hanging fruit around increasing our accessibility includes the following:

• making sure images have alt attribs
• checking that sufficient contrast exists in the color palette; this is a helpful tool
• making sure that elements created in a loop have unique id attribs; this is a problem particularly when using bootstrap to create nav items, for example

For a thread concerning additional issues I tried addressing when working on the cps wagtail app, see this comment on the cps app accessibility issue

[fgomez828]

Here is an example of a PR that addresses some of the easy fixes that google lighthouse surfaced: https://github.com/datamade/cps-ssce-dashboard/pull/410

[hancush]

Deliverable: Create a recipe adding Lighthouse to our CI. https://github.com/GoogleChrome/lighthouse-ci

Ideas:

• Configure rules to exclude/omit.
• Configure a score threshold so site doesn't have to score 100%.

[hancush]

N.b., there are existing Actions that might offer a good starting point! https://github.com/marketplace/actions/lighthouse-check

[hancush]

Initial draft done, @fatima3558 learning more about additional assessments surfaced in CI.

[derekeder]

Related, I have added a list of Accessibility checks to the site launch checklist from @vkoves: https://github.com/datamade/site-launch-checklist/blob/master/README.md

Notably:

• [ ] Overview - test all pages with a tool like Axe DevTools or Google Lighthouse
• [ ] Keyboard - confirm all functionality works with a keyboard only. This includes logical focus order (typically left-right top-down) and no focus traps (except modals)
• [ ] Screen Reader - test pages with a screen reader like NVDA on Windows or VoiceOver on Mac, confirming that all content is clear, including:
  • [ ] Confirm no repeat or unclear button titles (e.g. "Click here" or "View more")
  • [ ] Confirm images have proper alt tags for their context (including alt="" for decorative images)
• [ ] Structure - Using Accessibility Insights for Web or another tool, confirm all pages have clear and sufficient heading levels. Keep in mind it should act like a table of contents, you want to have enough headings to be useful but not one for every paragraph.
• [ ] Color Blindness - make sure no information is conveyed via color only, potentially by testing using grayscale mode in Accessibility Insights for Web

An example of this is in use here: https://github.com/chihacknight/decarbonize-my-state/issues/73

[derekeder]

A few other things I've learned about accessibility testing recently:

• MacOS has a great built-in tool for recording video clips. This is great for testing out UI and sharing in GitHub issues: https://support.apple.com/en-us/HT208721
• When testing for accessibility, navigating using only the keyboard is a great thing to check. However, MacOS has disabled a key feature to test this. You cannot tab through links by default. This setting needs to be turned on: https://css-tricks.com/proper-tabbing-to-interactive-elements-in-firefox-on-macos/

[fgomez828]

Spent some time today trying to figure out why the lighthouse browser tool was giving me different scores than the github lighthouse action. For example, the CI score for a blog page is currently 87:

But when I run the assessment on localhost through the browser tool, I get a 96:

If I run the assessment on a page without any data loaded, the score is more in line with the scores we're getting through the CI tests:

This makes me wonder whether CI tests for accessibility make sense for a CMS app like CPS? Given that the CI only tests the templates, it won't test the pages as they will look on a production app.

[derekeder]

doing accessibility testing for the EFI site. Tracking progress here: https://github.com/datamade/mpc-efi/issues/92