[AccessFu] On some Wikipedia pages, document title is repeated whenever returning from a link

VERIFIED FIXED in mozilla15

Status

()

Core
Disability Access APIs
--
major
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: MarcoZ, Assigned: eeejay)

Tracking

Trunk
mozilla15
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
STR:
1. Open http://en.wikipedia.org/wiki/Kylie_Minogue in Firefox Android with AccessFu enabled.
2. Start navigating the article.

Notice that, whenever on a link and navigating to the next element, Talkback will repeat the document title again before reading the actual next chunk of text.

I also notice, with SoundBack enabled, that in these instances, often two clicks are heard, even though only one element is being moved forward.
(Assignee)

Comment 1

5 years ago
Yeah, that is an unfortunate regression.
Assignee: nobody → eitan
Severity: normal → major
(Assignee)

Comment 2

5 years ago
Created attachment 626093 [details] [diff] [review]
Do Presenter.tabSelected when tab's window receives focus.

Don't use the document focus event since it will happen now every time we blur a focasable child. Instead use the DOM focus event for the window of the tab.
Attachment #626093 - Flags: review?(dbolter)
Comment on attachment 626093 [details] [diff] [review]
Do Presenter.tabSelected when tab's window receives focus.

Review of attachment 626093 [details] [diff] [review]:
-----------------------------------------------------------------

r=me.

::: accessible/src/jsat/AccessFu.jsm
@@ +73,5 @@
>      this.chromeWin.addEventListener('DOMActivate', this, true);
>      this.chromeWin.addEventListener('resize', this, true);
>      this.chromeWin.addEventListener('scroll', this, true);
>      this.chromeWin.addEventListener('TabOpen', this, true);
> +    this.chromeWin.addEventListener('focus', this, true);

OK AIUI this will only happen when the tab changes (not as chatty as our a11y focus event for the document... which maybe we should fix in core).

@@ -309,5 @@
>            break;
>          }
> -      case Ci.nsIAccessibleEvent.EVENT_FOCUS:
> -        {
> -          if (this._isBrowserDoc(aEvent.accessible)) {

Only one consumer of _isBrowserDoc left but OK.
Attachment #626093 - Flags: review?(dbolter) → review+
Eitan assures me the a11y engine focus events are correct.

Comment 5

5 years ago
(In reply to David Bolter [:davidb] from comment #4)
> Eitan assures me the a11y engine focus events are correct.

I'm not sure how it goes with comment #2 "Don't use the document focus event since it will happen now every time we blur a focasable child." Does it happen for example if you tab by links?

The problem of DOM focus (and why we fire focus event on blur) is when focus goes to document (for example shift+tab from focusable element) then there's no DOM focus event (since DOM document stays focused). We coalesce focus events and thus usually we don't get two focus events but if this doesn't happen then somebody should debug that (i.e. why blur and focus events have timeout).

Also since you are switching to DOM focus then you don't get notifications for selects (comboboxes, listboxes), trees, menus navigation. Also you don't get proper notifications for ARIA activedescendant changes. If you need that then you regress probably worst than you win.
(Reporter)

Comment 6

5 years ago
FWIW, NVDA also focused focusable items when navigating by virtual cursor. If the next item the v cursor lands on is not focusable, the last focused item remains focused until something new focusable is reached. They never set focus back to the document in the interim.
(Reporter)

Comment 7

5 years ago
Also FWIW, there is no tabbing between links yet in Android.

Comment 8

5 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #6)
> FWIW, NVDA also focused focusable items when navigating by virtual cursor.
> If the next item the v cursor lands on is not focusable, the last focused
> item remains focused until something new focusable is reached. They never
> set focus back to the document in the interim.

Thanks, Marco. I see now what happens. It sounds as a way to go.

Comment 9

5 years ago
https://hg.mozilla.org/mozilla-central/rev/8344de0f1079
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
(Assignee)

Comment 10

5 years ago
(In reply to alexander :surkov from comment #5)
> (In reply to David Bolter [:davidb] from comment #4)
> > Eitan assures me the a11y engine focus events are correct.
> 
> I'm not sure how it goes with comment #2 "Don't use the document focus event
> since it will happen now every time we blur a focasable child." Does it
> happen for example if you tab by links?
> 

What we are doing is more similar to caret navigation. If you press right arrow through a link to regular text, the focus leaves the link and does back to the document.

> Also since you are switching to DOM focus then you don't get notifications
> for selects (comboboxes, listboxes), trees, menus navigation. Also you don't
> get proper notifications for ARIA activedescendant changes. If you need that
> then you regress probably worst than you win.

The only use for the focus event, at least now, is for document tab changes.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
Target Milestone: mozilla15 → ---
(Assignee)

Comment 11

5 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #6)
> FWIW, NVDA also focused focusable items when navigating by virtual cursor.
> If the next item the v cursor lands on is not focusable, the last focused
> item remains focused until something new focusable is reached. They never
> set focus back to the document in the interim.

We don't only set focus back to the document, we keep the caret at the vc position. So if you press tab (maybe on a bluetooth keyboard?) when the vc is in a non-focusable text, the focusable element after it will get focus, and not the first item on the doc.

To me this seems like a good way to harmonize virtual cursor and tab focus order.
(Assignee)

Updated

5 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
(Reporter)

Comment 12

5 years ago
Verified fixed in Fennec/15.0a1 2012-05-24 Android.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.