Skip to content
This repository is currently being migrated. It's locked while the migration is in progress.
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 11 additions & 6 deletions src/_includes/components/results-description.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,17 @@
Text describing how many results are being shown.

* **Showing 1–10 of 999 results for "[query]".** The implementation should follow this format:
#### Structure

> Showing 1–10 of 999 results for "[query]"
* When used in non-search contexts, omit the `for "[query]"` portion. For example: `Showing 1–10 of 999 results.`
The implementation should follow this format:

* **Update when filters change.** The results description must update when filters are changed so that all users can understand that the results have been updated. Implementation should follow this format:
* Showing 1–10 of 999 for "[query]"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this say "results" ? showing 1-10 of 999 what?

Maybe there was a content decision to leave off the noun, and I trust the content folks. it just feels weird not not have the noun/object of the search displayed

* When used in non-search contexts, omit the `for "[query]"` portion.
* If a filter is applied to the results, add "with X filters applied" to the end. This is not necessary when sorting is applied since the Sort component itself acts as the visual indicator.
Comment thread
derekwang99 marked this conversation as resolved.
Comment thread
derekwang99 marked this conversation as resolved.

> Showing 1–10 of 999 results for "[query]" with 5 filters applied.
#### Code guidance

* **Do not reflect changes to sort.** The Sort component itself acts as the visual indicator of the order.
* An `<h2>` is not required for the results description. Some implementations on VA.gov may use this convention, but this is discouraged. A stable, targetable element (e.g., ID) is sufficient for focus management.
* Using `role="status"` provides an implicit `aria-live="polite"`, which will announce updates when the content changes. Adding an explicit `aria-live` is not necessary.
* To support programmatic focus, `tabindex="-1"` is required if we intend to move focus to the results description element. This is a focus-driven announcement pattern and is separate from live region behavior.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intent here to use a live region and to move focus at the same time to the results description? This seems like it would be redunandant? Moving focus to the description would also cause it to be announced. And the role="status" with the implicit aria-live would also cause it to be announced.

* When moving focus to the results description, the content should be announced as a single unit, assuming the DOM update is atomic. In testing (especially with VoiceOver), inline elements such as `<strong>`, `<span>`, etc., can cause the content to be announced in fragmented chunks instead of a single cohesive sentence, even though this is not consistently expected behavior.
* Avoid inline stylistic elements within the results description when possible, and instead rely on plain text to ensure consistent, single-pass announcements across assistive technologies. If inline styling is required, additional measures such as `aria-atomic="true"` may help, but results can still vary across screen readers.

Copilot AI Apr 22, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The aria-atomic="true" suggestion is a bit confusing alongside the recommendation to use role="status": elsewhere in the docs role="status" is described as implicitly setting aria-atomic="true" already. Consider clarifying that role="status" includes aria-atomic, and only suggest adding aria-atomic when using a different live-region approach.

Suggested change
* Avoid inline stylistic elements within the results description when possible, and instead rely on plain text to ensure consistent, single-pass announcements across assistive technologies. If inline styling is required, additional measures such as `aria-atomic="true"` may help, but results can still vary across screen readers.
* Avoid inline stylistic elements within the results description when possible, and instead rely on plain text to ensure consistent, single-pass announcements across assistive technologies. If inline styling is required and you are using a live region approach other than `role="status"`, `aria-atomic="true"` may help, but results can still vary across screen readers.

Copilot uses AI. Check for mistakes.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not the best person to make the call on whether to commit this suggestion so feedback is welcome.

Comment thread
derekwang99 marked this conversation as resolved.
Loading