feat: Accessibility testing

[bkmgit]

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

[jaredcwhite]

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.

[bkmgit]

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

[bkmgit]

Another option is webhint which seems to offer more functionality.

[sandstrom]

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.