caret shouldn't be moved to clipped area which is caused by overflow: hidden; in caret browsing mode?

NEW
Unassigned

Status

()

Core
Keyboard: Navigation
5 years ago
5 years ago

People

(Reporter: masayuki, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Currently, user input doesn't cause scrolling any non-editable overflow: hidden; elements. See the URL's testcase. When you set caret to the blue-dashed border box and move the caret by down arrow key, you cannot see the caret if it's moved to the clipped line.

I think that caret shouldn't cause scrolling non-editable overflow: hidden; elements. If it's correct, it may be better that caret cannot be moved to the clipped area since user may be confused by missing caret.

Other possible fix against "missing caret" is, making caret always painted top most layer like outline. However, this approach probably makes another issue. E.g., User would see caret in a blank area or over another content. It may cause user confused.

Comment 1

5 years ago
I think we need to loop in the a11y folks.

Comment 2

5 years ago
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #0)

> I think that caret shouldn't cause scrolling non-editable overflow: hidden;
> elements. If it's correct, it may be better that caret cannot be moved to
> the clipped area since user may be confused by missing caret.

Caret is implementation of keyboard focus, the focus must be perceivable.

But you know we have one exception: the focus may go into shadow content of canvas. It's assumed the author should take care of focus perceptibility.

> Other possible fix against "missing caret" is, making caret always painted
> top most layer like outline. However, this approach probably makes another
> issue. E.g., User would see caret in a blank area or over another content.
> It may cause user confused.

agree
You need to log in before you can comment on or make changes to this bug.