The task and original case
Audit a responsive layout where two cards change visual order while the DOM order stays the same. The work sample should show how reading and keyboard sequences compare with visible relationships. A narrow screenshot alone cannot reveal the document's interaction order.
| Case element | Value or requirement |
|---|---|
| Inputs | Two cards visually change order at a narrow width while their DOM order remains unchanged. |
| Build | A responsive reading-order demonstration and acceptance 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 minimal demo with two meaningful cards and a focusable link in each. Record the wide-screen visual order, DOM order and keyboard order. At a narrow width, reproduce the supplied visual reordering while leaving DOM order unchanged. Describe which relationship changes and whether the sequence matters to the task.
W3C's page-structure tutorial supports meaningful content structure. Inspect the DOM and accessibility reading order and tab through the links; do not infer these from CSS appearance. Prefer a structure whose meaningful sequence stays understandable across layouts. If an alternative visual order is harmless, explain why using actual task context instead of automatically treating every rearrangement as a failure.
Sources[1]
Check the worked result
The intended observation is a mismatch: narrow visual order differs from the unchanged document and keyboard sequence. Your report should name the two cards and list all three orders. It should explain the consequence, such as an instruction being reached after the action it explains, when the demo actually creates that dependency.
A proposed correction should align meaningful relationships or remove the dependency. Changing only the screenshot is insufficient if focus still jumps in an unexpected or confusing sequence.
Make the failure visible
Add another focusable control inside the visually first card and repeat the keyboard walkthrough. This can expose a longer focus jump than the two-link fixture. Avoid forcing order with positive tabindex values as a cosmetic repair; a coherent document structure is easier to maintain. Check that headings and regions still identify the cards after any structural change.
Revise it and ask someone to reproduce it
Ask a peer to complete the demo's declared task at both widths using a keyboard. Record where the order causes confusion, if it does. Revise the structure and repeat the same path. Preserve the before-and-after sequence lists with screenshots, and report the actual reviewed widths and interaction scope.
- Visual, DOM and keyboard order are recorded separately.
- Any failure is tied to a meaningful task relationship.
- The corrected sequence is rechecked at wide and narrow widths.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built an independent responsive reading-order audit comparing visible, document and keyboard sequences against a declared task relationship.”
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.