Advice after the warning

Last Tuesday I reviewed a sortable task board and left the comment below. I had spotted a real problem: the new interaction assumed a pointer, while the cards exposed no other way to move. Then I typed a question mark and handed the problem back.

Every word was defensible. The author still had to guess whether I wanted arrow keys, buttons, announcements, a different widget, or the whole feature removed. My concern arrived in the review; my help did not.

 return (

+  <SortableBoard columns={columns} onMove={moveCard} />

 );

Fine. What is the author supposed to do with that? I cannot measure how much vague advice comes from fear of giving the wrong answer, but I recognize the feeling because I had it while writing this comment. Accessibility covers standards, browser behavior, assistive technology, disability, language, and individual preference. A concrete recommendation can be checked against any of them and found wrong, which is exactly why the question mark felt safer.

So reviewers retreat to warnings. Teams hear that accessibility matters, receive little help choosing an implementation, and infer two safe options: build the familiar thing exactly as it has been built before, or find an expert who can bless every decision. That bargain protects the advice giver and leaves the person doing the work alone with the hard part.

The spec has more than one voice#

People often describe accessibility as subjective because they mix several kinds of claim into one pile. The Web Content Accessibility Guidelines 2.2 does the opposite. Its principles and guidelines are broad; the success criteria are written as testable requirements for conformance; techniques and common failures remain informative because context changes which implementation fits.

That layering gives a reviewer somewhere firm to stand. WCAG's keyboard criterion says that functionality must be operable through a keyboard interface, apart from tasks whose result depends on a path drawn by the user. The same guidance explicitly allows pointer input alongside the keyboard path. Nobody has to flatten a drag board into a list of plain links to satisfy it.

Dragging has its own requirement. WCAG 2.5.7 asks authors to provide a single-pointer alternative that does not require dragging, unless dragging is essential. Its examples keep the interesting interface and add controls: move-up and move-down buttons for a sortable list, a menu for moving a task between columns, or arrow buttons on a kanban card.

Custom widgets carry another concrete contract. The ARIA Authoring Practices Guide calls a role a promise: adding role="button" tells assistive technology what the element is, while the author still has to provide the keyboard behavior a native button gets from the browser.

Those are actionable statements. Other questions stay contextual. Should moving a card announce its new position after every key press? Does selection follow focus in this composite widget, or would that trigger slow network work and make navigation miserable? The APG's keyboard guidance says that selection following focus can help or harm depending on how quickly the interface responds. Reviewers have to mark which part they know and which part still needs evidence.

Label the kind of advice#

I now try to name what sort of claim I am making before I write the comment. Four labels cover most of the conversations I see, and they change what the author should do next.

The labels prevent a preference from dressing up as law. They also stop a clear requirement from dissolving into “consider accessibility.” An author who hears requirement knows the merge is blocked. Name a compatibility risk instead and the response is a test plan, while a hypothesis gets a prototype rather than a citation duel.

I went back to the task-board thread after lunch and replaced my question with this:

Keep dragging. Please add Move left and Move right controls that work by click and keyboard, then preserve focus on the card after it moves. WCAG 2.5.7 covers the non-drag pointer path and 2.1.1 covers keyboard operation. I am less certain about the announcement: try column name plus position with the screen readers we support, because repeating the full card may be noisy.

The revised comment could still be wrong at the edges. It gives the author a patch to attempt, two reasons for it, and one unresolved question with a way to gather evidence. The author can now see which uncertainty belongs to which part of the feature.

Judgment still deserves a sentence#

Some accessibility choices resist a universal answer because meaning depends on context. Alternative text is the familiar example. An image of a flooded street may be evidence in a news report, atmosphere on a travel page, or redundant beside a caption that already names the location and damage. The surrounding page gives the same image a different job in each case.

W3C's Easy Checks separates the easy machine question from the harder human one. A tool can report that an image lacks an altattribute. Deciding whether the supplied text communicates the image's purpose takes context, and the guidance says appropriate alt text is not an exact science.

“It depends” can begin useful advice, provided the next sentence says what it depends on. Propose the wording and name the user task it supports; then explain which detail you left out and why. A reviewer does not need universal authority to say, “On this product page, the color is part of the purchase decision, so include it in the description.”

User research helps with questions the criteria cannot settle, though it does not turn one participant into the representative of every disabled person. W3C's guidance on involving users in accessibility evaluation recommends bringing disabled users into development early, then stating the scope of what was evaluated. A small session can reveal a barrier, but it will not certify the entire interface for everyone.

Make expertise a service#

Accessibility does require specialist knowledge. So do security, databases, localization, and distributed systems; teams still let ordinary developers change code in those areas because they build review paths, defaults, tests, and escalation points. Requiring personal mastery before anyone tries a new interaction guarantees that most teams will reuse whatever component happens to be nearby, accessible or otherwise.

W3C's guidance on combined expertise expects a group to cover web technology, evaluation tools, disability barriers, assistive technology, and standards because one evaluator rarely carries all of it. That model gives specialists better work. They maintain patterns, teach reviewers what evidence means, join risky design work early, and take the cases whose consequences justify deeper testing.

A team can give every novel component a small baseline contract before escalation enters the conversation:

• Every action remains reachable and operable without the primary pointer gesture.
• Name, role, state, and value are available to assistive technology.
• Focus has a deliberate location before, during, and after the interaction.
• The team records which browser and assistive-technology combinations it actually tested.

Passing that baseline makes the discussion smaller without proving that the design works well. The specialist can spend time on orientation, cognitive load, speech verbosity, and unfamiliar gesture models instead of discovering that the only clickable object is a div with no key handler.

Some ideas will still fail when disabled users try them. Others will need a second interface rather than a clever adaptation of the first. I know of no process that removes that risk while preserving experimentation, though a team can expose its assumptions early and repair what the testing reveals.

Leave a next action#

A helpful accessibility review says what may break for whom, how confident the reviewer is, which requirement or convention applies, and what change would make the next test worth running. Those four pieces take longer to write than a question mark, and they spare the author from reverse-engineering what the reviewer was afraid of.

At 4:18 I reopened the task-board thread one last time. The author had added two small move buttons, and keyboard focus stayed on the card as it crossed into the next column. I pressed the right-arrow control, listened to the screen reader announce the new position twice, and left a comment about the duplicate speech. This time the cursor was already sitting after a sentence someone could act on.