Need tab key 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})