1856009 - Nothing is announced when a new Report Broken Site tool is opened

Status: RESOLVED FIXED

(Web Compatibility :: Tooling & Investigations, defect)

Description

[Anna Yeddi [:ayeddi]]

Attachment: Win-NVDA-output-Nothing-is-announced.png

STR:

1. Ensure a screen reader is running
2. From any site, open a new Report Broken Site tool (i.e. via URL bar > Enhanced Tracking Protection > Report Broken Site) with keyboard
3. Observe the announcement of a screen reader and, if possible, focus indicator position within the new RBS tool
   • Repeat the steps above with keyboard alone (without a screen reader)

Expected:

1. Screen reader is announcing that the tool is opened (the landmark role and its accessible name) - preferably by announcing the Report Broken Site, dialog (or Report Broken Site, group) and
2. the focus is landed on the topmost element of the dialog - the < Back button - and this button is announced as Back, button (after the landmark is announced)
   • If keyboard alone is used, the focus is still placed on the Back button
   • Design pattern and expected behavior example could be found in WAI ARIA website

Actual:

1. Screen reader only announces the title of the webpage opened (because it picks up some content change but does not know what exactly is relevant)
2. Keyboard focus is not present on the screen
   • The first Tab keypress would move the focus indication on the screen and to the editable URL field
   • In some cases, i.e. when the RBS tool is opened from the Fx Menu, the focus is placed by default on the editable URL field, but the screen reader does not announce any information about the dialog, thus it is not clear which specific URL is being edited and why (refer to the screenshot attached in the #c1)

Programmatic borders: The <panelview> dialog is not marked up as a landmark and has role=document (which is the pattern from the shield/protection doorhanger, now reported in bug 1855961): providing role=dialog or at least role=group would allow assistive technology users to use navigation shortcuts to navigate there as well as for screen readers to announce the content of the doorhanger when it loads.

Comment 1

[Anna Yeddi [:ayeddi]]

Attachment: Win-NVDA-Focus-is-placed-on-URL-edit-field.png

The issue with placing focus anywhere past the first focusable element or a container itself is that users who cannot see the screen or use high levels of magnification would miss the content above the focused element and would not get the helpful instructions for filling up the form and may not even know where are they and what is the URL that is being edited (especially when no dialog information is being announced by a screen reader)

Comment 2

[Anna Yeddi [:ayeddi]]

Since this behavior is caused by a new Report Site behavior and not by the A11y API, moving this bug to the Webcompat

Comment 3

[Thomas Wisniewski [:twisniewski]]

Anna, the latest batch of fixes have landed for our a11y story here, and are in the latest desktop nightlies. I think this bug is fixed now, could you confirm?

Comment 4

[Anna Yeddi [:ayeddi]]

Confirmed on Win 11 and macOS on the recent Nightly builds 123.0a1 (2024-01-01) that the Report Broken Site tool is announced when it is opened. Thank you for working on it, Thomas!