aria-practices
aria-practices copied to clipboard
w3c
When are navigation links a Layout Grid
3.12 Grids lists navigation links as an example for Layout Grid and also provides an implementation.
I like it. Personally, I’d implement any list of links like this. Also, breadcrumbs and main navigation. For the latter it solves the problem of repeatedly tabbing threw the complete main navigation to get to the main content on each page.
But the example for breadcrumbs and also that for a Navigation Landmark are completely different. In contrast to the Layout Grid with navigation links they use list elements and have no special keyboard controls.
Now I am wondering. a) Is it valid to implement breadcrumbs and main navigations as Layout Grids instead of implementing the examples 4.3.6 Navigation Landmark and 3.4 Breadcrumb b) If not, do we need the Layout Grid pattern for navigation links at all? We could just implement them like 3.4 Breadcrumb instead.
Personally, I'm not a fan of using the grid list this way. It's fairly unexpected/non-standard for keyboard users at this stage, and having a giant "this is how you actually use our site" tooltip is interesting, but a bit heavy-handed. For simple navigation, users arguably expect to just TAB/SHIFT+TAB between links, particularly when it's only a handful of them...
I’m not that sure about the unexpected/non-standard statement.
As I understand WAI-ARIA, it aims at recreating the standard desktop experience on web pages (i.e. by mapping to the standard OS’s Accessibility API).
Now, if you take a look at how windows handles tabbing and arrow keys (in example the explorer in general, or more specifically the file-path-window as a substitute for breadcrumbs) it is exactly as described in LayoutGrid.
Then it always is unexpected and we don't beed the Navigation Links Grid.
And the actual problem is that there is no pattern description for the "expected variant".
The Navigation Links Grid is the only one regarding navigations.
In case it's helpful, the "single tab stop with arrow keys" versus "list of links with tab keys" navigation discussion has taken place before in other issues:
- https://github.com/w3c/aria-practices/issues/89
- https://github.com/w3c/aria-practices/issues/353
- https://github.com/w3c/aria-practices/issues/991
A lot of the discussion is about whether or not to use menu (which is single tab stop) versus nested lists of links (where tab focuses each link), however the concept is the same as using a layout grid to reduce the number of tab keys typed.
Looking at some of the government web sites (which are generally considered to be accessible), we can see that many of them have chosen to go with "list of tabbable links", and they rely on skip links to let people jump over (or to) the navigation regions.
- https://www.usa.gov/
- https://www.gov.uk/
- https://www.australia.gov.au/
The Canadian government site uses menu markup. They used to have a good example of a menubar, but I see that they have collapsed it into a single Menu button, which is unfortunate. I used to point to them as a good example of an accessible menubar site nav. I guess they ended up with too many top-level items. The Menu button is still a single tab stop, though, and it is still marked up as a menu with arrow key navigation, but now their entire site nav is hidden until the user activates the menu button.
- https://www.canada.ca/en.html
Of course, if there are multiple navs with quite a few links, that's a lot of tabbing. In the case of the BBC News web site, they have a "Skip to content" link, but screen reader users won't even know that they are skipping 2 levels of navigation. (They should probably add a "Skip to News navigation" link to fix that. :) It might be useful in cases like these to consider using single-tab-stop, but you would need to somehow communicate that to your users, maybe with an "Accessibility Help" skip link.
- https://www.bbc.com/news
So it really depends on your site, and on how willing you are to train users to use arrow keys. :) If there are other single-tab-stop controls on your page, like a grid, and/or a real honest application menu (File, Edit, View, etc), and/or a real honest toolbar (Cut, Copy, Paste, Bold, Italic, ...) then getting users to think "first I tab there, then I can use arrow keys" will be easier. This is an area where Usability Testing can really pay off.
@alrdytakn asked:
a) Is it valid to implement breadcrumbs and main navigations as Layout Grids instead of implementing the examples 4.3.6 Navigation Landmark and 3.4 Breadcrumb
Yes, it is indeed valid to use a grid inside of a breadcrumb nav region. We have issue #72, which is intended to do exactly that.
And, yes, we could do the same thing in the list of links in the nav regions of the landmark example pages. There are quite a few places in the APG where we could employ this pattern but have not yet done so.
b) If not, do we need the Layout Grid pattern for navigation links at all? We could just implement them like 3.4 Breadcrumb instead.
That is author choice. There are plenty of good reasons for either choice -- circumstances matter.
As you have pointed out, the potential UX improvements for screen reader and keyboard users offered by the grid pattern for sets of links can be really substantial. This is a very high-value pattern. I wish it were widely adopted.
That said, realizing that value is harder than we would like it to be, because the support for grids by assistive technologies still has issues. The intent of the ARIA-AT project run by the ARIA-AT community group is to address that specific barrier to wider ARIA value realization.
Gaps in ARIA support as well as authoring confusion have really meant that, as web GUIs have evolved over the last couple decades, they have not been able to fully adopt desktop GUI accessibility conventions. So, user expectations are still based on web 1.0 and WCAG 1.0 styles of interactions. As @patrickhlauke pointed out, this is "unexpected for a regular website's navigation/set of links..." Consequently, ancient, inefficient, band-aid techniques prevail today, so users are stuck spending an inordinate amount of time pressing keys, especially Tab, instead of enjoying content.
Patterns like the navigation grid provide approaches to making very large gains in simple ways. But, because of those legacy expectations, making them universally friendly does mean helping users along. Users need help understanding when to press an arrow key instead of Tab. Happily, this is asuper easy thing for anyone to learn. And, I am sure that once designers decide to help users in this way, there will be no shortage of creative solutions for achieving that objective. the pop-out help on the navigation grid example is just one attempt at inspiring that kind of design work.
Bottom line: I think you can use nav grids wherever they fit as long as you also do something to help sighted users know to use arrow keys to navigate inside the grid. As of today, none of the screen reader issues with grids create problems for that particular use of grids.
Where do they fit? Where you have 3 or more links in a set that is not hierarchical.
@alrdytakn, does this answer your questions?
