Description of bug or feature request

Capturing this suggestion from:
Lisa Sullivan
Email: xenacat3@hotmail.com

I am writing as a screen reader user with a suggestion for future WAI-ARIA or related accessibility API work.

Please feel free to forward this message to the appropriate WAI working group, task force, or publicly archived WAI mailing list if that is the best place for this kind of feedback.

The issue I am seeing involves dynamic web applications and screen reader browse-mode buffers. I am testing an Electron/web-based music application that can show or hide a playback transport area. The control is a native checkbox labeled "Show Transport." When it is unchecked, the app hides the transport wrapper using standard web techniques such as the native hidden attribute, aria-hidden, inert, and CSS display none. When it is checked, those hiding attributes are removed. A live status region announces "Transport shown" or "Transport hidden."

In JAWS focus/forms mode, this works correctly. The transport controls are available when shown and unavailable when hidden.

However, in JAWS browse mode, the virtual buffer can continue to contain stale information. JAWS may keep reading controls that were already hidden until the user turns browse mode off and back on, or manually refreshes the JAWS view. The page and accessibility tree appear to have changed correctly, but the browse-mode reading buffer does not always reflect that structural change immediately.

I understand that this is not simply an authoring problem, and that ARIA live regions are intended to announce changes rather than force a screen reader's virtual buffer to refresh. However, this seems to expose a gap for modern dynamic web applications. Many web and Electron applications behave more like traditional desktop applications, showing one workspace or control region at a time. Screen reader users may reasonably expect hidden controls to disappear from browse-mode navigation as soon as the app hides them.

My suggestion is that WAI consider whether future ARIA, accessibility API mappings, or authoring guidance could address this type of situation. For example, there might eventually be a way for authors to mark a region as structurally dynamic, so that assistive technologies know that show/hide or subtree changes should invalidate the cached browse-mode representation for that region.

Possible directions might include:

• A future ARIA attribute or role for a structural dynamic region whose subtree should be refreshed when its visible or accessible state changes.
• Accessibility API guidance for browsers to expose structural invalidation events for hidden, aria-hidden, inert, or controlled-region changes.
• Authoring guidance for dynamic applications explaining the best current pattern for screen reader browse-mode refresh issues.
• Coordination with screen reader vendors so that correctly hidden regions are removed from browse-mode virtual buffers more predictably.

Current related features such as aria-live, role=status, aria-relevant, aria-busy, hidden, aria-hidden, and inert are helpful, but none of them seems to mean: "the structure of this region has changed; assistive technologies should invalidate cached browse-mode content for this subtree."

This would be valuable for users because the current behavior can be confusing. A user may hear a status announcement saying that a region is hidden, but then browse mode may still read the old controls until the user knows to refresh the virtual buffer. Many ordinary users may not understand why this is happening.

Real example:

• A Show Transport checkbox controls a playback transport region.
• When checked, JAWS should be able to read Play, Loop, Record, Metronome, and Mode.
• When unchecked, those controls are hidden from the page and accessibility tree.
• JAWS focus/forms mode reflects the change.
• JAWS browse mode may continue to read the previous controls until browse mode is refreshed.

I realize that any solution would require coordination between ARIA, browsers, accessibility APIs, and assistive technologies. I am raising it because dynamic web and Electron applications are becoming more common, and this seems like an area where future standards or guidance could improve the user experience.

Thank you for considering this suggestion.

Sincerely,
Lisa Sullivan

Will this require a change to CORE-AAM?

If unknown, leave blank. If relevant, link bug.

Will this require a change to the ARIA authoring guide?

If unknown, leave blank. If relevant, link bug.