Verbosity Settings for Data Announcements

Data apps talk a lot: result counts, sort changes, selection totals, live updates, background job progress. What one screen reader user finds helpful, another finds exhausting. Screen readers have their own verbosity settings, but they cannot tell your app’s messages apart. An app-level verbosity setting — for example “Essential”, “Standard” and “Detailed” — lets users decide which categories of message they hear, without losing anything critical.

This guide belongs to screen reader announcement strategies.

Spec reference

SC 4.1.3 Status Messages (AA) — status messages must be programmatically available; verbosity settings must never suppress messages users need to complete tasks.
SC 2.2.4 Interruptions (AAA) — users can postpone or suppress interruptions except emergencies.
SC 2.2.2 Pause, Stop, Hide (A) — users can control auto-updating information.
SC 1.3.1 (A) — information suppressed from announcements must remain available on screen.

Higher levels add categories; essentials never drop.

When to use — and when not to

Add verbosity settings when your app announces more than a few message types, especially with live data. Default to “Standard”.

Do not let any level suppress errors or the outcome of the user’s own actions. The misapplication: a “quiet mode” that also silences “Save failed”, leaving users believing their work was saved.

Annotated code example

const LEVELS = { essential: 1, standard: 2, detailed: 3 };
const CATEGORY_LEVEL = { error: 1, outcome: 1, count: 2, confirm: 2, progress: 3, background: 3, hint: 3 };
let userLevel = LEVELS[loadPref('verbosity') ?? 'standard'];

export function announce(message, category, { assertive = false } = {}) {
  if (CATEGORY_LEVEL[category] > userLevel) return;                    // filtered by preference
  (assertive ? alertRegion : statusRegion).textContent = message;
}

// Usage
announce('Sorted by amount, descending', 'confirm');
announce('Export 40% complete', 'progress');
announce('Could not save INV-1042. Try again.', 'error', { assertive: true });

<fieldset>
  <legend>Announcement detail</legend>
  <label><input type="radio" name="verb" value="essential"> Essential — errors and results of your actions</label>
  <label><input type="radio" name="verb" value="standard" checked> Standard — also counts and confirmations</label>
  <label><input type="radio" name="verb" value="detailed"> Detailed — also progress and background updates</label>
</fieldset>

Keyboard & AT behaviour

Event	Essential	Standard	Detailed
Save failed	Announced (assertive)	Announced	Announced
Row deleted by user	Announced	Announced	Announced
Filter applied, 84 results	—	Announced	Announced
Export 40% complete	—	—	Announced
Another user edited a row	—	—	Announced

Users can choose roughly a tenfold range.

Step-by-step implementation

Inventory messages. Search the codebase for every live region update and list the message, trigger and purpose.
Classify them. Assign each a category: error, outcome, count, confirm, progress, background, hint.
Centralise announcing. Replace direct live region writes with a single announce() service that checks the level.
Add the preference. A radio group with descriptions of each level, in settings and perhaps a quick toggle near data views.
Confirm changes. When the level changes, announce a sample: “Announcement detail set to Essential”.

Integration context

Queuing messages is covered in announcement queues for competing messages, and bulk debouncing in debouncing status messages for bulk operations. Numeric updates are in announcing numeric changes with direction and magnitude, and live data controls in pause, stop, hide controls for auto-updating data.

Gotchas

Visible equivalents. Messages suppressed at low verbosity must still be visible somewhere (a status bar, a count), so users can check them on demand.

Testing at every level. Automated tests should assert that errors are announced at Essential.

Screen reader verbosity is separate. Users may also lower NVDA or JAWS verbosity; your setting controls content, theirs controls how it is spoken.

Edge cases

Multiple tabs. Apply the preference across tabs via storage events.
New message types. Require a category for every new announce call; reject uncategorised messages in code review or lint.
Shared workstations. Store preferences per user account, not per browser.

Worked example

A logistics app announced every shipment status update to dispatchers. Some screen reader users loved it; others switched off their screen readers’ speech for the app entirely. The team classified twenty message types, centralised announcements and added three verbosity levels with descriptions. Dispatchers who wanted silence chose Essential and still heard failed bookings; others chose Detailed. Complaints about noise stopped without anyone losing critical messages.

Common mistakes

A mute switch that silences errors.
Direct live region writes bypassing the setting.
No visible equivalents for suppressed messages.
No description of what each level includes.

Testing checklist

Every announcement has a category.
Errors and outcomes are announced at every level.
Changing the level is confirmed.
Suppressed information remains visible.
The preference persists per user.

With NVDA, set the level to Essential and perform a filter, a sort, an export and a failed save. Only the failed save and direct outcomes should speak. Switch to Detailed and repeat; you should hear counts, confirmations and progress. Check that the switch itself is announced. Use NVDA’s speech viewer to count messages per level and compare with your inventory.

Explaining the setting to users

Describe each level by what users will hear, not by abstract names. “Essential — errors and the results of your own actions” tells users exactly what they keep. Place the setting where users meet the noise: a small “Announcement detail” link near busy data views, as well as in global settings. Mention it in onboarding for screen reader users, and in any help page about keyboard and screen reader use. A setting nobody can find does not reduce noise.

Choosing categories

Categories should describe why a message exists, not where it comes from. “Outcome” covers the result of anything the user just did, whichever component did it; “background” covers anything that happened without the user’s action. That split matters more than any other, because users almost always want to hear about their own actions and are much more selective about everything else. Keep the list short — six to eight categories — so that new messages are easy to classify consistently, and write one example message for each category in your contributor guidelines.

Key points

Route every message through one service that knows its category.
Errors and outcomes of the user’s own actions are never filtered.
Describe each level by what users will hear, and confirm changes.

Design system notes

Provide the announce service with categories in the design system, and include the verbosity preference in the standard settings page template.

FAQ

Does this replace screen reader verbosity?

No. It complements it by filtering what the app sends.

What should the default be?

Standard, with counts and confirmations.

Can users choose categories individually?

Advanced settings can expose per-category toggles; levels are simpler for most.

Are errors ever suppressible?

No. Errors and outcomes of user actions are always announced.

Does this help non-screen-reader users?

Visible toast frequency can follow the same setting.

Where should the setting live?

In user preferences, with a shortcut near busy data views.

Announcement queues for competing messages — ordering messages
Announcing numeric changes — what to say
Notifications and toasts for data operations — visible messages

← Back to Screen Reader Announcement Strategies for Data Interfaces