docs: up/down keys do not scroll content area

[adrianandreias]

Up/down keys don't work in documentation. Neither do page up/down keys.

They don't work in any of the documentation pages, i.e.:
https://material.angularjs.org/0.9.4/#/

Clicking to focus on the content div on the right of the page doesn't help.

Tested with latest Chrome on Windows: Version 43.0.2357.65 m

This reproduces with current master HEAD as well.

[ThomasBurleson]

@adrianandreias

• Why do you expect the up/down arrow keys to work?
• Are you referring to the sidebar list on the left?

When you select a sideNav item to navigate to new content... we change the focus to the content area. You can use the Tab keys to navigate with the keyboard.

@marcysutton - any additional thoughts here?

[adrianandreias]

Forgot to mention: I have a vertical scroll bar on the right. The content does not fit on the screen.
These keys would work on any regular web page.

[marcysutton]

Arrow keys work on a page that isn't split into separate scrolling columns–what you're seeing may be a bug with Flexbox. If you notice, clicking to focus on the primary column when it overflows and hitting SPACE does not scroll, either. This is the nature of webapps that use this type of layout. We may have to re-implement the browser's scrolling behavior in overflowing columns, which doesn't sound trivial.

This looks similar to the page scrolling limitation I reported on mobile Safari with Voiceover: #2315

If you can find examples of web-app layouts like this that do support arrow and space keys for scrolling, we'd love to see them.

[adrianandreias]

As far as I know a regular iframe and even a div: once they have the focus arrow keys just work.

[joshribakoff]

+1

You can rationalize the "broken" arrow keys all you want, but as a user I expect to simply click on something that has a scrollbar, and press my arrows, and this expectation is broken. Seems like a common theme that this material design trades away usability in favor of eye candy.

@marcysutton Here's an example of a "web app" with an overflow div that I can focus & scroll - http://embed.plnkr.co/4jERkO/preview I know you use flex columns so it is different, but can't the functionality be polyfilled somehow? Seems like if flex is the issue, then flex is not ready for web use.

Also FYI the suggested workaround for navigating the documentation does not work. If I press tab it focuses each nav element one by one. After pressing tab many dozens of times the Chrome URL bar gets focus at which point I can no longer tab away without mouse interaction. At no point am I able to tab or click to focus the content & simply use arrow keys. A version of the documentation that is accessible is essential or [some] people will just pass this material design by & use some other framework.

[ThomasBurleson]

@marcysutton - Looking at a Github issue UX appears to support your posit. Yet the Slack web app has a UX the supports arrow key scrolling in the main content area (on the right); it appears that they are using a custom jquery scroll component 'monkey_scroll'.

Adding this UX feature to our docs (and perhaps to mdContent) may have impacts on other components... so we will approach this with care.

@adrianandreias, @joshribakoff - The simple answer is that we have not yet implemented this feature; nor explored all the ramifications of such features in mdContent. Our team has been extremely busy with component implementations, doc improvements, and bug fixes.

I think this is will be a usability win... please be patient while we keep focused and fast track to a version 1.0 release of Angular Material.

[adrianandreias]

👍 the truth is there are more pressing issues in the milestones. This is a "nice to have" right now.

[doug65536]

This is not assigned properly is it? The problem has nothing to do with docs. Angular material itself has the bug (and yes, non-working movement keys are a bug, let's be real here).

[wilzbach]

+1 for removing this from the backlog ;-)

[scottrodoty]

Sorry for the comment spam, but here's a strong +10 for getting this to work. I have been working to get my organization to adopt angular material, knowing that it is not complete, but this issue is a showstopper, and will prevent us from moving forward with Angular Material on a desktop web app.

[vort3xxx]

+1
Please read the intro for section 3.1.1 in http://www.w3.org/WAI/PF/aria-practices/#keyboard
It spells out what most of the first world is using for minimally acceptable keyboard standards in the web application space.

[doug65536]

The backlog? The backlog is more important than user's ability to scroll as they wish? I have dropped angular material, it is a toy, not suitable for real applications.

[joshribakoff]

@doug65536 I'm pretty sure "removing this from the backlog" was intended as another way of saying "fixing the scrolling, so it works properly". The devs also clearly stated in a previous post that "I think this is will be a usability win". For what its worth I also dropped angular material out of my app, since its taking so long.

[ferc]

+1

Do you have any temporal solution for this issue? I can't use arrows, page up/down, space or any key to navigate in the views.

[ferc]

The current problem is the tabIndex="-1" in the index.html:

<div layout="column" tabIndex="-1" role="main" flex>

When I remove that, I can focus the content and I can scroll with the keys.

If somebody knows why exists that tabIndex="-1" (maybe fix something) please tell me.

[marcysutton]

Tabindex is there so that container is programmatically focusable, since it is a main landmark. I wonder if flex attributes could be applied to a child element instead so they aren't impacted by tabindex. I've seen weird collisions like that with flexbox.

[Splaktar]

OK, it's time to finally fix this for the docs site. If you have a similar issue that is related to md-content or some other AngularJS Material component, please open a new issue with a reproduction.

Currently this "Skip to content" button is hidden unless focused

We already support Navigating by headings. But we can't say that's good enough and drop the "Skip to content" hidden button feature because we need to support keyboard-only users who aren't using a screen reader.

I investigated using the "Skip Navigation" link approach with element ids and named anchors. However, I abandoned this approach because it only seemed to work the first time. Afterwards, when activating the link (when the #maincontent is already in the URL), nothing happens.

As noted in #2961 (comment), the root problem is adding a tabindex="-1" to the main scrollable content element. While it is nice to be able to focus the entire main content area, the real goal here is to be able to skip from the navigation links directly to the main content area. This doesn't require a tabindex="-1" on the top level container, but it does require a tabindex="-1" on a common element at the top of every page (ideally the first header).

On our docs site, we have a md-breadcrumb header (<h2>) at the top of every page. I've moved the tabindex="-1" from the previous main content area <div> (and converted that <div> to a <main>) to the md-breadcrumb <h2>. This means that this "main" header can be reached both via traversing the list of headers in a screen reader and via the "Skip to main content" link.

In addition to the above, I'm converting the "Skip to main content" button to an icon button (right chevron) with a tooltip and I'm making it visible in the header by default.

[JonathanHuot]

Sorry @Splaktar, but this issue is now fixed.

I read the PR and indeed, it increases the ease of navigation for screenreader/ keyboard-only, as suggested by the WebAIM specification.

However, the mouse+keyboard users have not the UX improvement they deserve. If you read the initial issue description, the exact same behavior happen.

Up/down keys don't work in documentation. Neither do page up/down keys.

They don't work in any of the documentation pages, i.e.:
(..)

Clicking to focus on the content div on the right of the page doesn't help.

This is the basic of navigation for every website and this framework does not seem to solve that. You can't force the users to click on "Focus main content header" before navigating the md-content with keyboard. That's barely a workaround, but not a fix.

[Splaktar]

Sorry @Splaktar, but this issue is now fixed.

@JonathanHuot you mean not fixed?

Have you checked https://material.angularjs.org/HEAD/? It isn't part of a release yet, but it will be in 1.1.19 and beyond.

[RoyceBArockiasamy]

Is this up/down keys do not scroll content area issue fixed?

[Splaktar]

Is this up/down keys do not scroll content area issue fixed?

@RoyceBArockiasamy yes. Fixed in v1.1.19.

If you have questions about how your app is working please ask on Stack Overflow, Gitter, or the AngularJS Material forums.

If you've identified a new bug that you can provide a StackBlitz or CodePen reproduction for, please open a new issue.