Mockups for same level navigation in Single Pattern and Single Practice pages

[isaacdurazo]

Text-based Mockups

These mockups incorporate a Side Navigation component to the left-hand side of a single Pattern page (same case for the single Practice), that takes all the viewport height and is independently scrollable from the main area of the page. This side navigation allows users to navigate between patterns without returning to the main Patterns page.

When looking at the page in smaller viewports, the side navigation is hidden and a patterns menu button is displayed in the header to show and hide the component. The appearance and functionality of this is the same one used on the WAI website

Visual Mockups

Desktop

Desktop - Sidebar collapsed

Mobile

[helen-libit]

For the desktop version, I like what @mcking65 and @a11ydoer suggested, making the left navigation sidebar (Patterns list) collapsible like the sidebar on the ARIA specification pages.

For the mobile version, I wonder if the Patterns list can be a drop-down menu so the Page Content menu is visible on the 1st screen and it doesn't take a lot of scrolling to get to the main content area.

[a11ydoer]

I like the destop version because it improves the usability by showing the pattern list on the left. Therefore, users can easily jump into any patterns they are interested in and have bird's eye view. Thanks so much, @isaacdurazo!

Regarding the mobile view, I have three comments.

1. Visual location and contents of "Pattern Menu" toggle button - the Pattern menu button is located above the global main menu although Pattern toggle menu, the list of patterns, is just one subset of the global main menu item, Pattern.

I see that this design is from WAI site like that of WAI Fundamental page However, the menu toggle in WAI site seems to be in the different context, mobile version of global menu unlike APG submenu toggle, Pattern menu. WAI toggle menu button is also confusing to me because menu toggle itself also revieals submenu list of "Fundamentals" at the same time. @shawna-slh Is that the correct understanding for WAI menu toggle button?

2. May be the "Pattern menu" can be "Pattern list" because the Pattern menu does not actually include the right subsection, "Page contents" of the Pattern?

3. Can we have a way not to scroll much in the mobile like Helen pointed above? (This could be extra feature though.)

[a11ydoer]

@shawna-slh @isaacdurazo If this is helpful, I attached the screen shots of WAI mobile menu toggle, which reveals global menu items and secondary menu at the same time.

[a11ydoer]

By the way, I used the word, "toggle" button for users's understanding, but it is navigation menu button in the WAI template coding with aria-haspopup and aria-expanded.

[mcking65]

From today's meeting:

• Put left nav after top nav and before table of contents in DOM order
• Put aria-label on nav element that matchesthe H2, e.g., "Patterns"
• Put aria-current="page" on the pattern that is currently displayed
• Avoid hacking template; coordinate with W3C WAI team to ensure left nav is outside main

[a11ydoer]

@shawna-slh can you give us some feedback on this issue?

[a11ydoer]

@daniel-montalvo will help us to communicate with WAI team.

[shawna-slh]

Thanks for the ping @a11ydoer and @daniel-montalvo

We are planning a significant redesign of the WAI website in 2023. I'd like to check in on @iadawn 's thoughts on this proposal in light of the bigger project. -- And, we've got a backload of work. What are schedule considerations on this from your perspective? Thanks.

[iadawn]

Couple of questions and points that jump to my mind:

• What is the problem that is being solved? Is it a real problem or a perceived problem... sorry, habitual first question from long years of people fixing things that didn't need fixing! 😁
• Primary vs secondary navigation reflow - The solution proposed for reflowing the navigation only reflows the secondary (left hand nav) and does not do anything with the primary main nav (APG Home, Patterns, Practices...). This is ok on the mock ups but a few more words or a slightly narrower viewport and that nav becomes difficult to use. The current approach is to put this in a scrolling div which I don't really see as ideal.
• Two scrolling areas - just following on from the scrolling primary nav, the solution proposed suggests a scrolling secondary nav. This would put two scrolling areas in the browser. I know from dim and distant usability testing that this can cause problems for some people. The main risk I would see with this is that users miss the scroll and don't find the items near the bottom of the list.

[mcking65]

@iadawn asked:

Couple of questions and points that jump to my mind:

• What is the problem that is being solved? Is it a real problem or a perceived problem... sorry, habitual first question from long years of people fixing things that didn't need fixing! 😁

User feedback tells us it is a real problem.

The problem is that the current path for moving from pattern X to pattern Y is:

1. Starting on the page for pattern X, activate the patterns link in the top APG nav bar
2. Scroll the patterns page to pattern Y.
3. Activate the link for pattern Y.

Given that people frequently explore and compare patterns, this three step process is undesirable overhead. With this patterns navigation sidebar on every pattern page, the process becomes a single step. For consistency, we would include the ability to navigate between practices on each practice page as well.

• Primary vs secondary navigation reflow - The solution proposed for reflowing the navigation only reflows the secondary (left hand nav) and does not do anything with the primary main nav (APG Home, Patterns, Practices...). This is ok on the mock ups but a few more words or a slightly narrower viewport and that nav becomes difficult to use. The current approach is to put this in a scrolling div which I don't really see as ideal.
• Two scrolling areas - just following on from the scrolling primary nav, the solution proposed suggests a scrolling secondary nav. This would put two scrolling areas in the browser. I know from dim and distant usability testing that this can cause problems for some people. The main risk I would see with this is that users miss the scroll and don't find the items near the bottom of the list.

I'll let visual design types respond to these two concerns. Proposals welcome.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Mockups for same level navigation in Single Pattern and Single Practice pages.

The full IRC log of that discussion

<jugglinmike> Subtopic: Mockups for same level navigation in Single Pattern and Single Practice pages
<jugglinmike> github: https://github.com//issues/2535
<jugglinmike> Matt_King: The issue related to the top navigation could be treated as something separate, right?
<jugglinmike> jamesn: I think so, yes
<jugglinmike> Matt_King: We may need to hold a call with Isaac, Kevin, and Sean in order to move this forward
<jugglinmike> jamesn: The W3C menu button doesn't appear to satisfy accessibility standards. For instance, the menu it opens is many "Tab" presses away
<jugglinmike> jongund: I agree; it doesn't seem like something we can use on APG
<jugglinmike> Matt_King: Do we need to get Isaac back in this meeting in order to re-present? Or is the material he provided in the issue sufficient?
<jugglinmike> jamesn: In Isaac's design, the position of the menu on mobile doesn't seem correct. If the focus automatically moves to the menu, then I might be okay with it
<jugglinmike> jamesn: On the WAI site design, the intermediate state (where one menu is collapsed and the other is not) is what concerns me
<jugglinmike> Matt_King: When the second nav is collapsed, where should the first one be positioned?
<jugglinmike> Matt_King: An action item is that Isaac should update the mobile version
<jugglinmike> Matt_King: is there anything about the desktop (or "full") view that should be updated?
<jugglinmike> jamesn: No, I'm okay with that
<jugglinmike> Matt_King: There also needs to be an affordance for collapsing the menu. It looks like there is a button at the bottom, but it should be right at the beginning
<jugglinmike> Matt_King: The current state should be rendered consistently in both navs
<jugglinmike> jongund: The underline makes it look like a heading to me
<jugglinmike> jongund: Maybe a vertical bar on the left side would avoid giving the appearance of a heading
<jugglinmike> Matt_King: When the second nav is collapsed, it is not positioned in the same place that it would appear if you were to expand it. The collapsed form of it and the expanded form of it should be in the same place
<jugglinmike> Matt_King: Also, two problems with the top menu. First is that it doesn't collapse on mobile, and the current state is visually communicated through color alone (which is a WCAG issue)

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Mockups for same level navigation in Single Pattern and Single Practice pages.

The full IRC log of that discussion

<jugglinmike> Subtopic: Mockups for same level navigation in Single Pattern and Single Practice pages
<jugglinmike> github: https://github.com//issues/2535
<jugglinmike> Matt_King: We discussed this during the last meeting
<jugglinmike> Matt_King: We're waiting on feedback from Shawn. I'll bump this with them

[daniel-montalvo]

Hi @isaacdurazo @mcking65 @helen-libit @a11ydoer

@iadawn asked:

• Primary vs secondary navigation reflow - The solution proposed for reflowing the navigation only reflows the secondary (left hand nav) and does not do anything with the primary main nav (APG Home, Patterns, Practices...). This is ok on the mock ups but a few more words or a slightly narrower viewport and that nav becomes difficult to use. The current approach is to put this in a scrolling div which I don't really see as ideal.
• Two scrolling areas - just following on from the scrolling primary nav, the solution proposed suggests a scrolling secondary nav. This would put two scrolling areas in the browser. I know from dim and distant usability testing that this can cause problems for some people. The main risk I would see with this is that users miss the scroll and don't find the items near the bottom of the list.

I'll let visual design types respond to these two concerns. Proposals welcome.

I don't feel in a position to propose a solution for these myself either, but I think it would be good to reply to @iadawn 's concerns with visual affordances here. Can anyone have a look at these?

[isaacdurazo]

Hi everyone, apologies for my late response.

With regard to your concerns, @iadawn:

Primary vs secondary navigation reflow - The solution proposed for reflowing the navigation only reflows the secondary (left hand nav) and does not do anything with the primary main nav (APG Home, Patterns, Practices...). This is ok on the mock ups but a few more words or a slightly narrower viewport and that nav becomes difficult to use. The current approach is to put this in a scrolling div which I don't really see as ideal.

I would like to focus the discussion here on the issue of same-level navigation between patterns. I agree with you about the current problem with the primary main nav on small viewports, but we should discuss that in a separate issue.

Two scrolling areas - just following on from the scrolling primary nav, the solution proposed suggests a scrolling secondary nav. This would put two scrolling areas in the browser. I know from dim and distant usability testing that this can cause problems for some people. The main risk I would see with this is that users miss the scroll and don't find the items near the bottom of the list.

I think that is a great point. Perhaps we can simply not have the side menu be independently scrollable and just make it part of the rest?