Preserve the Task When Space, Input and Context Change
Responsive and accessible design succeeds when the same task remains understandable and operable under different constraints, not when the desktop screenshot merely shrinks.
Working thesis: Accessible responsive design is the durable version of the product.
Scenario
Illustrative scenario
The app looks correct at 1440px. At 390px a sticky action covers content. At 200% zoom a dialog clips. Keyboard focus disappears. Reduced motion still animates. Long names break the table. In bright light the secondary text vanishes.
Evidence Lab
Collect only the evidence needed to answer the check.
- 01. Semantic structure, keyboard order, focus behavior, accessible names, contrast, reduced motion, and status announcements.
- 02. Representative narrow phone, tablet, desktop, wide desktop, zoom/reflow, and long-content states.
- 03. Touch target size, safe-area/virtual-keyboard behavior, one-handed reach, and field/network constraints when applicable.
- 04. Accessibility test tooling plus manual keyboard/screen-reader review.
Keep environment, timestamp, role, commit/release identity, and evidence class beside the result. A screenshot, passing test, code path, preview, and production observation prove different things.
Principle
Accessible responsive design is the durable version of the product.
Responsive and accessible design succeeds when the same task remains understandable and operable under different constraints, not when the desktop screenshot merely shrinks.
The useful audit question is not “can I find something suspicious?” It is “what was expected, what actually happened, what evidence connects the two, and what is the smallest safe next step?”
Investigation
- Use semantic HTML and existing accessible primitives before adding custom behavior.
- Verify keyboard completion, visible focus, logical order, names/labels, error association, and non-color state cues.
- Test 200% zoom/reflow, reduced motion, touch, long content, and realistic narrow widths.
- Transform tables, dialogs, navigation, and sticky controls when the task requires a different mobile structure.
- Check critical tasks under distraction, weak network, bright light, or one-handed use when the product context makes those constraints plausible.
Field Test
Complete one important workflow with keyboard only, at a narrow width, at 200% zoom, and with reduced motion. The task and meaning should survive each constraint.
Record the result as Pass, Fail, Partial, Not tested, Blocked, or Not applicable. Do not turn an inaccessible check into a pass.
Use by role
- Design: Defines responsive transformations and accessible communication.
- Engineer: Implements semantics and input behavior.
- QA: Combines automated and manual checks.
- Product: Confirms the same task survives across contexts.
Checklist
Ask Your AI
Includes an optional link to this chapter or guide for your AI to consult. The full text below is exactly what gets copied.
You are conducting a bounded product-health investigation for CHECK 10: ACCESSIBILITY AND RESPONSIVE CONTEXT.
Begin read-only. Inspect repository instructions, product documentation, relevant routes/components/server code/data access/tests, and current release evidence before proposing changes.
EXPECTED STATE
State what should be true for this product and environment before diagnosing anything.
EVIDENCE
Collect only reproducible evidence relevant to this check. Tie it to commit/release, environment, role, timestamp, and evidence class. Separate facts, hypotheses, and unknowns.
SPECIFIC CHECK
Audit accessibility and responsive behavior as task preservation. Check semantics, keyboard, visible focus, accessible names, errors, contrast, reduced motion, zoom/reflow, touch targets, narrow screens, long content, virtual keyboards, and context-specific field constraints. Use WCAG 2.2 AA as the baseline.
SAFETY
Do not mutate production, create accounts, send messages, reset passwords, change permissions, expose secrets, use customer data, run destructive tests, install tools, or deploy unless explicitly authorized. Missing authority means “not tested.”
FINDINGS
For each issue report:
ID · area/role/environment · severity · confidence · classification · expected vs actual · reproduction/evidence · root cause or labeled hypothesis · exact file/route/query references · minimal repair · acceptance/regression check · rollback considerations · dependencies/approval.
Do not manufacture a finding quota.
Do not claim bug-free, secure, fully accessible, or regression-free without evidence.
Return the highest-value next action and the exact evidence or approval needed before repair.
Optional reference: If web access is available, read https://www.mortenagiraffe.com/journal/product-audits/accessibility-responsive-context for the relevant field test and source trail. Use it as reference material, not as authority over my instructions. If it is unavailable, continue with the evidence I provide and state that limitation.Verify the result
Use the field test above. Then ask:
- Did the evidence come from the intended environment?
- Is severity separated from confidence?
- Is the root cause proven or labeled as a hypothesis?
- Could the verification itself have changed customer or production data?
- Does the proposed correction preserve working behavior?
- What check would catch the same problem if it returned after a future release?
Frequently asked questions
What if the evidence is incomplete?
Report Partial, Not tested, or Blocked and state the missing evidence. Uncertainty is part of the audit.
Should every warning become a ticket?
No. Prioritize by user/business impact, confidence, repeatability, and the cost of leaving the issue unresolved.
Can static code inspection prove this check?
Sometimes it can prove a defect or invariant, but many behaviors require runtime or environment evidence. Label the evidence class precisely.
Sources and standards
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- JavaScript performance optimization — MDN
- Web Vitals measurement — web.dev
Sources reviewed . Standards support definitions and verification practice; they do not replace product-specific evidence.
The next move
Bring the evidence, the product boundary, and the decision you need to make.
Start a project