Give each current search or filter request ownership of its result and concise status; expose appropriate live feedback without moving focus or announcing stale responses.
A search filter can update the visible cards while leaving another reader unsure whether anything happened. Give the update a concise, truthful outcome without unexpectedly moving keyboard focus. The more difficult part is often timing: the message must describe the current selection, not whichever request finished last.
This guide uses a fictional learning-resource library with topic and format filters. Counts and request numbers illustrate decisions; they are not measurements from a live service. The workflow concerns enhanced in-page results, rather than a conventional search that navigates to a new results page.
Define the completed outcome before adding announcements
Write what the visitor should know after changing a filter: which selection is active, whether its request completed, and how to reach the matching resources. A disappearing spinner alone cannot distinguish success from cancellation or failure.
Keep a visible text outcome near the controls or result heading. For the fictional library, “3 resources match Video and Repair” is more useful than “Updated”. The wording should agree with the cards currently available, not an intended response that failed to render.
Decide what a displayed count means: all matches, cards on this page or items currently loaded. If there are more matches beyond the first batch, avoid describing the batch size as the total. Specify this contract before asking a developer to choose accessibility attributes.
Distinguish a status from the results themselves
W3C’s Status Messages explanation distinguishes a brief search-progress or result-count message from the list of results. Qualifying updates communicate status without taking focus or changing context. Making the entire result collection an announcement can bury the useful outcome in repeated titles and descriptions.
For the library, the count is feedback; the resource heading and cards remain navigable content. A reader can keep editing the filter and then choose when to explore results. Do not force them into the first card after every choice merely to make the update noticeable.
A full page navigation is a different interaction. Review its page title, heading and preserved query through the site-search guide, rather than applying the same in-page announcement design indiscriminately.
Keep one restrained, persistent status region
MDN documents the status role with implicit polite and atomic semantics. It suits advisory feedback that should not steal focus. A practical implementation should establish the region before updating its text and check the behaviour with the intended assistive technology.
Ask the maintainer to identify which component owns that region. If a theme, search extension and filter widget all announce the same completion, the visitor may hear duplicates. Keep the purposeful visible message and its programmatic exposure coordinated rather than inserting competing hidden copies.
Do not announce every keystroke as an urgent alert. For a type-to-search interface, agree when a request is worth making and announcing. Waiting briefly for a pause or requiring an explicit Search action are application design choices, not effects automatically supplied by an ARIA role.
Use a state record that includes failure and cancellation
| Current state | Fictional visible feedback | What must remain true |
|---|---|---|
| Updating | Updating resources for Video | The pending selection is clear |
| Complete with matches | 3 matching resources | Count and displayed collection agree |
| Complete with no matches | No resources match these filters | The reader can change or clear filters |
| Failed | Could not update; previous results remain | Old results are not labelled as new matches |
| Superseded | No separate completion message | An obsolete response cannot overwrite the current state |
Retaining old results during loading can help browsing, but identify them as the previous selection when that distinction matters. If you instead temporarily remove them, preserve a usable route to the filters. Neither choice should turn an unsuccessful request into “No matches”.
Provide an understandable retry for an error. It must use the current selection and avoid adding duplicate cards. Keep the reader’s filters intact where safe; resetting everything after a temporary failure makes recovery more laborious.
Give the latest intended request ownership
Suppose request 7 asks for Guides, then request 8 asks for Video. Request 8 returns first with three resources; request 7 later returns with twelve. The later arrival is older intent. It must not replace the video cards or announce twelve results for the active video filter.
Have the developer keep an explicit relationship between the submitted selection, request identity and current interface state. Before committing cards, count, pagination and status, verify that the response still belongs to the active intent. Cancelling unnecessary work can help, but the interface still needs an ownership check.
Reset later-page state when a new selection requires it. A successful second page of an old category is not the first page of a new one. Treat the result collection and its navigation as one coordinated update, rather than allowing each to accept responses independently.
Finish busy state without confusing it with request control
MDN’s aria-busy reference explains signalling that updates are incomplete and returning the state to false when they finish. The attribute does not abort network activity, prevent duplicate requests or select the correct response.
If the implementation uses busy state on its result region, define who clears it on success, no matches, error and a superseding request. An obsolete request must not clear a newer request’s pending state prematurely. Keep the announced outcome coordinated with the final content commit.
Review a slow update as well as a fast one. A loading message that appears only after completion is misleading. An interface that remains busy forever after an error also needs a real recovery path, not merely a changed colour.
Test the complete reading and keyboard route
- Start with a known selection and record its cards and count.
- Change one filter using the keyboard; confirm focus remains purposeful.
- Review the announced and visible completion, then move into the results.
- Try a no-match selection and recover through the offered controls.
- On an authorized test copy, exercise a slow or failed request and retry.
- Change selections rapidly so responses can arrive out of order.
- Repeat with a relevant screen-reader/browser combination and retain the actual outcome.
Record whether messages were missing, duplicated, delayed or stale; the presence of role and busy attributes is insufficient evidence. Check narrow layouts, long filter labels and the last result. Our form-feedback review addresses control labels and corrections; the archive guide covers reaching later batches. Accept this interaction when the current selection, available results and conveyed outcome tell the same story.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- W3C: Status MessagesChecked Brief waiting, completion, count and no-match feedback without a context change can be status messages; the whole results list is different.
Limits: This criterion does not prescribe one implementation or make every page change a live announcement. - MDN: status roleChecked Advisory live-region semantics with implicit polite and atomic behaviour.
Limits: Correct attributes alone do not prove announcement timing or support across actual browser and assistive-technology combinations. - MDN: aria-busyChecked Communicating an incomplete update and setting the state back to false on completion.
Limits: Busy state neither cancels a request nor determines which response belongs to the current selection.