631068 - NVDA stops reading field label after hide/show cycle

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Zack Weinberg (:zwol)]

Attachment: test case

In Firefox 4.0b10 with NVDA active, if you load the attached test case, NVDA will initially recite something like "hide link show link review edit multi-line".  But if you trigger "hide" and then "show", it does not repeat the word "review".

NVDA *does* repeat the word "review" if the label is associated with the text field by enclosure rather than a for="", or if the overflow changes or the delay are removed.

This is a regression from 3.6.

Comment 1

[alexander :surkov (:asurkov)]

I tried to navigate hide link, activate it, tab to show link, activate it, arrow down, it reads "repeat" and I can traverse the page by arrow keys. The behavior the same in Fx4 and Fx3.6 on nightly. I didn't tried Beta10 but Beta10 wasn't really good.

Marco, can you confirm my observation and if so then close bug as worksforme?

Comment 2

[Zack Weinberg (:zwol)]

It reads "repeat"?  Did you mean "review"?

Could you explain what you mean by "Beta10 wasn't really good"?  If you can't reproduce the bug even with beta10 I need to go back and mess with the test case, but if you *can* we can probably consider this fixed.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> I tried to navigate hide link, activate it, tab to show link, activate it,
> arrow down, it reads "repeat" and I can traverse the page by arrow keys.

doing tabbing I get "hide link", "show link", "review edit multiline", then shfit tab to hide link, press it, tab to show link, press it, then tab to edit and I get "review edit multiline". I think that should be a steps to reproduce.

So closing as worksforme, please reopen it if you still see a problem on nightlies or ongoing beta11.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> It reads "repeat"?  Did you mean "review"?

right. I guess I thought about something different when I spelled it :)

> Could you explain what you mean by "Beta10 wasn't really good"?

We weren't in time to polish our major code changes introduced in FX4. It's quite possible that beta10 has a lacks of a11y support. Beta11 feels much better though has a problems still.

>  If you can't
> reproduce the bug even with beta10 I need to go back and mess with the test
> case, but if you *can* we can probably consider this fixed.

I'll try with beta10.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)

> I'll try with beta10.

confirm, I can reproduce with beta10

Comment 6

[Zack Weinberg (:zwol)]

Thanks for the quick work; I'll have my informant verify once beta11 comes 'round.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> I'll have my informant verify once beta11 comes
> 'round.

ok, please make sure to change status on resolved once you confirm

Comment 8

[Zack Weinberg (:zwol)]

Informant reports problem still present with beta 11.  Informant has previously refused to touch nightlies under any circumstances whatsoever, so please do not ask.

Comment 9

[Zack Weinberg (:zwol)]

Note also that I have myself failed to reproduce the problem with beta 10 under GNOME with Orca, and failed to make OSX's VoiceOver do anything whatsoever constructive with beta10 or beta11 (the VoiceOver highlight cannot be budged from the window's close button -- I did file a bug for that, yes?)

Therefore there is every reason to believe this problem is specific to Windows and/or specific to NVDA.  I bring this up because nobody else who failed to reproduce the problem with pre-beta11 nightlies said exactly which OS and/or screenreader they were using.

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> Note also that I have myself failed to reproduce the problem with beta 10 under
> GNOME with Orca, and failed to make OSX's VoiceOver do anything whatsoever
> constructive with beta10 or beta11 (the VoiceOver highlight cannot be budged
> from the window's close button -- I did file a bug for that, yes?)

No, Firefox 4 is not accessible on Mac.

> Therefore there is every reason to believe this problem is specific to Windows
> and/or specific to NVDA.  I bring this up because nobody else who failed to
> reproduce the problem with pre-beta11 nightlies said exactly which OS and/or
> screenreader they were using.

Marco, can you please look?

Comment 11

[Marco Zehe (:MarcoZ)]

Yes, I can now reproduce this with NVDA 2011.1Beta2 and Firefox 4.0b12pre nightlies. In the tree, the accessible name is not again associated with the label's text after showing. AccProbe confirms this observation, the textarea no longer has the accessible name. So this is not just NVDA that's exposing this problem, it's our code.

Comment 12

[alexander :surkov (:asurkov)]

hardblocker, final+ is ok with this I think. Must be fixed in fx4 since points to underlying serious problems.

Comment 13

[alexander :surkov (:asurkov)]

Marco, can you find regression range? I was pretty sure I wasn't able to see on nightly (comment #3) while I saw it on beta10 (comment #5).

Comment 14

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

(In reply to comment #12)
> hardblocker, final+ is ok with this I think. Must be fixed in fx4 since points
> to underlying serious problems.

Yeah, comment 11 worries me. Let's try to get a low risk fix.

Zack, thanks for staying with this bug. I wonder what Orca is doing differently, perhaps the lack of a proper virtual buffer is helping, but that doesn't explain Marco's observations on win32 with accprobe.

Comment 15

[Zack Weinberg (:zwol)]

I misremembered which accessibility test case I was unable to reproduce with Orca.  Orca's behavior with Hg revision cc3f910bf168 is as follows:

* On page load: reads a lot of confused nonsense.
* Tabbing: starts with "review text" when the keyboard-traversal highlight is on the entire content pane, then subsequent tabs recite "hide link", "show link", "navigation toolbar ...", "search ...", back to "review text."
* Activate "hide": silence.
* Activate "show": reads "review"; tab sequence (content only) is now "text", "hide link", "show link", "text".

That looks to me like the same behavior seen with NVDA, modulo terminology changes ("text" instead of "edit multiline"); so there is a cross-platform bug here.  Does anyone know if there's a GNOME equivalent of AccProbe?

Comment 16

[Fernando Herrera]

Zack, there is accerciser for GNOME:

http://live.gnome.org/Accerciser

I have tested it and I confirm: after loading the text area has "labelled-by: review" relation. After hide/show, it lost it.

Comment 17

[alexander :surkov (:asurkov)]

when display block is set the accessible tree is created, then overflow style change triggers an accessible tree recreation, the accessible tree is created before hide event is processed and destroys relations (as side effect on subtree shutdown).

Comment 18

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 19

[alexander :surkov (:asurkov)]

(In reply to comment #18)
> Created attachment 511706 [details] [diff] [review]
> patch

I fixed unwanted changes in mochitests locally.

Comment 20

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

Comment on attachment 511706 [details] [diff] [review]
patch

r=me.

>+++ b/accessible/tests/mochitest/relations/test_update.html

>-      gQueue = new eventQueue();
>+      gQueue = new eventQueue();/*
>       gQueue.push(new insertRelated("aria-labelledby", "dependent3", true,
>                                     RELATION_LABELLED_BY, RELATION_LABEL_FOR));
>       gQueue.push(new insertRelated("aria-labelledby", "dependent4", false,
>                                     RELATION_LABELLED_BY, RELATION_LABEL_FOR));
> 
>       gQueue.push(new insertRelated("aria-describedby", "dependent5", true,
>                                     RELATION_DESCRIBED_BY,
>                                     RELATION_DESCRIPTION_FOR));
>@@ -126,16 +164,19 @@
>       gQueue.push(new insertRelated("aria-controls", "dependent10", false,
>                                     RELATION_CONTROLLER_FOR,
>                                     RELATION_CONTROLLED_BY));
> 
>       gQueue.push(new insertRelated("aria-flowto", "dependent11", true,
>                                     RELATION_FLOWS_TO, RELATION_FLOWS_FROM));
>       gQueue.push(new insertRelated("aria-flowto", "dependent12", false,
>                                     RELATION_FLOWS_TO, RELATION_FLOWS_FROM));
>+*/

Might as well delete this ^ but what about the tests for DESCR* and CONTROLLER*?

Comment 21

[alexander :surkov (:asurkov)]

(In reply to comment #20)

> Might as well delete this ^ but what about the tests for DESCR* and
> CONTROLLER*?

these are unwanted changes from comment #19 :)

Comment 22

[alexander :surkov (:asurkov)]

landed on 2.0 (fx4b12) - http://hg.mozilla.org/mozilla-central/rev/91debd04e05e

Comment 23

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

(In reply to comment #21)
> (In reply to comment #20)
> 
> > Might as well delete this ^ but what about the tests for DESCR* and
> > CONTROLLER*?
> 
> these are unwanted changes from comment #19 :)

Got it. Thanks :)

Comment 24

[Zack Weinberg (:zwol)]

Rev 447d780336cc WFM with Orca.

Comment 25

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre