Two small ones: a table never says what it is, and discarding never offers the way back #260

New issue

Closed

opened 2026-09-17 15:07:07 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-17 15:07:07 +00:00

Owner

Two unrelated papercuts, both cheap, filed together because neither is worth its own issue.

A table never names itself

There is exactly one <caption> in the application — applications/calendar.html:79,
sr-only, carrying the month. The two configurable tables, applications and companies,
render a header row, a filter row, sortable columns, per-column widths and a resize handle,
and nothing that says what the table is. A screen reader asked to list the tables on the
page gets an unnamed one; somebody landing inside it by keyboard hears a grid of columns
with no subject.

A <caption class="sr-only"> in partials/table/head.html, taking the table's own label,
fixes it everywhere at once — both tables and whatever #160 adds. The label is already
known: it is what the column-settings view names the table by.

A discard never offers the way back

The capture review discards with d and moves straight on. That is right for the screen —
#179 built the keys because it is worked through forty times in a row — and discarding is
not destructive: CaptureStatus.DISCARDED is a status, the record stays, and the capture
list has a toggle that shows the ones that are not pending.

So the capture is recoverable and the interface never mentions it. The message says
"Capture discarded." and nothing else, at exactly the moment somebody who hit the wrong key
is looking for a way back. The fix is the message carrying a link to where the discarded
ones are — the mechanism exists, it is one sentence, and it turns a fast key from a risk
into a fast key.

Worth checking while there: the bulk version says "Captures discarded: N", which wants the
same link.

Two unrelated papercuts, both cheap, filed together because neither is worth its own issue. ## A table never names itself There is exactly one `<caption>` in the application — `applications/calendar.html:79`, `sr-only`, carrying the month. The two configurable tables, *applications* and *companies*, render a header row, a filter row, sortable columns, per-column widths and a resize handle, and nothing that says what the table *is*. A screen reader asked to list the tables on the page gets an unnamed one; somebody landing inside it by keyboard hears a grid of columns with no subject. A `<caption class="sr-only">` in `partials/table/head.html`, taking the table's own label, fixes it everywhere at once — both tables and whatever #160 adds. The label is already known: it is what the column-settings view names the table by. ## A discard never offers the way back The capture review discards with `d` and moves straight on. That is right for the screen — #179 built the keys because it is worked through forty times in a row — and discarding is not destructive: `CaptureStatus.DISCARDED` is a status, the record stays, and the capture list has a toggle that shows the ones that are not pending. So the capture is recoverable and the interface never mentions it. The message says "Capture discarded." and nothing else, at exactly the moment somebody who hit the wrong key is looking for a way back. The fix is the message carrying a link to where the discarded ones are — the mechanism exists, it is one sentence, and it turns a fast key from a risk into a fast key. Worth checking while there: the bulk version says "Captures discarded: N", which wants the same link.

tiagoagueda added this to the 0.4.0 milestone

2026-09-17 15:07:07 +00:00

tiagoagueda added the

enhancement

accessibility

interface

labels

2026-09-17 15:07:07 +00:00

tiagoagueda referenced this issue from a commit

2026-09-19 07:29:49 +00:00

Name the tables, and say where a discarded capture went

tiagoagueda closed this issue