Closed Bug 1323070 Opened 8 years ago Closed 8 years ago

'Remember Password' popup interrupts aria-live screen reader updates

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
50 Branch
Platform:
Unspecified
Windows
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: amangano, Unassigned)

Details

(Keywords: access) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

1.) Create a simple webpage with a form and an aria-live region (or role='alert') like the following:
<html>
  <head>
    <script>
      function onSubmit(event) {
        event.preventDefault();
        document.getElementById("status").innerHTML = "The form was submitted";
      }   
    </script>
  </head>

  <body>
    <p id="status" aria-live="polite"></p>

    <form method="post" action="" onsubmit="onSubmit(event)">
      <input id="email" type="email" placeholder="email@example.com"/>
      <input id="password" type="password" placeholder="password" />
      <input id="submit" type="submit" value="submit" />
    </form>
  </body>
</html>
2.) Start JAWS or NVDA screen reader on Windows.
3.) Open the webpage from step 1 in Firefox. Make sure that Firefox has been configured to offer to remember passwords.
4.) Fill out and submit the form. 


Actual results:

The 'Remember Password' popup appears and interrupts the screen reader before it can read the message in the aria-live region. The aria-live messages never get read. This can be very confusing for end users when aria-live regions are used to communicate form errors and other important information.

NOTE: this also happens when aria-live is set to 'assertive' and when role='alert' is used instead of aria-live. It seems to happen because the 'Remember Password' popup itself is treated as an element with role='alert', which interrupts other messages and causes the screen reader to give it immediate attention.


Expected results:

The screen reader eventually reads the contents of the aria-live region.
OS: Unspecified → Windows
Summary: 'Remember Password' popup interrupts screen reader updates → 'Remember Password' popup interrupts aria-live screen reader updates
Component: Untriaged → Disability Access APIs
Keywords: access
Product: Firefox → Core
Not actually sure how to solve this, since such prompts are important that they warrant the role "alert" set on them. This is one of those cases which hasn't been resolved satisfactory yet by the WAI-ARIA working group and/or screen reader vendors. Until a fully bullet-proof way forward for such dases is devised, I guess we'll have to live with this. Suggesting to WONTFIX this. David, any objections?
Flags: needinfo?(dbolter)
I'm not sure the spec would prescribe a fix on the browser side. I wonder if this is fixable by the screen reader. Perhaps with an 'unread live region queue' or something.
Flags: needinfo?(dbolter)
Setting to WONTFIX then. This is indeed more a problem of screen readers dealing with multiple live region updates. Our doorhangers (the password prompt) is just another of them (note role="alert" sets an aria-live="assertive" implicitly).
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Marco Zehe (:MarcoZ) from comment #3)
> Setting to WONTFIX then. This is indeed more a problem of screen readers
> dealing with multiple live region updates. Our doorhangers (the password
> prompt) is just another of them (note role="alert" sets an
> aria-live="assertive" implicitly).

Would it be possible to use something like aria-live="polite" instead of role="alert" for these? My understanding of role="alert" is that the alert message immediately grabs the attention of the screen reader, which can result in other messages being lost (as we are seeing here). Using aria-live="polite" would allow the screen reader to finish reading any messages in the queue before it reads the new polite message.
I would rather not do that, since some of these messages are indeed time-critical. For example, the password prompt goes away when the next page loads and keyboard focus shifts to a focusable element on that newly loaded page. So the user has to know immediately that they're being asked a question.
You need to log in before you can comment on or make changes to this bug.