bridgetown
bridgetown copied to clipboard
feat: Accessibility testing
Summary
Before deploying a website, it may be helpful to do some accessibility testing.
Motivation
Ensure that sites built with Bridgetown are accessible and make sure automated checks can be done during development
Guide-level explanation
- When building and/or augmenting a static site, you would be notified of accessibility problems in [WCAG Guidelines] (https://www.w3.org/WAI/standards-guidelines/wcag/) early so that they can be rectified.
- You would get a warning message for WCAG violations
- https://accessibility.18f.gov/ gives more information on accessibility
Reference-level explanation
Possible tools that can be integrated as tests include
- https://github.com/pa11y/pa11y
- https://github.com/dequelabs/axe-core
- https://developers.google.com/web/tools/lighthouse/
- https://github.com/IBMa/equal-access
Drawbacks
Increases complexity of the project
Unresolved Questions
Best way to implement the testing
Thanks for the great idea! I think this is something we could maybe add to our bundled configurations feature alongside things like PurgeCSS or Minitest.
Configurations folder seems reasonable.
Documentation on testing and automation would probably also be needed.
One option is cypress-axe , an example of using this is available at https://github.com/leonardofaria/cypress-accessibility-example
Another option is webhint which seems to offer more functionality.
I'm doing some issue gardening 🌱🌿 🌷 and came upon this issue.
Maybe this is something that could live in plugins, outside Bridgetown?
Important advances accessibility-wise are usually at the OS level. For example, recent versions of macOS has great accessibility support (even for websites that has spent zero effort making their page accessible).
In a world of finite time, I would let this live outside core and let enthusiasts focus on it.
By closing some old issues we reduce the list of open issues to a more manageable set.