Most accessibility findings are design decisions that reached the browser: a contrast ratio chosen in a palette, a focus state nobody drew, an error shown only in red, a tap target too small on a phone. Fixing them in code afterwards is more expensive than deciding them once in the design, and it is why a checklist for designers is a different document from a developer's. On the worked example fourteen failing criteria across nine templates carry 126 issues, and most of them were decided in a design file.
The palette, and the ratio it has to beat
Body text needs a contrast ratio of at least 4.5:1 against its background, and large text 3:1, under WCAG's contrast minimum. Check the palette once, in the design tool, including the states: the disabled grey, the placeholder text and the brand colour on white are the three that usually fail, and they fail on every page at once.
The states nobody draws
Focus, hover, active, error, disabled and loading, for every interactive component. Focus is the one that matters most and is missing most often, because it is invisible to a mouse user and essential to everybody else. Draw it once in the component library and it is right everywhere.
The things colour alone must not carry
Errors, required fields, chart series, status. Each needs a second signal: text, an icon, a pattern. This is the cheapest rule on the list to follow at design time and one of the more annoying to retrofit, because it usually means new copy as well as new markup.
Questions people ask about design accessibility checklist
Does this slow design down?
After the first project, no. It is a component library decision rather than a per-screen one.
Who owns accessibility, design or engineering?
Both, at different moments. The palette, the states and the copy are design; the markup, the focus management and the names are engineering.
What about a design system?
It is the highest-leverage place to fix this. A conformant component library removes the same finding from every future project.