Per our design review DR, The below steps are specifically the design and accessibility testing part of the overall acceptance flow process. The code submitter should have done their due dilligence for any user interface changes so that a design/a11y reviewer can focus on finer details. Although there are several steps, if we do this regularly it will be a light lift and will avoid any design/a11y debt.
- Consider conducting this with your engineer, who can help diagnose and articulate problems and solutions to what you may find in this process.
- Load the frontend application (this updates on every merge to the main branch)
- Open the PR(s) with the needs design review label to review.
- Use the checklist in the next section to review the changes, noting what the original developer checked off in their "user-facing" checklist
- For each PR you review, remove the needs design review label
- Create a new issue with the "Bug" template, and document a problem you find, linking to the relevant PR and
@ing the original developer for context (don't "assign" unless they're ok with it).- Repeat this step for each issue you find. To help engineers portion and pace work, it's usually best to not bundle everything into a single issue. Instead, use one issue for each discrepancy or highly related group of discrepancies.
- Check that the design translated visually
- Check interaction behavior
- Check different states (empty, one, some, error)
- Check for landmarks, page heading structure, and links
- Try to break the intended flow
- Confirm this works at 5Mbps down and 1Mbps up. You might use Firefox dev tools or Chrome's WebRTC Network Limiter
- Check responsiveness in mobile, tablet, and desktop at 200% zoom
- Check keyboard navigability
- Test general usability, landmarks, page header structure, and links with a screen reader (different from what the original dev used in their checklist):
- Use an a11y tool to check these changes conform to at least WCAG 2.1 AA