Complete the dragging task with separate pointer actions

Define the outcome before the fallback

W3C’s SC 2.5.7 explanation requires a non-drag single-pointer route, subject to its exceptions. Keyboard access alone does not establish that route.

Choose one operation and state the result the user must be able to achieve. List the important retained properties as well as the changed value. An alternative that reaches a similar screen while losing content, precision or the selected object may not preserve the actual task. Avoid defining success so vaguely that any response looks acceptable.

Ask the component owner which states and constraints are intentional. A fallback should not silently bypass a permission, a valid size limit or an existing content rule. Keep those rules fixed while comparing the interaction routes. The aim is equivalent capability under the approved contract, not a second tool with unrelated behavior.

Compare a concrete result pair

A fictional report panel contains a heading and chart. Dragging changes width from two columns to three. Tapping the width choice must produce the same width and retain both contents; choosing two restores the initial width. The model also rejects a four-column value outside its stipulated range.

Write the initial object once and make independent copies for the two runs. Compare the resulting fields rather than relying on visual similarity. Keep a rejected value in the fixture because an alternative that accepts an unsupported state can appear more capable while breaking the product’s contract. Record which values are intentionally supported rather than inventing them from the interface’s appearance.

The local execution here compares explicitly modeled operations and state equality. It does not simulate real dragging, touch input, browser controls or assistive technology. A supplied implementation demonstration remains necessary to show that users can discover and operate the intended route in the receiving environment.

Check whether the route is usable for this task

Ask a reviewer to locate the alternative without being told its exact position. Observe whether the wording identifies the object and the change clearly. A hidden menu item with an unrelated name may exist technically while remaining difficult to discover. Describe the observed problem rather than converting every usability concern into the same criterion failure.

Follow the operation through its surrounding workflow. Does the selected panel remain identifiable after the change? Can the reader inspect the result before continuing? Is the available reversal understandable? These questions keep the fallback attached to the user’s actual work instead of treating the presence of an extra control as sufficient evidence.

Preserve the ordinary interaction while reviewing the alternative. The purpose is not to force every user into one route or remove a useful interaction merely because another route is required. Ask the responsible accessibility reviewer to assess any claimed exception and keep that judgment separate from the practical comparison of outcomes.

Accept the capability, not just the extra button

Prepare a compact result record with the common starting state, supported values, paired outputs and remaining receiving checks. Explain a mismatch by the property that differs. A report saying the fallback failed is less actionable than showing that the width changed but a content identifier disappeared.

When the implementer proposes a fix, repeat the rejected-value case and the restoration case as well as the primary change. A repair can preserve the main result while accidentally weakening a constraint or applying the change to the wrong object. Keep the fixture small enough to repeat reliably whenever the component changes.

Finish with a bounded decision about the supplied capability and evidence. The local model can establish internal consistency of the proposed rules; it cannot establish compatibility with every device or prove the page’s overall accessibility. Record the version and unresolved receiving tests so a future reviewer does not inherit an unsupported blanket approval.

Make the reasoning concrete.

A fictional report editor has an attractive resizing interaction and a proposed width menu. A reviewer finds that the menu changes the width but drops one content identifier in an early prototype.

The editor keeps the mismatch open and requests a corrected implementation demonstration. No production content is changed.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Task

   Which result and retained properties define success?

2. Contract

   Which values and constraints are intentionally supported?

3. Pair

   Do independent runs produce equivalent objects?

4. Discovery

   Can a reviewer find the alternative without coaching?

5. Retest

   Which ordinary, rejected and restoration cases must survive a fix?

Watch for the wrong conclusion.

• Counting an extra control without checking its result.
• Allowing the alternative to bypass an intentional constraint.
• Calling state equality a real-device interaction test.

Sources & scope

Original explicitly fictional fixtures and editorial workflows. Criterion explanations and their applications remain source-derived. Understanding pages are informative guidance; scoped checks do not prove full conformance or legal compliance. Local modeled checks are distinguished from receiving-browser and assistive-technology evidence.

• W3C: Understanding SC 2.5.7, Dragging Movements →Primary W3C guidance · Supports: Supports the independent pointer-route requirement.