A partly selected checkbox: make Select all mean the right records

Write the selection scope before designing its appearance

Choose an explicit promise: Select the 12 entries on this page, Select all 48 matching entries, or select a named group. These are different operations. If both page selection and whole-result selection exist, provide a deliberate step between them and name the expanded count. Avoid a silent change in scope when a reader reaches another page.

For the directory, suppose the first action selects the current page only. A separate option can offer all matching entries after the first selection. Record that rule in the design brief, acceptance checks and confirmation screen. The same wording should mean the same target set on desktop, mobile and keyboard journeys.

The sortable tables guide explains ordering. Selection should survive an order change by record identity, rather than transferring to whichever entry occupies an old row position. Ask for that behavior explicitly when reviewing an implementation.

Specify what activating a mixed checkbox will do

A partial indicator describes the present situation; the next activation still needs a predictable effect. Decide whether activating the group will select every eligible entry in scope or clear the selection. Prefer one documented policy throughout the product. Do not make the same-looking mixed state alternate between unrelated actions depending on how the visitor arrived there.

The HTML checkbox definition specifies native preactivation behavior: checkedness changes and indeterminate becomes false. An application that recomputes a group summary must deliberately reconcile that native transition with its own selected set. A style change alone is insufficient.

Ask the developer to demonstrate the intended transition using harmless records. Start with three selected entries, activate the group, inspect all selected identifiers, then activate it again. Judge the final set and explanation together. These are proposed acceptance exercises; they are not a claim that this fictional interface has been tested.

Decide how filters and unavailable entries affect the group

For the directory, retaining hidden selections can support a useful cross-page workflow, but the editor needs a way to inspect and clear them. Clearing selections on a filter change can also be reasonable when that is the product promise. Choose deliberately, communicate the change, and do not silently switch between the two policies.

Define eligibility separately. An entry may be visible but unavailable for this invitation because it was already invited. If the group selects eligible entries only, say so and show the eligible count. Review whether unavailable entries contribute to the mixed indicator; an ambiguous denominator can leave the checkbox permanently partial even after the intended selection is complete.

Use the dynamic result status guide for changes in result counts. Keep the selection summary equally specific: 3 selected, including 2 outside this filter, is more useful than a bare tick beside a changing result list.

Also define the reset route. A Clear selection control should describe whether it clears the current page or every retained identifier. In the directory example, reviewing the selection and clearing it must remain possible after a filter returns no results; otherwise an invisible earlier choice can survive without a practical correction path.

Make the group understandable without the dash

The W3C checkbox pattern describes partial group selection as mixed and documents an accessible name, state and Space-key operation. If a custom component replaces native checkboxes, these requirements need implementation and review; drawing a minus symbol does not provide the behavior.

Give individual entries distinctive names and name the group by its scope. A visitor should be able to tell which entry is selected without relying on row color or the nearby photograph. Check the group announcement and the selected count using the supported assistive technology combination, while remembering that this article does not establish a universal device test result.

Review the target set again before the operation

Selection and permission are separate. Before a consequential invitation or change, the receiving service should evaluate the requested entries under its current rules. A browser checkbox is not evidence that an editor is allowed to act on every supplied identifier.

Prepare a final review containing the action, count, selection scope and a route to inspect the entries. If some records became unavailable, explain which were skipped and which were acted upon. Avoid presenting a single success message for an outcome that actually contains several different results.

The disabled and readonly form guide covers native field eligibility. Here the acceptance target is broader: the selected set, the group summary, the request and the resulting operation must agree, including after pagination, filtering and an eligibility change.