Accessible Learning Dashboard

1. Project setup and file structure

Scenario: you are building the dashboard a learner sees after signing in — a searchable, filterable grid of course cards with real progress data. Set up a Vite + React project locally (npm create vite@latest learning-dashboard -- --template react) organized by feature, not by file type: a src/dashboard/ folder containing CourseCard.jsx, CourseGrid.jsx, SearchFilterBar.jsx, useCourseData.js, and App.jsx. Add a small mockApi.js exporting a fetchCourses(query) function that returns a Promise resolving after a random delay (150-600ms), simulating a real network call, matching the pattern from this course's data-fetching lesson.

• The project runs locally with `npm run dev` and shows a placeholder page before any dashboard code is added
• Files are organized under src/dashboard/ by feature, not scattered into generic components/ and hooks/ folders
• mockApi.js's fetchCourses returns a real Promise with a randomized delay, not an instantly-resolved one

2. CourseCard and CourseGrid components

Build CourseCard as a single-responsibility, reusable component accepting props for title, difficulty, progressPercent, and an onSelect callback (following the one-way-data-flow and callback-prop patterns from this course). It must render a visible progress indicator (not just a number — a filled bar or equivalent, with an accessible text alternative such as an aria-valuenow-bearing progressbar role or visually-hidden text stating the percentage). Build CourseGrid to render a list of CourseCard components with stable, id-based keys (never array index), and its own empty-state message when the filtered list has zero items.

• CourseCard is a single, reusable component with no dashboard-specific data fetching inside it
• The progress indicator has a real accessible representation, not just a visual bar with no text alternative
• CourseGrid keys every card by the course's real id, never by array index
• CourseGrid shows a distinct, clearly-worded empty-state message when filtering produces zero results

3. Data fetching with all four UI states

Extract fetching and filtering into a custom hook, useCourseData(query), that owns items/isLoading/error/filtered state and guards against race conditions exactly as in this course's data-fetching lab (an ignore flag or request-token check in the effect's cleanup). App.jsx should derive a single uiState value ('loading' | 'error' | 'empty' | 'success') from the hook's returned data, per this course's UI-states lesson, and render distinctly different markup for each of the four states.

• useCourseData guards against race conditions using the ignore-flag or request-token pattern from the course
• All four UI states are reachable and visually distinct: loading (a real loading indicator), error (a retry-oriented message), empty (a helpful message distinct from the error state), success (the real grid)
• Typing quickly in the search field never leaves the dashboard showing results for an earlier, outdated query

4. Accessible search and filter controls

Build SearchFilterBar with a labeled search input (a real <label>, not just a placeholder) and a difficulty filter (a real <select> or a set of accessible toggle buttons with aria-pressed). Every control must be reachable and operable via keyboard alone, and the currently active filter must be understandable without relying on color alone.

• The search input has a real, programmatically associated label, not only a placeholder attribute
• The difficulty filter is fully keyboard-operable (tab to it, change it without a mouse)
• The active filter state is conveyed by more than color alone (e.g. also by text, an icon, or aria-pressed)

5. Component tests

Using React Testing Library (add @testing-library/react and @testing-library/jest-dom to the project via npm), write tests that query by role/label/text per this course's testing lesson: confirm the search input has an accessible name, confirm typing an unmatched query shows the empty state (not the error state), and confirm a CourseCard with 0% progress and one with 100% progress both render an accessible progress representation.

• At least one test queries the search input by its accessible role/label, not by CSS selector
• At least one test confirms the empty state (not the error state) appears for a non-matching query
• At least one test confirms CourseCard's progress indicator is accessible at both boundary values (0% and 100%)
• `npm test` (or your configured test command) runs all tests successfully with no failures