|
1 | 1 | Text describing how many results are being shown. |
2 | 2 |
|
3 | | -* **Showing 1–10 of 999 results for "[query]".** The implementation should follow this format: |
| 3 | +#### Structure |
4 | 4 |
|
5 | | -> Showing 1–10 of 999 results for "[query]" |
6 | | - * When used in non-search contexts, omit the `for "[query]"` portion. For example: `Showing 1–10 of 999 results.` |
| 5 | +The implementation should follow this format: |
7 | 6 |
|
8 | | -* **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: |
| 7 | +* Showing 1–10 of 999 for "[query]" |
| 8 | + * When used in non-search contexts, omit the `for "[query]"` portion. |
| 9 | + * 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. |
9 | 10 |
|
10 | | -> Showing 1–10 of 999 results for "[query]" with 5 filters applied. |
| 11 | +#### Code guidance |
11 | 12 |
|
12 | | -* **Do not reflect changes to sort.** The Sort component itself acts as the visual indicator of the order. |
| 13 | +* An `<h2>` is not required for the results description. Some implementations on VA.gov may use this convention, but this is not necessary. A stable, targetable element (e.g., ID) is sufficient for focus management. |
| 14 | +* 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. |
| 15 | +* 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. |
| 16 | +* When moving focus to the results description, the content should be announced as a single unit, assuming the DOM update is atomic. |
| 17 | +* 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. |
| 18 | +* 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. |
| 19 | +* If inline styling is required, additional measures such as `aria-atomic="true"` may help, but results can still vary across screen readers. |
0 commit comments