element.focus() in $mdSidenav causes page jump

[nolandubeau]

Hi,
I am building an application which has a layout similar to the angular material design site. At the very top of the page however, is another md-toolbar. Below the first toolbar is the sidenav and the main content area.

With a layout like this when the sidenav is finished opening, element.focus() is called. This causes the page to focus to the sidenav toolbar top, and causes the toolbar above the sidenav to be partially visible (since the page has scrolled). Is it really necessary to have the element.focus() in the updateIsOpen function? If I comment out element.focus(), the issue is fixed.

if (scope.isOpen) {
//element.focus();
}

[marcysutton]

Focus is necessary for accessibility purposes, so that keyboard and screen reader users are directed into sidenav when it opens. Sounds like we may need to do some CSS wrangling to support both use cases. Can you provide a Codepen or Plunker with your markup showing the jump?

[davidvthecoder]

I am also having this issue, I do not want it to snap, is there a way to override this behavior? I do not want the sidenav to "snap" causing the page to jump.

Here is a link to an example of the "snapping":
http://codepen.io/anon/pen/jEdKwv
I can confirm that if you comment out that line it stops the focus, however this isn't a solution for me as modifying angular itself will not work with our deployment strategy (not to mention its bad practice).

[davidvthecoder]

Perhaps a fix like this would work:

              var x = window.scrollX, y = window.scrollY;
              elemment.focus();
              window.scrollTo(x, y);

http://stackoverflow.com/questions/4963053/focus-to-input-without-scolling

[marcysutton]

Smooth scrolling is something I've done in the past. That makes it so you can still focus an element and while smoothing out the jump.

[davidvthecoder]

Except thats not the desired effect, why force scrolling? could we have it as an optional config property? I think most people would just want the side nav to slide out and thats it.

I would say if people want it to scroll smoothly down, they could just write their own javascript to do it.

It just seems to go away from being extensible if you force scrolling. You could implement no scrolling/no snapping and then if someone wants to smooth scroll, they could add an event to handle it. Just my 2 cents.

[marcysutton]

The scrolling would only be added to smooth out focus, which is required for the sidenav component but causes a jump if it the element being focused is in a different area of the viewport. I'm looking into how to make this better while still keeping it accessible for keyboard and screen reader users.

[davidvthecoder]

I guess, I wonder why its required to scroll, to me it would make sense to have two behaviors. One that doesn't scroll but still focuses, and one that focuses and scrolls. Could be set by a config property on the side nav.

[dmackerman]

This is actually causing us issues in our app, because we want to focus inputs when the sidenav opens - and it appears that this is overriding that for us.

[davidvthecoder]

Or at the very least have an option that disables focus entirely, that way for those who want to create their own focus behavior rather than being forced into one way, could do that. Just have a warning that if you remove focus it will break screen readers until you implement your own. This would fix every issue, with the caveat that in documentation you would have to warn the end user about the possibility of breaking screen readers temporally.

[marcysutton]

Ok, this sounds like a good candidate for more options. The $mdDialog has a similar configurable property with an accessibility warning in the docs, focusOnOpen.

[davidvthecoder]

👍