parent | nav_order | title | status | date | deciders | consulted | informed |
---|---|---|---|---|---|---|---|
Decisions |
100 |
Design & a11y reviews |
Proposed |
2023-08-04 |
Design/A11y lead |
All designers |
All project technical staff |
In order to work in an agile fashion and ensure code changes meet both design spec and our accessibility target, we should align on a consistent process to achieve this. As part of the accessibility review for each PR, the original developer will do a first pass of both design and a11y review. This DR covers how designers will be the second set of eyes on those user-facing changes.
- Review each PR locally before merging
- Review all merged PRs for the current sprint in the deployment environment at the end of the sprint
- Review entire application in the deployment environment every other sprint
- Review entire application in the deployment environment when designers are available
Chosen option: "Review all merged PRs for the current sprint in the deployment environment at the end of the sprint", because it is the best we can reasonably do given our comfort with the tools and time available.
- Good, because it maximizes coverage
- Good, because it does a decent job of preventing issues from sneaking by for more than a sprint
- Bad, because it requires extra time to create a new issue for each problem discovered
- Bad, because it requires extra time to filter Github PRs by date
This decision is confirmed by all designers, as they will be doing this work.
- Good, because it maximizes coverage of changes
- Good, because it prevents almost all issues from sneaking by
- Good, because feedback can go directly into the PR
- Bad, because it requires frequent intervention by designers who may not be comfortable with necessary tools
- Good, because it maximizes coverage of changes
- Good, because it does a decent job of preventing issues from sneaking by for more than a sprint
- Bad, because it requires extra time to create a new issue for each problem discovered
- Bad, because it requires extra time to filter Github PRs by date
- Good, because it maximizes coverage of the final user experience (end to end)
- Neutral, because it does a decent job of preventing issues from sneaking by for more than two sprints, but can mean more work is needed to recover from it
- Bad, because it requires extra time and cognitive load to check what was merged and identifying in the environment what to review. It's more likely in two vs one sprint that multiple PRs covered a certain page/feature, so filtering PRs by date is less useful.
- Bad, because it requires extra time to create a new issue for each problem discovered
- Neutral, because it could maximize coverage of the final user experience (end to end), but only as much as the designer has time for
- Bad, because lingering design/a11y debt can be harder to pay off the longer it lingers
- Bad, because it requires extra time and cognitive load to check what was merged and identifying in the environment what to review. It's higly likely that multiple PRs covered a certain page/feature, so filtering PRs by date is useless.
- Bad, because it requires extra time to create a new issue for each problem discovered
- The design review checklist is located in the PR template for the first option and in a separate document for all other options.