Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Caret browsing to a text input using arrow keys should focus it




Keyboard: Navigation
10 years ago
7 years ago


(Reporter: Mats Palmgren (vacation - back in August), Unassigned)


({access, top100})

Firefox Tracking Flags

(Not tracked)



Spawned off from bug 311376 comment 62 and 63.

Caret browsing to a text input using arrow keys should focus it, to allow
text to be entered.

0. turn on caret browsing (use F7 key or set "accessibility.browsewithcaret"
   preference to "true" manually in about:config)
1. load URL
2. click on the page background
3. using the arrow keys only - navigate to the text input
4. type something

Text is not entered into the input (typing ' or / triggers FAYT).
Workaround: do a mouse click on the text input or TAB/Shift+TAB

The text input should gain keyboard focus when the caret is inside it.

Bug occurs in Firefox, and trunk on Linux.

Comment 1

10 years ago
I'm new to a11y, admittedly, but I don't think this is a good idea. How do you propose the user gets out of the box? tab/shift-tab will focus the next control, not the text after it (and clearly we can't change that behaviour) and arrowing out doesn't work. The user will be stuck, and the next control might be a lot further down the page (or worse, at the top of the page/UI, if this is the last one).
(In reply to comment #1)
> How do you propose the user gets out of the box? 

Using arrow keys.  If one can move the caret into a text control using them,
then I think it's reasonable to use the same keys to move it out again.
(except if it's a selection movement of course...)

If the element doesn't gain kbd focus then I don't see the point of moving
the caret inside the text control in the first place.

Note that with the default UA stylesheet it's impossible to see whether a
text input has focus or not, other than the blinking caret.  I think it's
confusing to have a blinking caret in a text control that doesn't have
kbd focus and thus do not allow typing, and that ' and / triggers FAYT.
Blocks: 241023

Comment 3

10 years ago
Unfortunately what you're proposing is just as confusing as current situation - because there are two states of "editing a textbox", one from a mouse click (or tab) where you can't leave and one from caret navigation in which you can.

I propose to leave current behaviour as it is, but perhaps change the way it *looks* to make it obvious that caret-in-a-textbox is not the editing caret and box is not focused. Currently the two states look identical, at least on windows.

Also, enter could focus the text box, much like it currently follows links.

Comment 4

10 years ago
setting platform all as it occurs also on vista

--> as the carret can be placed inside the text area with arrows and navigate also inside it, i believe that enter must at minimum give the focus to it ...
OS: Linux → All


10 years ago
Blocks: 382192


8 years ago
No longer blocks: 382192


7 years ago
Blocks: 560270


7 years ago
No longer blocks: 560270
You need to log in before you can comment on or make changes to this bug.