dollyVision / screens / 1.4 review workspace 1440 × 900 · macOS

Where the SME gets to play judge and jury.

Three panes, every findings-list action on a keystroke, and the snapshot-versus-live distinction never in doubt. Everything here is assembled from parts already defined in Elements and Components — nothing new is invented at screen level, which is what all the arguing in Elements was for.

Primary arrangement · list 380 / evidence fluid / browser 460 Snapshot mode
Northwind Retail version 4 · 2026-08-08 14 new 31 fixed 3 regressed Snapshot v4 Live
Filter Status · open Regressed only Severity · any Criterion · any Source · any Page · /checkout 12 of 136
Findings Sorted · severity
Regr
Interactive control has no accessible name
4.1.2 AA · axe · differs
Regr
Submit button unreachable by keyboard
2.1.1 A · axe · differs
Open
Contrast 3.1:1 on placeholder text
1.4.3 AA · axe · matches
Open
Focus indicator obscured by sticky header
2.4.11 AA · custom · unchecked
Man
Keyboard trap in date picker
2.1.2 A · manual · gone
Fixed
Redundant link text in footer
2.4.4 A · custom · matches
2 selected Push to Jira Set status
Screenshot A11y tree DOM Filmstrip Focus order
critical regressed AA DV-4A81-0117
Interactive control has no accessible name.
main > nav.utility > button:nth-of-type(2)
target element
1440 × 900 · captured 2026-08-08T09:14:26Z
Add an SME note…
Embedded browser Replaying snapshot
northwind.example/checkout/payment
Why matched · tier 3
signal
v3
v4
role
button
button
dom path
ul>li:2>button
nav>button
Keys Jnext Kprev Ffixed Eevidence Ppush Nnew manual Rrecheck Uundo Marked fixed Undo
Design notes Not part of the screen
Adding a finding, and how far it reaches

N opens a manual finding on whatever is selected in the browser pane. The scope control is the important part: this page only binds the finding to one URL, while every page with this element matches it across the sample by selector, so a footer problem is one finding rather than forty-two. Scope is set once at creation and shown on the card, because changing it later would silently rewrite the counts in a published version.

Snapshot and live are a mode, not a checkbox

The two-state block and the amber viewport frame say which one is showing at all times. This is the one place amber describes a mode rather than a change, because acting on the wrong one silently produces evidence that does not match the version record.

Every list action has a keystroke

Triage is the bulk of the working day, so status writes, navigation, evidence, push and recheck all sit on single keys — and every one of them is undoable, because rapid keying guarantees misfires.

Findings bind to captured evidence

Annotating during a live session triggers a visible micro-capture. A finding never rests on what someone remembers seeing.

Collapsed panes · rails, not absences [ findings · ] evidence · restores prior widths
Northwind Retail · Main storefront v4 · /checkout/payment both collapsed
[ 42 findings
]
Live
The embedded browser at full width. Collapse is the point: the SME is operating the page, not reading the list.
Rails keep the gutter reading · expanding restores the prior widths exactly
Zoom sweep · 1.4.4 and 1.4.10 Reference viewport 1280 · scrub with [ and ]
Probe · page rescaled Nine captures between 100% and 400%. Frames are evidence — a flagged frame attaches to a finding like any capture.
100%
125%
150%
175% · clips
200% · clips
250%
300%
350%
400% · two-way
Frame 400% · selected
Two-way scrolling appears at 400%, and the payment form first clips at 175% — well before the criterion's checkpoint. The sweep is what makes the earlier break visible; testing only the two presets would have reported a pass at 150% and a fail at 200% with nothing in between.
Attach frame to a finding Export filmstrip
Reference viewport
sweep width: 1280px
at 400%: 320 CSS px equivalent
capture profile: desktop

The standards sweep always runs from this width, whatever profile found the finding. Zooming a 390px viewport to 400% is not what 1.4.10 measures.

Mobile sweep · exploratory only