UI/Accesibility: Breadcrumbs in the document index

Good afternoon!
When working on XWIKI-20696: Accessibility best-practice: use landmarks in view pages (Jira issue & PR), we had a discussion with @MichaelHamann about the breadcrumb on document tables like the one in the Index of the wiki.

The Index page after the PR changes, with every landmark highlighted in a pink square
20696-NavigationPanelFixed

Where the issue arose:
A. We want landmarks on wiki pages. Breadcrumbs as they are very much fit the bill for being <nav> (a landmark role) elements.
B. We have one breadcrumb for every entry in document tables, to show location of the document.
C. From MDN web docs: " Landmark roles are intended to be used sparingly, to identify larger overall sections of the document. Using too many landmark roles can create “noise” in screen readers, making it difficult to understand the overall layout of the page."

A, B and C are not compatible together AFAIK.
The solutions:

  1. Let A off: we remove the landmarks from the breadcrumbs in tables.
  2. Let B off: we replace the breadcrumb in tables by another “simpler” element that just displays the location of the document, without links.
  3. Let C off: we ignore the recommendation on those pages and just go with a cluttered UI for screen reader users.

No solution is perfect here, and @MichaelHamann figured that we should ask on the forum to reach some consensus to close/merge this PR some day :slight_smile:


My opinion:
-1 for 1. The breadcrumb ‘brick’ of UI should be the same whatever the place, making an exception for this seems like just bad UI practice.
+1 for 2. I think the visual UI looks already cluttered and there’s way too many interactive elements on the page. For me, we should fix this usability shortfall first. One issue of this would be to reduce possible interactions, which could be a slight regression on usability for power-user.
+0 for 3. This is the easiest choice, and the {{documents}} macro that generates such problematic tables are not on every page, it’s rare enough that we can manage a bit of user unfriendliness. It’s not a “hard” WCAG rule or break of ARIA and I think going against the recommendation here would make sense.


What do you think of those solutions?
Is there an easier solution that would conciliate all three requirements?

Thank you for your help!
Lucas Charpentier

The breadcrumb at the top is very different from the breadcrumbs in the table: it also contains sub-trees to quickly navigate to other pages that aren’t shown in the main breadcrumb so this is a lot more of a navigation element than the breadcrumbs in the table. Therefore, I’m for solution 1.

1 Like

+1 for 1
First the entries in that table row show the location. Second they are probably used for navigation. XWiki users will easily learn, that location in XWiki often is shown with clickable links of spaces.
I wouldn’t let C off. And breadcrumbs are singletons and show the location of the current site.

Same as Michael, +1 for 1.

-0 for 2 because I think it’s useful to be able to navigate from the live data to an ancestor of the listed wiki page.

Thanks,
Marius

Thank you for your feedback! :slightly_smiling_face:

Implemented solution n°1 in XWIKI-20696: Accessibility best-practice: use landmarks in view pages by Sereza7 · Pull Request #2133 · xwiki/xwiki-platform · GitHub

Have a good day!

Lucas C.

1 Like