A11y word breaks out of sync with keyboard navigation
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | unaffected |
firefox116 | --- | unaffected |
firefox117 | --- | unaffected |
firefox118 | + | disabled |
firefox119 | --- | disabled |
firefox120 | --- | fixed |
People
(Reporter: Jamie, Assigned: m_kato)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(4 files)
STR (with the NVDA screen reader):
- Open this test case:
data:text/html,<input type="text" value="ab'cd">
- Focus the text input.
- Press home to move to the start of the text.
- Press control+rightArrow.
- Expected: NVDA says "cd"
- Actual: NVDA says "ab'cd"
Impact: Screen reader users can't work out where word boundaries are in the presence of punctuation. They will be confused by double speaking and won't know where the caret has actually moved.
Even though the caret lands on "c" (so keyboard navigation treats "ab'" as one word and "cd" as another word), accessibility treats the word as "ab'cd". Accessibility and keyboard navigation must be in sync at all times with respect to how word boundaries are calculated.
Setting intl.icu4x.segmenter.enabled to false fixes this.
Reporter | ||
Comment 1•1 year ago
|
||
As I understand it, intl.icu4x.segmenter.enabled is supposed to change everything to use the new segmenter. Why then does keyboard navigation (I guess PeekOffset, etc.) seem to be using different segmentation?
Do we need to fix keyboard navigation here? Or is the correct fix to disable the icu4x segmenter for accessibility word breaking? Or something else?
Comment 2•1 year ago
|
||
Set release status flags based on info from the regressing bug 1719535
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 3•1 year ago
|
||
Hmm, I think that WordBreaker::FindWord
returns different result...
This new segmenter is Nightly only. so we won't turn on release 118 until all regressions are fixed.
Reporter | ||
Comment 4•1 year ago
|
||
Note that layout has some code (in ClusterIterator, IsSelectionInlineWhitespace, IsSelectionNewline, etc.) to handle punctuation and white space. A11y needs to emulate layout word breaks, so it has similar code... but we can't reuse the same code because the layout code is entangled with layout frames. This will probably make unifying this behaviour a little tricky.
Comment 5•1 year ago
|
||
Set release status flags based on info from the regressing bug 1719535
Assignee | ||
Comment 6•1 year ago
|
||
Hmm, Although I setup with NDVA 2023.1jp, NVDA says "ab'cd" on Firefox 117. How to reproduce this?
Assignee | ||
Comment 7•1 year ago
•
|
||
I guess that sample is invalid. I am looking for valid sample.
Reporter | ||
Comment 8•1 year ago
•
|
||
The test case is valid. The tricky part here is that with intl.icu4x.segmenter.enabled set to true, the caret movement behaviour with control+rightArrow doesn't change, but what is returned by a11y does change when it shouldn't.
Reporter | ||
Comment 9•1 year ago
•
|
||
[Removed incorrect comment.]
Assignee | ||
Comment 10•1 year ago
•
|
||
I can reproduce this by the following step. Original step doesn't move caret by Ctrl+Arrow.
- Open
data:text/html,<input type="text" value="ab'cd">
. - Focus textbox
- Blur textbox
- Focus textbox again.
- Input any text in textbox then remove it
- Move caret to head
- Ctrl+Arrow
Reporter | ||
Comment 11•1 year ago
|
||
Ah, that's because tabbing to the text box selects all text. Sorry, i was focusing with NVDA browse mode rather than tab, which does not select all.
An easier way to work around this is to tab to the text box, press left arrow, and then press control+right arrow.
Assignee | ||
Comment 12•1 year ago
|
||
Ah, that's because tabbing to the text box selects all text. Sorry, i was focusing with NVDA browse mode rather than tab, which does not select all.
I see.
Hmm, "ab'cd" should be 1 word by UAX#29 spec. But nsFrameSelection
(or nsTextFrame?) doesn't recognize this is 1 word. We should fix on layout side.
Reporter | ||
Comment 13•1 year ago
•
|
||
Reporter | ||
Comment 14•1 year ago
|
||
The layout.word_select.stop_at_punctuation and layout.word_select.stop_at_underscore prefs are probably relevant here. Should those even be relevant with icu4x?
Assignee | ||
Comment 15•1 year ago
|
||
(In reply to James Teh [:Jamie] from comment #14)
The layout.word_select.stop_at_punctuation and layout.word_select.stop_at_underscore prefs are probably relevant here. Should those even be relevant with icu4x?
Yes. we guess that we should reference this even if using ICU4X.
Assignee | ||
Comment 16•1 year ago
|
||
Remove duplication code.
Assignee | ||
Comment 17•1 year ago
|
||
This fix adds stop at punctuation mode for FindWord for a11y.
Also, IS_ASCII is conflict with nsUnicharUtils.h's, so it is renamed.
Depends on D188784
Assignee | ||
Comment 18•1 year ago
|
||
Depends on D188785
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 19•1 year ago
|
||
Assignee | ||
Updated•1 year ago
|
Comment 20•1 year ago
|
||
Backout for causing gv-junit failures.
- backout: https://hg.mozilla.org/integration/autoland/rev/340ff5b040db29059fa1e5f7c6c4b6ed7fb44093
- push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=VbncKDJORHOZ1i3DCuE0AA.0&revision=d1fc71cc3817fe3529b10939ed53c1d395a346fa
- failure log: https://treeherder.mozilla.org/logviewer?job_id=430595871&repo=autoland&lineNumber=2007
Assignee | ||
Comment 21•1 year ago
|
||
GeckoView runs a11y code in UI thread, not Gecko main thread. So I would like
to change layout.word_select.stop_at_punctuation to atomic.
Depends on D188786
Comment 22•1 year ago
|
||
Comment 23•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cbf382972a0c
https://hg.mozilla.org/mozilla-central/rev/e1f0c76f6fa7
https://hg.mozilla.org/mozilla-central/rev/0320eac255f1
https://hg.mozilla.org/mozilla-central/rev/ac94b9a48562
Assignee | ||
Updated•1 year ago
|
Description
•