Need tab support

[robdodson]

Description
As mentioned here https://docs.cypress.io/v1.0/docs/type#section-typing-tab-key-does-not-work. For accessibility testing I need to be able to tell the keyboard to press tab. If cy.tab is not currently supported is there some way to work around this?

[jennifer-shehane]

I'd like to hear more about what you are looking to cover in terms of accessibility testing. Can you give me an example of a use case you are trying to test with the tab key?

Right now there is not a way to press "tab".

Currently we simulate all events in Cypress - although we automatically backfill in the browser's default behavior on all actions, which means that your application does what it does identically to native events.

The problem with tab is that it is extremely complicated and its behavior is not necessarily normalized across all behaviors.

The solution for us is to enable native events within Cypress. We can "opt into" native events whenever we want, the problem is mostly with the UX experience around the debugger protocol. Namely that you cannot have Dev Tools open and issue native events due to the limitation of Chrome's debugger protocol.

There is an open issue in Chromium to add multiplexing support so we've been waiting for that to go live. Until then we will kick the can, or eventually be forced into creating a good UX experience that either automatically closes Dev Tools, or prompts the user that their tests cannot continue until it is closed.

[robdodson]

thanks for the response

The tab key is one of the primary ways a keyboard user moves around the page so it's difficult to write a high confidence accessibility test without it. In my case I'm building custom components that comply with the aria authoring practices guide. The first thing I would like to do on every page is press tab to focus the element. I can fake this by calling click() but it's not really the same. A non-sighted user will never use the mouse so calling click() feels a bit like cheating and you could imagine a situation where an element has one behavior when clicked and a different behavior when focused via the tab key.

[brian-mann]

If you're testing the behavior of an element coming into focus, or you're testing things like styles you can just focus the element directly.

cy.get("input").focus()

What this doesn't test for is what the browser's behavior when clicking "tab". But you can often indirectly test this.

For instance, you could just make sure that the element it's supposed to focus on has tabindex set.

[robdodson]

What this doesn't test for is what the browser's behavior when clicking "tab". But you can often indirectly test this.

Yeah that's what I've been doing. Still, I would prefer tab key support if it were there because it'd be less boilerplate to write :)

[kamituel]

I have a different use case for .tab() - in our app we have a fairly advanced search input (multiline, hence implemented as a <textarea>). A user is supposed to enter a query written in a custom grammar. It might look like this: some.path.here = something. Tab completion is supported, so when the user enters, say, some.p and pressed a tab key, it might get expanded to some.path..

This is obviously distinct from accessibility use cases (as described above).

Any update on .tab()?

[jennifer-shehane]

In Chrome 63, there is support for multiplexing and we can now better handle native events. See #311

[protoEvangelion]

@jennifer-shehane Is this on the road map to be implemented? Or should we not expect this any time soon?

[awhill19]

I'd love to know as well. Just ran into this issue while writing a form validation test.

[davidszepernick]

Me too . I was expecting some way to tab to the next field like .type({tab})

[siemiatj]

Same as the above. I'm testing an app that mimics desktop application and heavily relies on keyboard usage.

[mirandashort]

Has anyone found a good workaround for this? It seems as if we're not getting a tab function..

[scottschafer]

This seems to work:

Cypress.Commands.add('typeTab', (shiftKey, ctrlKey) => {
  cy.focused().then(($el) => {
    cy.wrap($el).trigger('keydown', {
      keyCode: 9,
      which: 9,
      shiftKey: shiftKey,
      ctrlKey: ctrlKey
    });
  });
});

[brian-mann]

@scottschafer that fires the event, but the browser will not perform the default action such as moving the tab focus to the next focusable element

[jennifer-shehane]

@scottschafer This should be able to be simplified to this:

Cypress.Commands.add('typeTab', (shiftKey, ctrlKey) => {
  cy.focused().trigger('keydown', {
      keyCode: 9,
      which: 9,
      shiftKey: shiftKey,
      ctrlKey: ctrlKey
  });
});

[scottschafer]

@brian-mann , ah. In our web app we specifically handle keyboard events and change focus programmatically. It works for us - sorry this won't work for you.

[jennifer-shehane]

@scottschafer Yes, glad to see you got this work in your use case. It should help anyone else that programmatically works off of the user's specific keydown of the tab key.

[lazarljubenovic]

Whaaat? Tabbing was literally the first thing I tried testing 😄 Wanted to test the login form and the fact that pressing Tab on the password form doesn't focus the Show/hide password button but the Login button...

The problem with tab is that it is extremely complicated and its behavior is not necessarily normalized across all behaviors.

Wouldn't it be possible to allow users to customize the "algorithm" for tabbing? Figuring out where the focus will go is indeed a tricky problem, but for a majority of usecases it should work pretty straightforward. Figure out what is the next focusable element in the DOM after the current document.activeElement. Something like button:not([tabindex=0]),a:not([tabindex=0]),[tabindex=1],[tabindex=2],...)?

There are a few very good libs which also try to figure out which elements are focusable in order to trap focus in a modal or a dropdown. Maybe it's a good starting point to figure out what kind of algorithm they use to intercept focus leaving the modal and taking it back to the first focusable element in it?

[decafdennis]

I think the key is to find or come up with an implementation that works for your use case. It's hard to come up with a general solution.

FWIW, here's my implementation roughly based off of some of jQuery UI's logic: https://github.com/getstreamline/menu/blob/master/cypress/support/index.js#L39

One of the gotchas is that the focused() command does not work reliably when the browser is not currently in focus, so I also added a separate active() command that is more consistent: https://github.com/getstreamline/menu/blob/master/cypress/support/index.js#L63

It's naive but works for my use case!

[samjulien]

@decafdennis your tabbing stuff works well for me, thanks! The solution @jennifer-shehane posted wasn't working with the "shiftKey" variable for some reason. Tabbed forward but not backward.

[stefcameron]

Why is that? Does it fail under some circumstances?

Here's one example I've encountered, that being that cypress-plugin-tab doesn't understand that a non-tabbable node can still be focusable and can be tabbed away from. You can set focus to the node, but when you try to use cypress.tab() to move away from it, the plugin will throw an error.

[theTestingApproach]

I am really thinking that keyboard and mouse events does not trigger well with cypress.
For ex i cannot use mouseover for hovering a text it never works .
same mousedown never works
I tried cy.get('input').type('{shift}{alt}Q') from example here it does not work as well.
sometimes i have to use cy,invoke('show') which is not a good practice as it is checking the DOM but not the interface.

[dcb99]

+1 for tab key, it's a basic part of accessible navigation.

[krichards]

agreed - essential for accessible navigation testing

[rafaelcoelhoo]

+1 it's an essential feature of accessibility tests.

[Rash419]

+1

[Kingdutch]

This issue has been open for quite some years and a lot of people follow it (and thus get emails for new comments).

Please refrain from posting comments that merely say “+1” and clutter the issue. These make it more difficult for people to find other comments that discuss what is needed to move this forward or other packages that people can use as a workaround.

Instead of posting “+1” please hit the 👍 on the opening post.

[ElamuruganGR]

+1

[rubiadestro]

+1

[stefanprobst]

ffs please use the +1 button, this one:

instead of adding "+1" comments, which will notify everyone subscribed to this issue!

[lazarljubenovic]

Just unsubscribe from the thread. It's not fixed in 6 years. The chance for a better project/stack popping up is higher than cypress getting its shit together :)

[mryellow]

This needs to be prioritised in some manner. Leaving disabled people behind as we all forge ahead only testing mouse interactions is probably a violation of policy for many if not law.

[alisterscott]

The chance for a better project/stack popping up is higher than cypress getting its shit together :)

https://github.com/microsoft/playwright is already here and supports any keys 👍

[clintonmedbery]

What is the threshold for getting this in? Literally has more thumbs up than people watching this repo 😂

[mryellow]

This likely isn't getting implemented. Some decisions made at a fundamental level put it in the "too hard" basket.

Thus as mentioned above, the real solution is everyone switching to new tooling which doesn't suffer the same design flaw.

[ptletski]

Sad that it is taking years to get recognition that USERS use the tab key to navigate web pages. Sad.
Why not just make the plugin code native to Cypress since that is what you are telling people to use. That would make one less package to manage for us consumers.

[wilsonpage]

Just use cypress-real-events, works great.