RE: A question about immediate feedback

The modality of the <dialog> (theoretically) mimics the intended effects of aria-modal=”true/false”  depending how <dialog> is rendered visually.

 

in JavaScript, for example, the show() and showModal() methods produce a modeless and modal popup (the very word  dialog implies interaction between two parties), but not sure how consistent support is cross browser etc. especially for keyboard operability … 

 

much of the issue in my mind is that designers and developers tend towards making choices about layer content on appearance rather than function of purpose … 

 

 

 

 

 

 

 

 

From: Michael Livesey <mike.j.livesey@gmail.com> 
Sent: Thursday, June 26, 2025 1:40 PM
To: Adam Cooper <cooperad@bigpond.com>
Cc: Mike Cleary <mike.cleary@grantsolutions.gov>; w3c-wai-ig@w3.org
Subject: Re: A question about immediate feedback

 

I agree, there is a distinction between popup models and notification toast messages. Modals are for requiring a user decision and an action and are role="alertdialog", a toast is simply a notification.

A successful download popup sounds like a toast. These should be visible for long enough to read (using role alert), focus should not switch to them.

role="alert" is really meant for messages that need the users immediately attention. I would consider aria-live="polite" for something like a download notification.

The <dialog> tag for modals is really helpful, especially with respect to CSS, but I don't think this should be a modal.



On Thursday, June 26, 2025, Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> > wrote:
> This is a simple status message so please do not move focus to it or require  it to be dismissed using a close button. It should be onscreen for as long as you believe it is necessary for everybody to consume its content and then disappear.
>
>  
>
> This is difficult to get right across user agent combinations.
>
>  
>
> You can try experimenting with various combinations of role=”alert” and aria-live=”assertive” when the popup is invoked and feature detection to make it cross-browser compatible.
>
>  
>
> Alternatively, using the HTML <dialog> element can simplify some of the positioning etc., but be warned  - it is as tricky to get right as a custom element.
>
>  
>
> However, by the sounds of it, this popup is likely entirely unnecessary so consider removing it altogether – problem solved.
>
>  
>
> Also, 3.2.2 doesn’t have anything to do with returning focus to a trigger point if it is activated.
>
>  
>
> If the user agent dialogs are not announced by a screen reader, then that’s not your problem to fix.
>
>  
>
>  
>
>  
>
>  
>
> From: Mike Cleary <mike.cleary@grantsolutions.gov <mailto:mike.cleary@grantsolutions.gov> >
> Sent: Thursday, June 26, 2025 3:45 AM
> To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
> Subject: A question about immediate feedback
>
>  
>
> Hello all,
>
>  
>
> Does a user action like a download need to be confirmed in the immediate aftermath of taking that action? or is it acceptable if the confirmation is consistently announced, albeit after a little navigation?
>
>  
>
> We have an application where a user clicks a "Download" link on a popup form, and a second popup displays to say the download succeeded or failed. However, screen readers don't read the confirmation popup right away. 
>
> Browsers post their own equivalent popups about the download, which seem to compete for focus. Screen readers read the browser confirmation in Firefox, but don't manage to read those confirmations in Edge or Chrome.
>
> If the download works, the focus ends up on original Download link (per SC 3.2.2). When that popup form with that link is closed, screen readers always read the popup confirmation next.
>
>  
>
> Is it a problem that the screen reader doesn't always provide immediate feedback?  Or is WCAG 2.0 satisfied because the screen reader always eventually gets there.
>
>  
>
> Please advise.
>
>  
>
> Mike
>
>  
>
>  
>
>  
>
> Mike Cleary (Contractor) | Scrum Master
>
> Guidehouse, Inc. 
>
> mike.cleary@GrantSolutions.gov <mailto:mike.cleary@GrantSolutions.gov> 
>
>  
>
> On Assignment With
>
> GrantSolutions 
>
> Office of Grants, Office of the Assistant Secretary for Financial Resources (ASFR)
> U.S. Department of Health and Human Services
>
> Mobile: 703.627.7501