FE10: Capstone: three frontend projects for Kirana Express
Project 1: an accessible component set from a design
🎯You'll be able to
Turn a set of inaccessible components into an accessible, tested set.
🏠The everyday picture
A furniture maker turns a drawing into chairs that must also be sturdy, comfortable and safe for children. A developer turns a design file into components that must also work by keyboard, screen reader and touch.
📘What it really is
-
Read the design file carefully: sizes, spacing, colours, states (default, hover, focus, disabled, error, loading), and responsive behaviour. Ask the designer about anything missing, especially focus and error states.
-
Turn design values into tokens (FE7) and build each component with semantic HTML first (FE6):
Button(variants, loading state, icon-only with accessible name);TextField(label, hint, error linked witharia-describedby);SelectandCheckbox(native elements styled, or a well-tested accessible pattern);Dialog(focus in, trapped, Escape, focus returned);-
Toast(announced through a live region; doesn't steal focus; stays long enough to read). -
Show every state on the kit's
/componentspage. Stories in a tool such as Storybook are optional; they aren't needed to pass. - Test each with component tests by role and label (FE8), plus a manual keyboard and screen reader pass.
📝A worked example
A learner's component checks (illustrative; the test counts are the kit's):
| Component | Keyboard | Screen reader | Contrast | Kit tests |
|---|---|---|---|---|
| Button | ✓ | ✓ ("Add salt to cart, button") | 7.1:1 | 5 |
| TextField | ✓ | ✓ (label, hint, error announced) | 5.9:1 | 5 |
| Select and Checkbox | ✓ (native) | ✓ | 5.9:1; border 3.4:1 | 2 |
| Dialog | ✗ first: focus didn't return | ✓ | — | 4 |
| Toast | ✓ | ✓ (polite live region) | 6.2:1 | 4 |
The Dialog failure showed up in the kit's focus-return test; the learner fixed the component, not the test.
🌍Where it's used
- Design systems shared across products.
- Agencies building client sites from designers' files.
- Accessibility remediation of existing apps.
📝Case scenario
The design file has no focus style, and the designer is unavailable. The learner proposes a 3 px brand-coloured outline with an offset, checks its contrast against every background, documents it in the stories, and sends it to the designer for approval rather than leaving focus invisible.
🖱️Try it
Fix the six components in the kit's components/ui/ until npm run test:components and the axe scan of /components pass, then
record a manual keyboard and screen reader check in a table like the one above.
⚠️Common mistakes
- Fixing only what axe reports. Sign: the dialog still lets Tab escape. Fix: test every component by keyboard as well.
- Changing tests to make them pass. Sign: a test edited instead of the component. Fix: change the component; the tests are the agreed behaviour.
🛠️For your project
Project 1: fix the components in components/ui/ until the 20 tests in tests/components/ and the axe scan of /components pass.
✅Quick check
Which states are commonly missing from design files and need asking about?
Show the answer
Focus and error states (and often loading and disabled).
How should a toast notification behave for screen reader users?
Show the answer
It should be announced through a live region without stealing focus, and stay long enough to read.