Comment 1 by jteh on 2012-10-25 23:17
NVDA uses the same code it uses to get text from dialogs. It's rather complicated, but in short, it tries to find all descendants that might be text. However, it does not descend into certain objects including sections (which is what divs are mapped to in Firefox) because they normally don't contain dialog text. We need to think on how to fix this without breaking other use cases.

Comment 3 by javis on 2012-10-26 18:24
Just wanted to add a quick note to this one. It also looks like if you swap out the DIV for a span it will work. However, if your span has either position:fixed or display:block it will stop working.

If there is any more information I can provide to help just let me know.

Thanks,
Jeff

Comment 4 by Michael Curran <mick@... on 2014-04-16 01:07
In [19fd268]:

Reverting a change from December 2009 commit 6c53a29d where IAccessible NVDAObject's name property was forced to contain content from IAccessibleText if there was no caret present.

This was supposed to allow focusable labels in Thunderbird to read nicer. However, this caused a long-standing issue where the content of alerts in web browsers would speak twice, and Thunderbird now seems to oddly expose a caret on the labels thus disabling the code change anyway.
Removing this code may possibly cause some other regressions as its very old. However, if regressions are found they should be handled specificly for each case, as clearly this code was too general.

Should be a fix re #3481. May affect re #2442, #2745

@michaelDCurran Could you please restate the implications of your #2745 (comment) on this ticket more concisely? I don't think I follow this correctly, although I am a triager/user and no developer.

Does anyone have an work around for this? Just as the OP stated (at least five years ago to the day? weird) Firefox ignores the addition of role="alert" to a div on a page we're developing. It does not read the alert.

@contentfree, @javis, is this still an issue with NVDA 2019.1.1 and Firefox 66 or nightly? I think I cannot really reproduce this. Do you have an example website which shows this behavior?

Last reminder before closing this issue as abandoned. Is anyone able to reproduce this issue in NVDA 2019.2? We do not have an update on it since almost two years.

@XLTechie do you have the issue also with disabled addons? Is "reporting of object descriptions" in NVDA settings / object presentation enabled when you reproduce this issue?

I have this issue on this website: https://www.moorfields-private.co.uk/
When using NVDA 2019.2.1 in Firefox errors in the 'Make an enquiry' form are only announced as 'alert' and the error message is not announced.
If aria-live=assertive is added, would this resolve the issue?

role="alert" still does not work on Firefox 73.0 (64-bit), Microsoft EdgeHTML 17.17134 and IE11 with NVDA 2019.2.1.
Sample code:
<div role="alert">
<p><span>Testing role alert</span></p>
</div>

Any updates on this? Running into the very same issue on my end where we are trying to dynamically display an Alert after a submission event and the NVDA reader is only announcing 'Alert 9' and thats it when there is a whole block of text that is direct children of the Alert component. I have tried swapping the children text to be surrounded by a span | div | and a p and none of them have worked.

Firefox version 72.0.2 (64 bit)

          <Alert
            role={'alert'}
            style={{ marginBottom: '2rem' }}>
               <p role={'alertdialog'}>
                  sample display text!!!
               </p>
          </Alert>

This issue occurs in Chromium browsers as well. The issue is here as follows:
NVDA does not report the text when navigating with tab or shift+tab in focus mode, when pressing nvda+tab or when pressing nvda+shift+o. It reports the text however only in browse mode when navigating with arrow keys.
Only Internet explorer reports this properly in focus mode.
I have the feeling that this is a regression, the behavior is really broken in all browsers and I don't remember this behavior in earlier versions of NVDA, earlier than 2018.1.
This might be related to the allert being put into a div element. Related issues might be:
#9196, #9010, #8512, #8507, #7522, #6627, #6606.
cc: @jcsteh, at least for Firefox.

@feerrenrut should I create a meta issue containing the related issues?

Similar issues are occuring in some cases when putting elements in span or section.
I might be specific to which tabindex is set on div, span or section. But this needs to be investigated further.

NVDA does not report the text when navigating with tab or shift+tab in focus mode, when pressing nvda+tab or when pressing nvda+shift+o.

Alerts generally aren't focusable, so they aren't meant to be reported in focus mode They are meant to be read when they appear, and people here seem to be suggesting that this doesn't work. However, I'm unable to reproduce this with the following STR:

1. Open this test case:
   data:text/html,<div hidden id="al" role="alert"><p><span>Testing role alert</span></p></div><button onclick="al.hidden = false;">Show alert</button>
2. Press the "Show alert" button.
   • Result (expected and actual): NVDA says "alert Testing role alert"

Tested with latest Firefox Nightly and NVDA alpha.

@saurabhsrivastava01, @lincolnengineer1, please provide a full test case and steps to reproduce including exactly what keys you pressed/actions you executed, what you expected and what happened instead.

role="alert" is not supporting in IE11 and Microsoft Edge 42.17134.1098.0 browser. However it does support in Firefox v75.0 (64-bit), Chrome v 81.0.4044.122 (Official Build) (64-bit) with NVDA 2019.1

Below is the use case -
Validating the form input with backend service and when bad request issue occurs then a warning message has to be shown on top of the form. Here is the snippet of warning message -

<div role="alert"> <span className="warning-image" /> <span className=>Invalid inputs</span> </div>
This is working fine in Chrome and FF browsers but not in IE and Edge. Probably IE and Edge doesn't support role="alert".

I was struggling on the same issue, spent a day and got it working on IE11. Can you share your code and findings here ? If our code snippets matches I can help you on this.

This is working fine in Chrome and FF browsers but not in IE and Edge. Probably IE and Edge doesn't support role="alert".

Not sure about edge, but IE11 supports it. you just need to add some tweaks.

This is working fine in Chrome and FF browsers but not in IE and Edge. Probably IE and Edge doesn't support role="alert".

Not sure about edge, but IE11 supports it. you just need to add some tweaks.

@sumegha26 , i'm using this same code -

<div role="alert"> 
   <span>Invalid inputs</span>
</div>

this snippet is in a react component and it is being called when there is an invalid response from backend.
Can you suggest the tweaks you are talking about, Thanks!

@santoshpandey459 ,follow this - https://developer.paciellogroup.com/blog/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/

1. inner elements CSS visibility property must be toggled (for IE) - from display: none to block
2. Need an additional role=alert on outer container element and then only set the role=alert on the inner element before adding the text.

<div role="alert">
<span style="display: none"></span>
</div>

your initial snippet will look like above, now when you want to show the message inside span
1.add text content
2.change display property to block. (like below)
3. set role to alert for inside span

<div role="alert">
<span role="alert" style="display: block">Invalid Server response</span>
</div>

If structure is not nested only changing display property of span with role pre added alert should also work

This - <span role="alert" style="display: none"></span>

To - <span role="alert" style="display: block">Invalid Server response</span>

@sumegha26 , thank you for your input. I had tried this tweak as referenced here, working fine with Chrome(NVDA), IE11 and edge with Narrator but fails in Firefox.

cc: @jcsteh in case there is something relevant in the last comment above. There might be a bug filled with Firefox already.