Closed Bug 812187 Opened 10 years ago Closed 9 years ago

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

Categories

(Core :: Disability Access APIs, defect)

16 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: carolynmacleod4, Unassigned)

Details

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.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Version: unspecified → 16 Branch
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also CC'ing Jamie so he can take a look from the NVDA end of things.
CC+ Max Li (although he is probably busy with other stuff)
Severity: normal → major
Flags: needinfo?
Hi, Alex. I am not familiar with the needinfo flag. Does it mean that you need information from me (the reporter)?
Flags: needinfo?
(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.
thanks. The flag somehow got removed. I am putting it back.
Flags: needinfo?
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.
Flags: needinfo?
(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.
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).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
awesome, thank you, Jamie.
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?
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.
(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
Bug 872397 seems to be specific to the "@" character. Note that this issue with word offsets applies to all punctuation symbols, not just "@".
You need to log in before you can comment on or make changes to this bug.