812187 - Screen readers say "blank" on first word of line when navigating by word

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Carolyn MacLeod]

Firefox 16.0.2

Go to this link: https://orion.eclipse.org/examples/textview/demo.html
Use arrow keys to move around in the editor.
Use down arrow to move to the first function (starting about line 20):
	function getWindow(document) {
		return document.defaultView || document.parentWindow;
	}
Use control+right/left arrow to move forward/back one word at a time through this function.

Now start up a screen reader (I tried this with JAWS 14.0 and NVDA 12.2.1). As you move forward by word through this function, notice that the first word of each line (function, return) is not spoken (or is spoken as "blank"). The screen reader does not recognize the first word on a line as a word. It will read the characters if you use right/left arrow (no ctrl). It will read the whole line if you use up/down arrow. But if you use ctrl+right/left arrow, the word is not spoken.

Comment 1

[Marco Zehe (:MarcoZ)]

With Nightly 19.0a1 and NVDA 2012.3, I see even more problems. The braille display often doesn't update when arrowing up and down, only left and right sometimes make it update. Speech speaks the wrong line often, too, lags behind one or two lines.

My suspicion is that there are quite a number of problems exposed that our NSIAccessibleText interface currently has.

Comment 2

[Marco Zehe (:MarcoZ)]

Also CC'ing Jamie so he can take a look from the NVDA end of things.

Comment 3

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

CC+ Max Li (although he is probably busy with other stuff)

Comment 4

[Carolyn MacLeod]

Hi, Alex. I am not familiar with the needinfo flag. Does it mean that you need information from me (the reporter)?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Carolyn MacLeod from comment #4)
> Hi, Alex. I am not familiar with the needinfo flag. Does it mean that you
> need information from me (the reporter)?

not necessary from you. Somebody needs to debug what happens.

Comment 6

[Carolyn MacLeod]

thanks. The flag somehow got removed. I am putting it back.

Comment 7

[James Teh [:Jamie]]

Gecko word offsets have been pretty broken since the beginning with respect to preceding punctuation and indentation. It's been a severe annoyance for me for years, but I've never been able to figure out exactly what's going on except that word offsets are incorrect in these cases.

In this particular case, the word "function" begins at offset 1196. IAccessibleText::textAtOffset(1196, IA2_TEXT_BOUNDARY_WORD) returns offsets (1191, 1192), which points to the space before "*/" on the previous line. Interestingly, offset 1197 correctly returns offsets (1196, 1205)  for "function ". As noted above, the problem relates to both preceding indentation and preceding punctuation. You have to remove both the "*/" and the tab character to get normal functionality.

Comment 8

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #1)
> With Nightly 19.0a1 and NVDA 2012.3, I see even more problems. The braille
> display often doesn't update when arrowing up and down, only left and right
> sometimes make it update. Speech speaks the wrong line often, too, lags
> behind one or two lines.
I think this is a separate issue, though it's still concerning. I've not seen this with other editable text controls, whereas the word offsets problem is common to all of them. It looks like caret movement in this control is a bit slow and while it is moving, retrieval of text offsets somehow becomes unstable.

Comment 9

[James Teh [:Jamie]]

The test case appears to be gone. However, the general issue seems to be fixed now, probably due to the recent refactoring of word offsets calculation.

Wfm in Firefox 23.0a1 (2013-04-09).

Comment 10

[alexander :surkov (:asurkov)]

awesome, thank you, Jamie.

Comment 11

[Carolyn MacLeod]

Sorry, Jamie. The Orion textview demo was moved to here:
https://orion.eclipse.org/examples/editor/demo.html

I can't update FF at the moment and this is still failing on FF 21.0.
Do you have a moment to test it on your FF 23?

Comment 12

[James Teh [:Jamie]]

The issue reported here is fixed, though there is still some other weirdness related to punctuation. For example, in "@private", when querying word offsets for the "@", Gecko reports the offsets for "private". I suspect this isn't new and I think there might be a bug for it already.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #12)
> The issue reported here is fixed, though there is still some other weirdness
> related to punctuation. For example, in "@private", when querying word
> offsets for the "@", Gecko reports the offsets for "private". I suspect this
> isn't new and I think there might be a bug for it already.

I filed a bug 872397

Comment 14

[James Teh [:Jamie]]

Bug 872397 seems to be specific to the "@" character. Note that this issue with word offsets applies to all punctuation symbols, not just "@".