Bug 76797
| Summary: | [Gtk] Entries should be arrow-out-of-able | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Joanmarie Diggs <jdiggs> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | bugs-noreply, chrys87, mario |
| Priority: | P2 | Keywords: | Gtk |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 25531 | ||
Joanmarie Diggs
+++ This bug was initially created as a clone of Bug #76796 +++
Steps to reproduce:
1. Launch Epiphany and enable caret navigation (if it is not already enabled) by pressing F7.
2. Load a page with entries (e.g. https://bugs.webkit.org/enter_bug.cgi?product=WebKit).
3. Tab to an entry. Type some text (optional). Then press Left/Right Arrow to exit the entry.
Expected results: You would be able to exit the entry via Left Arrow when the caret is at the beginning of the entry and via Right Arrow when the caret is at the end of the entry.
Actual results: You cannot arrow out of the entry.
Impact: Users who are blind and accessing content by caret navigation can get "stuck" in a focused entry. To get unstuck, they must then move focus out of the form field (e.g. by Tabbing to a nearby link). Finally, to continue reading the content, they must backtrack to the entry and then arrow around it. This is especially inefficient. It would be beyond awesome if WebKitGtk's native caret navigation could handle this case.
BTW: Placing in component Accessibility now for Mario's consideration/triage and reassignment to the more appropriate component.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
chrys
Confirmed as described. This is really frustrating :/. I often run into this problem.