w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.2k stars 329 forks source link

Breadcrumb should define Keyboard Interaction #635

Open carmacleod opened 6 years ago

carmacleod commented 6 years ago

The Keyboard Interaction for the Breadcrumb pattern currently says:

Not applicable.

I think it should say that the links/locations/steps in the list must be navigable using the tab key (for a multi-tab-stop breadcrumb); or navigable using tab to give the breadcrumb focus and arrow keys to select the various links within the list (for single-tab-stop breadcrumb). In both cases, Enter to move to the selected link/location/step.

The reason I think it is misleading to say "Not applicable" is that I have seen breadcrumbs that were only mouse-clickable, and "Keyboard Interaction: Not applicable" may give the impression that mouse-only is a viable option for a breadcrumb... which it isn't.

ZoeBijl commented 6 years ago

The opening line for the breadcrumb design pattern:

A breadcrumb trail consists of a list of links to the parent pages of the current page in hierarchical order.

The link design pattern has some keyboard interactions listed:

Keyboard Interaction

  • Enter: Executes the link and moves focus to the link target.
  • Shift + F10 (Optional): Opens a context menu for the link.

Would it be enough to link to the link design pattern in the opening line of the breadcrumb one?

carmacleod commented 6 years ago

Sure! Sounds good to me. Thanks!

mcking65 commented 6 years ago

It should not go in the opening line of breadcrumb. If we did that, it would be under the keyboard heading. However, given the simplicity here, I think that is not very helpful to the reader. Also, it would not address a single-tab stop scenario.

carmacleod commented 6 years ago

If we did that, it would be under the keyboard heading.

Missing a "not"?

If we did that, it would not be under the keyboard heading.

carmacleod commented 6 years ago

Also, it would not address a single-tab stop scenario.

Good point @mcking65. Presumably single-tab-stop-with-arrows would be a decent alternative way to navigate through a breadcrumb. Screen reader would eat the arrows, though.

mcking65 commented 6 years ago

well, no .... I meant that if we were going to link to link to emphasize the need for kb support, we would need to do it in the kb section and get rid of the "not applicable" text.

We often cross-link patterns, but we do not do so wherever we mention link. One reason is that that might be interpreted as suggesting people should use the link pattern. We do not want to promote use of role link.

Net, I favor the original proposal, which is write up content for the kb subsection of the breadcrumb pattern.

mcking65 commented 6 years ago

No, if you have a single-tab stop breadcrumb, it would be in a single-row grid or toolbar so the screen readers that support auto mode change would pass through arrows.

carmacleod commented 6 years ago

we would need to do it in the kb section and get rid of the "not applicable" text.

Yep, that's exactly what I meant. Glad we're on the same page. Sorry to be confusing. I should have included the full quote and not just the last piece. Language is hard. ;)

if you have a single-tab stop breadcrumb, it would be in a single-row grid or toolbar

Really? That seems a little extreme, like stretching the semantics just to get the arrow keys passed through?

mcking65 commented 6 years ago

@mcking65 wrote:

if you have a single-tab stop breadcrumb, it would be in a single-row grid or toolbar

@carmacleod responded:

Really? That seems a little extreme, like stretching the semantics just to get the arrow keys passed through?

Not sure what you mean by extreme; there is no stretch here. The simplest grids can be super light weight grouping containers. In fact, in its most basic form, a grid is just a grouping container and breadcrumbs are just a group of links.

Toolbar is similarly useful for grouping, but the toolbar role carries some common conotations that are not totally harmonious with breadcrumbs so it is probably not the cleanest way to group breadcrumb links. So, I believe grid is the better choice.

carmacleod commented 6 years ago

Not sure what you mean by extreme; there is no stretch here.

My bad. I was thinking that there was a "breadcrumb" role, and that combining "breadcrumb" role with "grid" role felt like multiple inheritance. But (oops, of course) "breadcrumb" is just a pattern. So you are completely correct that the links can be inside the cells of a single-tab-stop, single-row grid labelled "Breadcrumb". Sorry for the distraction.

So, back to the original purpose of this issue: fixing up the keyboard interaction wording for breadcrumb so that authors don't get the mistaken idea that they don't need keyboard support...

Please note that, in addition to the Keyboard Interaction section in the pattern definition for Breadcrumb, there's also a Keyboard Support section on the Breadcrumb example page that says:

No keyboard interaction needed.

This needs to be fixed up as well.

ZoeBijl commented 6 years ago

I will take this on.

@mcking65 do you feel there’s need for a single-tab-stop example? We already have that in the grid example.

Proposal:

Links in the breadcrumb widget should be in the natural(?) tab order.

  • Tab: When focus moves into the breadcrumb, places focus on the first link. When the breadcrumb contains the focus, moves focus to the next element in the page’s tab sequence.
  • Enter: activates the link.
  • Shift + F10 (Optional): Opens a context menu for the link.