JumpTo: can't scroll to bottom of menu if not fully visible in viewport

[midvorak]

on the page of the patterns, we can access to to a menu by clicking on "alt" + "0". The issues is that it is hard to scroll on the menu: the menu is bigger than my screen and I can't scroll to see the bottom menu items because I am always send it back to the top of the menu.

[aardrian]

I am also seeing that issue.

A suggestion for a temporary fix is to amend the following CSS to the menu container:

.jump-to [role="menu"] {
  [ existing styles ]
  max-height: 90vh;
  overflow: auto;
}

The first style should keep the entire container within the viewport. The second should make the container itself scroll.

[midvorak]

For info, saw it in chrome, Version 101.0.4951.67

[mcking65]

@richnoah

Are we pulling the jumpto script from the aria-practices repo? Or, is it living in wai-aria-practices? I just want this issue in the same repo where the PR will be made.

I don't see it in the scripts directory in aria-practices.

[jongund]

Here is a an update to the SkipTo.js script to use the scripted shortcut instead of the HTML accesskey attribute and supports a scrollable list of headings and landmarks if the list is to large for the screen height.

https://github.com/paypal/skipto/tree/dev/v4.2/downloads/js

As per the conversation today, the APG will just switch from using "JumpTo" to using "SkipTo" to eliminate the need to maintain two separate code repositories and make it easier for other people to add the "SkipTo" functionality to their website.

[aardrian]

Not privy to the APG call — is the plan for fixing this issue going to address the container height and overflow, or is this control being completely replaced?

[jongund]

The update uses container height and overflow to fix the content overflow issue. JumpTo is a one off of the SkipTo code, so this is an attempt to harmonize the divergent branches and just use the more established SkipTo for deployment,

[aardrian]

Gotcha. Thanks for the explanation.

[midvorak]

Note : please create another ticket if you feel that it is relevant. And sorry for my English.

I am checking the menu to remember a bit the issue and I realize that the items in the jump menu are not coded as links and therefore:

1. they are not announced as links with a screen reader
2. navigating with the keyboard, they are not reachable when we click on tab to go from a link to the next.

So basically, it seems to me that that items of the jump menu do not respect 1.3.1 and 2.1.1 WCAG criterias

[jongund]

SkipTo is implementing the ARIA menu button pattern and the use of the menu roles provides screen reader users with information that they can use the cursor keys for navigation of the menu items. If link roles were used, screen reader users would assume that they would need to use the Tab key to move between items. If you feel that this is not an appropriate use of the menu button pattern, you should file an issue with the ARIA authoring practices.

I am not sure what your second point means, I guess I need clarification on the issue.

[midvorak]

What I mean is :

• like a normal menu, or a summary with possibility to reach a certain part of the content in the same page (also for "one page website" menu), it should be a link (a href)
  
• because it is not coded as a links, when using NVDA or jaws, the items of the menu are not announce as links and because there is no "a href" (or button tag), it is not reachable while you press on "tab". Normally, all interactive elements are reachable by typing on tab.

Now, digging into the code, I see that the title "landmarks" and "headings" (I don't know if there are more because of the bug I initially mentioned) are not read by the screen reader. I checked the DOM and I see they are embedded in a div with an attribut role="separator". So visually, we see the title but the screen readers do not say them.

[jongund]

I think there are two main points here.

1. Roles indicate the type of keyboard interaction, if the link role was used you would be telling screen reader users that they would need to use the TAB key, rather than the cursor keys to go between items. It would be nice if there was an ARIA role like "menuitemlink", but this does not currently exist and at least at this point has not been proposed as part of the ARIA spec. Probably because there are no platform accessibility APIs with this type of role.

2. There are grouping (e.g. role=group) labels for list of headings and landmark region menu items in the code and being communicated through accessibility APIs to screen readers. So they have the opportunity to announce, but most don't. The goal of the W3C ARIA-AT project is to identify these gaps in assistive technology use of accessibility information and to encourage improved support by screen readers. If you are interested in ARIA support in assistive technologies I would urge you to join the group.

[midvorak]

thanks, I will check that. Thanks a lot for your time and you precious answers.