Task list

Problem Context

• The component appears inside a service, application, setup, onboarding, registration, renewal, case, or task hub where users complete a known set of tasks.
• Each task row may represent one page, a section, a group of questions, an upload, a verification, a review task, or a dependent task.
• Users need to scan which rows are complete, which need action, which cannot yet start, and which row to open next.
• Task names, hints, status labels, grouping, and row activation determine whether users can navigate the broader transaction safely.
• The component may be used with a complete-multiple-tasks hub, but the component itself does not define the service's completion model.

Selection Rules

• Choose task list when the interface needs row-level task names, links, hint text, and status labels for a known set of service tasks.
• Use complete multiple tasks when the problem includes saved transaction progress, grouping across sessions, dependencies, final action gating, or review readiness beyond row anatomy.
• Use step navigation when users must move through a strict ordered path and should not choose any task row in any order.
• Use process list when users need public journey guidance rather than live task completion status.
• Use list view when users are browsing or managing arbitrary records with sorting, filtering, pagination, row menus, or bulk selection.
• Use progress bar when progress is continuous or measured as a bounded operation rather than a set of discrete tasks.
• Use tag inside task rows only for status labels that need emphasis; keep Completed lower weight so unfinished tasks remain prominent.
• Use review before submit for answer review after task completion, not inside the task list row itself.
• Include hint text only when users need extra context to decide whether to open the row, and keep it short.
• Hide neither blocked nor unavailable tasks; explain the dependency and route users to the unlocking task.
• Task names should be user-recognizable actions or sections, not internal model names.
• Connect each row's status and hint to its link or accessible description so screen reader users hear the task state before opening it.

Required States

• Linked startable task row.
• Completed task row.
• Incomplete or not started task row.
• In progress task row.
• Unavailable or cannot start yet task row with reason.
• Needs attention task row.
• Optional task row.
• Ready task row.
• Task row with concise hint text.
• Task row without hint text.
• Grouped task list section.
• Updated status after returning from a task.
• Mobile stacked row state.
• Long task name or long status wrapping state.
• Keyboard focus and hover state for the row link.

Interaction Contract

• A startable task row opens the represented task; the status label is not a separate primary command.
• Task statuses update when the user returns from the task, using the broader service state as the source of truth.
• Unavailable tasks remain visible with the reason and do not trap focus on disabled links.
• Hint text adds context only to the row it describes and does not contain separate links when the whole row is linked.
• Completed rows remain navigable if the broader service allows editing or review.
• Status labels are text first and colour second, and they do not rely on uppercase styling or button-like treatment.
• Rows wrap cleanly on mobile without detaching the status from the task name.

Implementation Checklist

• Define each task row's user-facing name, route, status source, optional hint, dependency reason, grouping, and completed-row edit behavior.
• Use semantic list markup or equivalent list structure with one focusable row or task link per startable task.
• Associate hint and status text with the task link through visible text and accessible description relationships.
• Keep status vocabulary small and consistent with the broader service, such as Completed, In progress, Not started, Cannot start yet, Needs attention, Optional, and Ready.
• Style Completed with lower emphasis than tasks needing action, and avoid status pills that look like primary buttons.
• Design mobile wrapping so long names, hints, and statuses remain readable without horizontal scrolling.
• Test keyboard activation, screen reader task names and statuses, blocked rows, status updates after return, long labels, grouping, high zoom, mobile, and row hover/focus affordance.

Common Generated-UI Mistakes

• Using task list as the whole service architecture without defining saved progress, dependencies, or final readiness elsewhere.
• Using task list as an answer summary.
• Using it for arbitrary records that need list view features such as sorting, filters, row actions, or selection.
• Using it for a strict linear journey that should use step navigation.
• Making status tags look like buttons or links.
• Putting several links or actions inside one task row.
• Writing long hints that screen reader users must hear every time they focus the task.
• Using colour alone to show status.

Critique Questions

• What task does each row start, and is the name clear enough without internal jargon?
• Does each row need hint text, or can the name carry the task by itself?
• Can users distinguish the row link from the non-interactive status label?
• Is the status text accurate, current, and connected to the row for assistive technology?
• What should users do when a task cannot start yet?
• Is this really a task list component problem, or a complete-multiple-tasks service pattern problem?