-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Reevaluate tab navigation interaction pattern #23706
Comments
What's the difference between bullets 1 and 4? Is 1 remove/deprecate I scoured the web for some relevant discussion around this design pattern and links that look like tabs: GOV.UKThere's a lot of good discussion from the GOV.UK team on this.
Other articles
I'm tempted to explore bullet points 2 and 3 a bit. There are plenty of examples around the web of "tab-looking" widgets are just implemented as navigation links. For example: GitHub Google Search GOV.UK |
Yeah, that was what I meant to convey; I updated the original to clarify. Based on some of those examples, I have a feeling it would be worth raising this to the Material Design team to explore option two above (changing the visuals of nav tabs) so that, while they kind of look like tabs in general, they're distinctive from the thing that the specification calls tabs (i.e., introduce a new component). |
@jelbourn Just so that I don't forget - one thing that might be worth doing in the meantime is removing the arrow key behavior between links in |
After some internal discussion, we've decided to try and run with 4: keep
These requirements are taken from https://www.w3.org/TR/wai-aria-practices-1.2/#tabpanel. Requirements 6-8 will be the most difficult to land because there is currently no |
A few options @crisbeto and I discussed:
If we did 2, we could add the new component / update |
@crisbeto, @jelbourn: PTAL at the WIP PR above if you have a sec. It turned out to be pretty easy to implement option 2, and only required 1-2 usage changes in g3. If we do go with 2, would we want to manually migrate all g3 usages to use |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
We currently support two interaction patterns for our tabs component: tablist + tab + tabpanel, and nav + anchor.
We've received feedback that the nav + anchor pattern can be confusing, since it looks like tabs, but behaves differently.
Furthermore, if these two interaction patterns are mixed, the inconsistency can be confusing for users. These issues would affected users with some degree of vision that use assistive technology to supplement their experience.
We should explore ways to reduce or eliminate the confusion here. Some options include (but are not limited to):
MatTabNavBar
)MatNavTabBar
, but change its interaction pattern)It's worth mentioning that using anchors is desirable for use cases where you want the URL to change and/or want to support opening in new browser tabs. Using routing to drive tab navigation also easily fits into Angular's route-based lazy-loading system.
cc @zelliott
The text was updated successfully, but these errors were encountered: