Accessibility Audit

Our application should be a pillar of accessibility to everyone who'd like to participate in Massachusetts legislature. In order to evaluate how accessible our application is, we should use tools and reports that help us point out areas of improvement, and then make progress to improve accessibility.

We should:
1. **Break out the tools**: Use the [Axe accessibility tools](https://www.deque.com/axe/) to generate accessibility reports
2. **Decide accessibility compliance level (AA)**: Decide on a [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) level of accessibility to shoot for. I propose AA compliance as a reasonable goal. If we're not A compliant, that should be an intermediate goal.
3. **Break down tasks** based on the report generated and prioritize A violations over AA.
- Typically tasks consist of small changes to components in pages, like adding labels, ensuring color contrast is sufficient.
- This might need to include designers to ensure that current and future designs are also WCAG AA compliant.
- Each task should have an issue associated with it. That issue should be part of this epic. Issues might be broken down by page, feature, or type of violation. We should be deliberate about which approach we use and why.
- Clearly mark the level of violation and the priority so people understand which changes are most important in each issue.
5. **Assign the tasks to newcomers**. These are typically easy fixes that have small, clear scope, and a clear definition of complete (the report no longer flags it). More complex fixes should be marked as such and delegated to more experience members of the team.
6. **Future proof**: Generate ideas for how to continue making an accessible application.
- For example, adding [accessibility static linting rules](https://www.npmjs.com/package/eslint-plugin-jsx-a11y).
- Adding accessibility automated tests to prevent builds with inaccessible additions.
8. ???
9. ~~Profit~~ Accessibility