Practice Site · QA Lab
Accessibility Practice App.
Practise accessibility testing using realistic UI components with intentional accessibility issues. Test keyboard navigation, focus order, accessible forms, error messages, modals, accordions, tabs, tables, colour contrast and ARIA mistakes.
Beginner to Intermediate45–90 minutesAccessibility labPartly automatableAccessibilityManualUI
Scenarios
25
Seeded bugs
11
Best for
Accessibility · Keyboard testing · WCAG
Test data
—
Answer guide
✓ Included
On this page17 sections
// WHAT YOU'LL PRACTISE
- Keyboard-only navigation
- Visible focus indicators
- Focus order
- Modal focus management
- Form labels and accessible names
- Error message accessibility
- Colour contrast checks
- Heading structure
- Image alt text
- ARIA misuse detection
- Table header validation
- Basic screen reader checks
// WHO THIS IS FOR
Manual QA engineers learning accessibility testingWeb testers adding accessibility smoke checksAutomation testers using axe or LighthouseDesigners and developers validating UI accessibilityInterview candidates preparing accessibility examples
// APP MODULES
Accessible and inaccessible formsNavigation menuModal dialogAccordionTabsData tableCheckout formError messagesKeyboard trap examplesColour contrast examplesImage examplesARIA examples
// PRACTICE MISSIONS
Small, focused tasks to warm up before the full lab.
25 mins
Check keyboard navigation
Accessibility, keyboard testing, focus order
→ Accessibility report20 mins
Test the modal focus trap and Escape
Focus management, ARIA
→ Bug report on focus handling30 mins
Run axe / Lighthouse and compare with manual findings
Tooling vs manual a11y testing
→ Combined accessibility findings// TEST SCENARIOS
Keyboard testing
- Navigate the page using the keyboard only.
- Verify all interactive elements are reachable.
- Verify the tab order is logical.
- Verify the focus indicator is visible.
- Open and close the menu using the keyboard.
- Open and close the modal using the keyboard.
- Verify Escape closes the modal where expected.
- Verify focus returns to the trigger after the modal closes.
Forms
- Verify every input has a visible label or accessible name.
- Submit the form with missing required fields.
- Verify errors are linked to their fields.
- Verify errors are announced or discoverable.
- Verify placeholder text is not the only label.
- Verify required fields are communicated clearly.
Visual and structure
- Check colour contrast for text and buttons.
- Verify the heading order is logical.
- Verify image alt text is meaningful.
- Verify decorative images are handled correctly.
- Verify tables have headers.
- Verify the page title is meaningful.
ARIA and components
- Verify the accordion state is announced.
- Verify tabs expose the selected state.
- Verify buttons are not incorrectly implemented as links.
- Verify custom controls have keyboard support.
- Verify ARIA is not used to hide important content incorrectly.
// SEEDED BUGS
This app seeds 11 bugs. Try to find them first, then reveal the answer guide to check your findings — each row links to its Common Bugs category.
| Bug | Example | Skill | Common Bugs |
|---|---|---|---|
| Missing label | An input has a placeholder but no label | Form accessibility | UI bugs → |
| Poor contrast | Grey text on a white background | Visual accessibility | UI bugs → |
| Keyboard trap | A user cannot escape the modal | Keyboard testing | — |
| Missing focus state | Button focus is invisible | Focus testing | UI bugs → |
| Bad heading order | The page jumps from h1 to h4 | Semantic structure | — |
| Bad ARIA | A button is incorrectly marked as a link | ARIA validation | — |
| Alt text issue | A decorative image has noisy alt text | Image accessibility | — |
| Error not announced | A form error is only shown visually | Accessible validation | UI bugs → |
| Tab order bug | Focus jumps unpredictably | Keyboard usability | — |
| Accordion exposes no state | A custom accordion toggles content but never sets aria-expanded | Component accessibility | — |
| Data table without headers | A table uses cells only — no th / scope for screen readers | Semantic structure | — |
Modal dialog does not trap focus or return it on closeSeverity: HighPriority: Medium
Steps to reproduce
- Open the modal with the keyboard
- Press Tab repeatedly
- Close the modal with Escape
Expected: Focus stays within the modal, then returns to the trigger.
Actual: Focus escapes to the page behind, and is lost after closing.
// REGRESSION CHECKLIST
The checks that would catch every seeded bug — reveal once you've done your own pass.
- Every interactive element is reachable by keyboard
- Focus is always visible and in a logical order
- Form fields have programmatic labels
- Errors are announced, not only shown visually
- Modals trap focus and restore it on close
- Headings follow a logical order
// REPORT TEMPLATE
A structure for each issue you log — copy it and fill it in.
- Issue
- What is wrong, in one line
- WCAG principle
- e.g. 1.3.1 Info & Relationships, 2.1.1 Keyboard
- Affected users
- Who this blocks (keyboard, screen reader, low vision…)
- Steps to reproduce
- How to observe it, including the tool / AT used
- Expected behaviour
- The accessible behaviour that should happen
- Actual behaviour
- What happens instead
- Severity
- Blocker / serious / moderate / minor
- Evidence
- Screenshot, recording or axe / Lighthouse output
// MANUAL & AUTOMATION TASKS
Manual testing tasks
- Complete keyboard-only navigation checks.
- Create an accessibility smoke test checklist.
- Report at least five accessibility bugs.
- Include the expected user impact in each bug report.
- Validate form labels and error messages.
- Check colour contrast with a tool.
- Check modal and menu behaviour.
Automation tasks
- Run axe checks on key pages.
- Run a Lighthouse accessibility audit.
- Add a Playwright accessibility smoke test using the axe integration.
- Verify focus movement for the modal.
- Verify visible focus states where practical.
- Add accessibility checks to CI for critical pages.
// INTERVIEW MODE
Reflection questions to rehearse how you'd talk through testing this app.
How do you test a page for keyboard-only users?
What's the difference between an automated axe scan and manual a11y testing?
How do you check that errors are announced to a screen reader?
Which WCAG checks would you prioritise in a smoke test?
How would you test a modal dialog for accessibility?
// WHAT YOU'LL PRODUCE
Accessibility reportKeyboard checklistWCAG issue examples
// SUGGESTED TOOLS
Keyboard onlyBrowser DevToolsaxe DevToolsLighthouseWAVEPlaywrightCypressScreen readers: VoiceOver / NVDA / Narrator
// AUTOMATION STARTERS
Fork a ready-made framework to automate this app — each sample ships with setup, CI and reporting.
// DOWNLOADS
// PORTFOLIO WRITE-UP
Use this as a starting point for your CV, LinkedIn or portfolio — swap in the tools and findings that are actually yours.
I tested an accessibility practice app covering keyboard navigation, focus order, modals, forms, error messages, heading structure, colour contrast, alt text and ARIA usage. I documented accessibility bugs with user impact and created a reusable accessibility smoke checklist.
// NEXT RECOMMENDED APP
Web app
Continue →UI Elements Playground
A free, standalone catalogue of almost every web element and widget — practise locators and automation against inputs, pickers, tables, overlays, navigation and dynamic content.