Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus-based navigation #1608

Open
Hixie opened this issue Feb 4, 2016 · 7 comments

Comments

@Hixie
Copy link
Contributor

commented Feb 4, 2016

We should implement next/prev (tab) and direction (d-pad) navigation of focusable controls, and ensure that everything is keyboard-accessible.

From http://developer.android.com/guide/topics/ui/accessibility/checklist.html:

Make sure users can navigate your screen layouts using hardware-based or software directional controls (D-pads, trackballs, keyboards and navigation gestures). In a few cases, you may need to make user interface components focusable or change the focus order to be more logical for user actions.

@Hixie Hixie added this to the Flutter 1.0 milestone Feb 4, 2016

@Hixie

This comment has been minimized.

Copy link
Contributor Author

commented Feb 4, 2016

@Hixie Hixie modified the milestones: 4: Make shippers happy, 5: Make Hixie proud Jan 26, 2017

@goderbauer goderbauer added this to VoiceOver Navigation in Accessibility Jun 27, 2017

@jonahwilliams

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2018

Is focus order the same as the traversal order? If so, we can simply reuse the semantics tree to handle focus traversal, with an additional focus state. Although I am concerned we would end up with two different concepts of focus.

cc @jslavitz

@Hixie

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2018

We can't use the semantics tree, it's not created if semantics are disabled.

@jonahwilliams

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2018

Turning on semantics when we detect tab navigation seems reasonable to me. The information needed to do focus based navigation is the same.

@gspencergoog

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2018

Focus navigation order could very well be different from semantics order. For instance, for focus navigation you probably want to skip the labels in the form, but you don't want to skip them in semantics traversal.

@jonahwilliams

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2018

The focus tree is a subset of the semantic tree though (right?).

@gspencergoog

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2018

Maybe? They feel like different use cases, so I wouldn't be surprised to learn that there are cases where it isn't a simple subset.

@flutter flutter deleted a comment from khalithartmann Dec 7, 2018

gspencergoog added a commit that referenced this issue Apr 22, 2019

Implement focus traversal for desktop platforms, shoehorn edition. (#…
…30040)

Implements focus traversal for desktop platforms, including re-implementing the existing focus manager and focus tree.

This implements a Focus widget that can be put into a widget tree to allow input focus to be given to a particular part of a widget tree.

It incorporates with the existing FocusScope and FocusNode infrastructure, and has minimal breakage to the API, although FocusScope.reparentIfNeeded is removed, replaced by a call to FocusAttachment.reparent(), so this is a breaking change:

FocusScopeNodes must now be attached to the focus tree using FocusScopeNode.attach, which takes a context and an optional onKey callback, and returns a FocusAttachment that should be kept by the widget that hosts the FocusScopeNode. This is necessary because of the need to make sure that the focus tree reflects the widget hierarchy.

Callers that used to call FocusScope(context).reparentIfNeeded in their build method will call reparent  on a FocusAttachment instead, which they will obtain by calling FocusScopeNode.attach in their initState method. Widgets that own FocusNodes will need to call dispose on the focus node in their dispose method.

Addresses #11344, #1608, #13264, and #1678
Fixes #30084
Fixes #26704

gspencergoog added a commit that referenced this issue Apr 25, 2019

[Re-Land] Implement focus traversal for desktop platforms. (#31614)
This re-lands the Focus changes in #30040. Correctness changes in routes.dart, and removes the automatic requesting of focus on reparent when there is no current focus, which caused undesirable selections.

Addresses #11344, #1608, #13264, and #1678
Fixes #30084
Fixes #26704

@gspencergoog gspencergoog added this to To do in Desktop Features May 2, 2019

@gspencergoog gspencergoog moved this from To do to In progress in Desktop Features May 2, 2019

gspencergoog added a commit that referenced this issue May 15, 2019

Implements focus handling and hover for Material buttons. (#31438)
This implements focus and hover handling for Material buttons. It inserts Focus widgets into the tree in order to allow buttons to be focusable via keyboard traversal (a.k.a. TAB traversal), and Listener widgets into the InkWell to allow the detection of hover states for widgets.

Addresses #11344, #1608, and #13264.

@gspencergoog gspencergoog self-assigned this May 16, 2019

@stuartmorgan stuartmorgan added this to To do in macOS MVP Jun 11, 2019

@stuartmorgan stuartmorgan added this to To do in Windows MVP Jun 11, 2019

@stuartmorgan stuartmorgan added this to To do in Linux MVP Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.