Project 1: An accessible component set

Marking guide version 1 · Lessons: FE1 lessons 1 and 5, FE6 lessons 1–5, FE7 lesson 3, FE8 lessons 3 and 5, FE10 lesson 2

The problem and who it's for

Kirana Express's buttons, fields and dialogs were built quickly. A shopper who uses a keyboard can't open the slot picker, a screen reader reads the Pay button as "group", and the error messages are red text nobody hears. Every page uses these six components, so fixing them once fixes the whole shop.

Scope

Rebuild Button, TextField, Select, Checkbox, Dialog and Toast in components/ui/ so they work by mouse, touch, keyboard and screen reader.
Style them from the design tokens in app/globals.css, with visible focus and contrast that meets WCAG 2.2 AA.
Keep the props the tests and pages use, so the rest of the app keeps working.

Not included

New components beyond the six.
A component library tool such as Storybook (optional extra).
Visual pixel-perfect matching to a design file.

Before you start

Core: Module 12 (webpage content), Module 13 (forms and inputs), Module 32 (components and props), Module 39 (frontend quality).
Path: FE6 and FE8 complete.
The kit installed, npm run test:components runs (it fails at first).

Starter files

kirana-express/README.md: install, run and test commands.
kirana-express/components/ui/Button.tsx: one of six deliberately inaccessible components (the others are beside it).
kirana-express/app/components/page.tsx: shows every component and state, for manual checks and the axe scan.
kirana-express/tests/components/Button.test.tsx: one of five test files; together they hold the 20 component tests.
kirana-express/e2e/accessibility.spec.ts: the axe scan of six pages, including /components.
kirana-express/app/globals.css: the design tokens to style from.

Download everything at once: starter/frontend-starter.zip.

Milestones

Run npm run test:components and note which of the 20 tests fail and why.
Rebuild Button and TextField with native elements, labels, hints and linked errors.
Rebuild Select and Checkbox with native elements, styled from the tokens.
Rebuild Dialog (focus in, trapped, Escape closes, focus returns) and Toast (polite live region, no focus stealing).
Run npm run build then npm run a11y until /components has no serious or critical findings.
Do a keyboard-only and a screen reader pass of /components, and record what each component announces.

Expected outputs

20 of 20 component tests passing.
No serious or critical axe findings on /components.
A short table: each component, keyboard result, what the screen reader announced, and the contrast ratio of its text or border.

Acceptance tests

#	Input	Expected result
1	`npm run test:components`	20 of 20 pass (Button 5, TextField 5, Select and Checkbox 2, Dialog 4, Toast 4)
2	`npm run build`, then `npm run a11y`, test for `/components`	Passes: no serious or critical axe findings
3	Open the dialog on `/components` by keyboard, press Tab 10 times, then Escape	Focus stays inside while open; Escape closes it; focus returns to the button that opened it
4	With a screen reader running, move to the PIN code field on `/components` (it shows an error)	The field's name and its error are both announced
5	Zoom to 200% and view at 320 px wide	No text is cut off and nothing needs sideways scrolling
6	`npm run typecheck`	No errors

Failure and recovery exercises

Remove the :focus-visible style from your Button and Tab through /components. Describe what a keyboard user experiences, then put it back.
Make the Toast take focus when it appears, and type in a field while it shows. Explain the problem, then restore it.
Change one test's expected text to make it pass without fixing the component. Run the axe scan and the keyboard check, and write down why changing the test hid a real problem. Then undo it.

Evidence to submit

Link to your repository or a shared folder with the kit and your changes: the deliverable link.
The output of npm run test:components showing 20 passed, and of npm run a11y for /components, pasted into test evidence.
A recording of under 5 minutes using only the keyboard on /components, with focus visible.
Your explanation: which native elements you used, how the dialog manages focus, and how errors are linked to fields.

Marking guide and self-check

Pass rule: every Safety-critical (S) and Mandatory (M) item must be met. A single unmet safety item means the project is not complete, whatever else is done. Quality items are for your own improvement.

Your answers are saved in this browser on this device. Self-checked means you checked your own work against this guide; it is not a reviewer's approval. Never paste passwords, keys, tokens or real customer data here.

Checklist (marking guide version 1)Safety-critical Every interactive control can be reached and used with the keyboard alone, with visible focus (acceptance test 3 and your recording).Safety-critical No form field relies on placeholder text or colour alone for its name or its error.Mandatory 20 of 20 component tests pass, with the output in your evidence; no test was changed to make it pass.Mandatory No serious or critical axe findings on /components.Mandatory The dialog traps focus, closes with Escape and returns focus; the toast is announced without taking focus.Mandatory Colours and spacing come from the tokens in app/globals.css.Quality The manual screen reader table covers all six components.Quality Failure and recovery exercises 1 to 3 completed and written up.

EvidenceLink to your deliverable (repository, workflow export, prototype or report)Test evidence: which acceptance tests you ran and what happenedLink to a short demonstration (screen recording or live preview)Your explanation: how it works and why you chose this design (60 words or more)Your self-assessment against the marking guide (30 words or more)Status