How do you test a design system in real web pages?
Use actual content and browser tasks to check that shared rules and parts work reliably.
Testing a design system checks whether it supports reading and tasks on real pages. A correct-looking individual part does not establish that its page composition works.
Keep these basics in mind
- Check complete common tasks, including success, failure, waiting, and cancellation, rather than default states alone.
- Cover representative browsers, wide and narrow viewports, zoom, and varying content lengths. Prioritise environments people actually use.
- Automated checks scan rules using tools. Manual checks involve people reading, operating, and judging. Both have roles.
- Regression checking repeats previously working scenarios after changes to find new problems.
See W3C’s preliminary accessibility checks for basic methods and USWDS accessibility guidance for systems and real-page verification.
Check and correct
Illustrative verification record
This is a teaching checklist, not completed test results.
| Scenario | Possible problem | Confirm after correction |
|---|---|---|
| Long-name card | Actions pushed out | Complete information and actions |
| Keyboard form | Save cannot be reached | Task works in a sensible order |
| Failed request | No recovery route | Input retained and retry available |
Walk through an example
After changing button padding, the team checks a regular profile page, an invitation page with long text, and a narrow window. The invitation button exceeds its container, so they correct size relationships. They recheck all three scenarios and record the coverage.
Limits and common misunderstandings
Passing automated tools is not full accessibility certification; preliminary checks do not cover everything. Screenshots reveal appearance changes but cannot establish correct interaction. Conclusions should name the environments checked rather than claim universal reliability.