1370032 - Redirection bar not annouced by screen reader

Status: RESOLVED WORKSFORME

(Firefox :: Disability Access, defect)

Description

[martinsz]

Attachment: barra de redireccion afip Captura de pantalla de 2017-06-03 13-33-04.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170523163538

Steps to reproduce:

Accessed a website with a meta redirect.

Full story here: https://support.mozilla.org/en-US/questions/1162786


Actual results:

The redirect authorization bar appears, but the screen reader does not notify the user


Expected results:

The authorization bar should have been announced by the screen reader

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco can you triage this one (when you are back)?

Comment 2

[Marco Zehe (:MarcoZ)]

Gijs, where does that one live best? it sounds to me like a change in the front-end code might have broken this. I've not seen such a meta redirect in ages.

Comment 3

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #2)
> Gijs, where does that one live best? it sounds to me like a change in the
> front-end code might have broken this.

Did it ever work?

> I've not seen such a meta redirect in ages.

You can get the bar to come up by loading:

data:text/html,<meta http-equiv="refresh" content="5; url=http://example.com/">


From a quick look, it looks like the notification bar should be getting role=alert, and isn't, but I haven't tested if that is enough to make NVDA happy.

Comment 4

[Marco Zehe (:MarcoZ)]

(In reply to :Gijs from comment #3)
> (In reply to Marco Zehe (:MarcoZ) from comment #2)
> > Gijs, where does that one live best? it sounds to me like a change in the
> > front-end code might have broken this.
> 
> Did it ever work?

Oh yes, a few years ago I did hear this on occasion. And it was announced automatically.

> From a quick look, it looks like the notification bar should be getting
> role=alert, and isn't, but I haven't tested if that is enough to make NVDA
> happy.

It should be enough.

Comment 5

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #4)
> (In reply to :Gijs from comment #3)
> > (In reply to Marco Zehe (:MarcoZ) from comment #2)
> > > Gijs, where does that one live best? it sounds to me like a change in the
> > > front-end code might have broken this.
> > 
> > Did it ever work?
> 
> Oh yes, a few years ago I did hear this on occasion. And it was announced
> automatically.

Then ideally someone should check when it broke and find a regression window. I don't have a setup to do that with.

> > From a quick look, it looks like the notification bar should be getting
> > role=alert, and isn't, but I haven't tested if that is enough to make NVDA
> > happy.
> 
> It should be enough.

I don't currently have cycles to work on this. As I have said elsewhere, I think we should remove this preference, as it is not fit for purpose anyway. That said, the issue may be a more general one with notification bars, which again, someone should investigate.

Comment 6

[martinsz]

I spent one hours bisecting builds from 2010 to 2017 and I didn't find a single one that works fine.
Since 2014 we have screen reader support in Linux (well, the user was on windows) and every build I tried after that date didn't announce the bar. So maybe someone with more experience can help me understand where in the code this should be.

Comment 7

[martinsz]

Hi, I think this bug should be set to confirmed. Also, there's a possible solution proposed, so it should be assigned to a developer also.

Comment 8

[:Gijs (he/him)]

(In reply to martinsz from comment #7)
> Also, there's a possible
> solution proposed, so it should be assigned to a developer also.

Unfortunately, there are hundreds of thousands of (open) bugs in this bug database, and lots of them have "possible solutions". It is simply not feasible to work on all of them right now. Someone will work on this bug when they can and its priority justifies doing so.

Whether the bug is confirmed doesn't really matter. In any case, I don't know that anyone has actually tried to reproduce. Maybe Marco has, I'm not entirely sure - I haven't.

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Reverting summary since this might be Linux only? (Marco can't repro)

Comment 10

[martinsz]

The bug was discovered on windows originally, and I also found it on linux. There is a possibility that some windows builds used to work, but I did not bisect on windows.

What has Marco tried to reproduce the bug?
The redirection bar is not announced by the screen reader and unless you know it's there, there's no indication that you can tab to it to click on the button. We're talking about people without sight that can't see the bar.

Comment 11

[Marco Zehe (:MarcoZ)]

I just confirmed that this indeed works on Windows with NVDA. Gijs was so kind and set up such a page for me that triggers this bar. Note that, by default, accessibility.blockautorefresh is FALSE, meaning auto-refreshes/redirects are not blocked any more. And as such, there is nothing to announce. So you'll only actually get this bar if you flip the pref in about:config. Once I did that, and visited the URL Gijs gave me, the alert was announced along with the Allow and Close buttons, and for the Allow button even the access key, as I remembered it from earlier days.

As far as I'm concerned, there is no bug here. At least not on Windows. I currently don't have Linux at hand to test there.

Comment 12

[Joanmarie Diggs]

Orca wasn't presenting it because there was unexpected "noise" in the accessible tree. I've just addressed that in Orca master and it's presented for me now.

Comment 13

[Marco Zehe (:MarcoZ)]

Thanks Joanie! Closing as WORKSFORME since a) not our bug and b) Fix committed to Orca, see comment #12. Windows with NVDA behaves correctly, see comment #11.