Week 7 Studio: Understood without the animation

The audit workshop. Turn off the motion, put the mouse away, and find out whether your interface was ever carrying its information in text.

22 April 2027

Here is the test, and it takes four seconds.

Turn your animation off. Look at the interface mid-upload. Can you tell what is happening?

For most prototypes arriving at this studio the answer is no, and the reason is uncomfortable: the information was in the motion. The text said Uploading… for ninety seconds while the bar carried everything a user actually knew — that it was moving, roughly how fast, roughly how far. Remove the animation and the interface stops saying anything, which means it was never saying it to anyone who could not see it.

By the end of this week#

You can:

• operate a waiting interface end to end from the keyboard, and identify where focus is lost when state changes underneath you;
• choose correctly between aria-valuenow, aria-valuetext and omitting the value, for determinate and indeterminate cases;
• write a live region that reports state transitions without announcing every increment;
• use prefers-reduced-motion as a diagnostic — turning motion off to discover what information it was carrying — and repair what goes missing;
• record an audit failure as a failure, in writing, on your own work.

The idea#

Tuesday’s lecture, Reading an Interface Without Looking at It, is the teaching. Today applies it. The four audit lines, with the trap in each:

1 — The keyboard path. Not a tab order. A state machine: at each state, what is reachable, and where does focus go when the state changes underneath the user? The common failure is a Cancel button that disappears on completion while focus is on it, dumping the user at the top of the document with no announcement.

2 — Semantics. role="progressbar" with aria-valuenow/valuemin/valuemax where a value exists, aria-valuetext where the bare number is unhelpful (“3 of 7 files” beats “43”). The trap is the indeterminate case from week 4: omitting aria-valuenow means progress is indeterminate; setting it to 0 means nothing has happened. Those are different claims and the second one is usually a lie.

3 — Announcements. A polite live region reports changes without interrupting. The failure mode is not silence, it is volume: a bar wired to announce aria-valuenow on every update produces a hundred announcements per upload, and the three state transitions that mattered are now buried. Announce transitions, never increments.

4 — Reduced motion as a diagnostic. Usually taught as a courtesy. Treat it as a test instead. Turn the animation off and ask what information left with it. If something did, that information was never in the interface — and this is the week your week 6 treatments are examined for whether they were carrying meaning or carrying atmosphere.

View this week’s slides — Tuesday’s lecture deck. Worth a pass before the studio, and the reference while you build. On a phone they are small — the deck is built for a projector, and this page carries the same material as prose.

In the room#

Thursday 22 April, 14:00–17:00.

What you start with#

• Your prototype through week 6: a determinate bar, three indeterminate registers, three motion treatments, and no accessibility work at all.
• Tuesday’s lecture, Reading an Interface Without Looking at It.
• The audit sheet, four lines, one page — the same sheet your partner will fill in on your prototype.
• Checklist v0, published in week 2.

What you build#

1. A completed audit sheet for your own prototype, four lines, each marked pass / fail / not-applicable with the evidence that settled it.
2. A second sheet, the one your partner filled in on your work.
3. The fixes the swap produced, committed today.
4. A reduced-motion variant of each week 6 treatment, which loses no information the default carried.

A worked example#

One defect, found and closed, on the week 4 indeterminate treatment. This is what a completed audit row looks like:

Line 2 — semantics        FAIL   aria-valuenow="0" during indeterminate stream
                          fixed  14:52, verified by re-listening

Recorded as a failure, then a fix. That row scores. A row reading “Line 2 — pass” would not.

Done when#

• Your partner completed an upload, hit a stall and read the outcome using only the keyboard, without being told anything.
• With motion disabled, your partner could say which state the interface was in at any moment you paused it.
• Your sheet has failures on it. Four passes and no notes is evidence the audit was not run, and it is marked that way.

The mistake to expect#

Recording a pass you cannot demonstrate.

A line recorded honestly as a failure scores. A line recorded as a pass that your marker can break does not, and costs more than the failure would have.

The second is subtler: fixing line 1 in a way that breaks line 3. Moving focus when a control disappears is correct; moving it without announcing why replaces a silent failure with a confusing one. Re-run all four lines after any fix.

Before next week#

About three hours — this is the heaviest week of homework in the course, because Assignment 2 is due on Tuesday 27 April, five days from now.

1. Fix what the pair swap found and you did not finish in the room.
2. Complete the Checklist v0 lines on the same sheet. They have been published since week 2 and they are assessed for the first time in A2.
3. Re-run the four audit lines yourself after the fixes. A fix that breaks another line is the usual outcome, and finding it now is much cheaper.

If you are joining late#

git checkout stage-07 restores a prototype carrying the week 4 and week 6 treatments with the accessibility work entirely absent. You audit that. It is a floor, not an answer — and auditing a baseline you did not write is a slightly harder version of today, not an easier one, because you cannot fall back on knowing what you meant.

What this week cannot tell you#

Two people at adjacent desks are not a test of whether this interface works for the people it excludes.

You audited against a checklist, and a checklist is a record of failures somebody has already had. It cannot report a failure nobody has written down yet. Neither of you uses a screen reader daily, so you have established that the announcements exist and are sane — not that they are good.

Say exactly that on the sheet. On Assignment 2 a line recorded honestly as a failure scores; a line recorded as a pass that your marker can break does not, and costs more than the failure would have.