The task and original case
Build an accessible file table where each download action has an identifiable destination. The three supplied file records are fictional. This is a table-and-link semantics project: the user should understand which file they are choosing, its format and its size without guessing from a repeated button label.
| Case element | Value or requirement |
|---|---|
| Inputs | A table lists 3 fictional files with file name, format and size; two share the visible label Download. |
| Build | A native HTML file table and a screen-reader/keyboard review checklist. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Create a native table with a caption describing the file collection. Use header cells for file name, format, size and action, and associate simple column headers with their data cells. W3C's data-table tutorial explains structural relationships for tabular information. Do not use a grid of generic containers merely to imitate a table's appearance.
Make each link name distinguish its destination, such as “Download budget template (CSV).” If you retain a short visible Download label, ensure its accessible name includes the file name and remains consistent with the visible wording. Use real demo targets or clearly marked placeholders; a link label does not establish that a nonexistent file can be downloaded.
Sources[1]
Check the worked result
The review should identify all three file names, formats and sizes in their respective rows. The two actions previously called only Download now have distinguishable destinations. A reviewer navigating a list of links should be able to tell them apart without relying on row position alone.
Read a row with a screen reader or inspect the accessibility tree and then perform a keyboard walkthrough. Confirm which column headers are announced and where focus goes after activating a link. Report the tools actually used.
Make the failure visible
Change one file's extension while leaving its stated format unchanged. Your content review should flag the mismatch. Also test a long file name at a narrow width; if the table scrolls horizontally, keep that region usable and labelled. Do not shrink the text until it becomes unreadable simply to make the whole row fit.
Revise it and ask someone to reproduce it
Ask a peer to select the specified CSV without using a pointer. Record whether they can identify the link and the surrounding file information. Add a fourth file with a similar name for the next revision, and improve naming if the actions become ambiguous. Preserve the original review to show what the change fixed.
- Caption and headers describe the actual file data.
- Every action identifies its specific destination.
- Long names and narrow-width behavior are reviewed contextually.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Created a native file-table exercise with structured headers, distinct download names and documented keyboard and assistive-technology review.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.