cypress
cypress copied to clipboard
cypress-io
Need tab support
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?
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.
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.
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.
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 :)
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()?
In Chrome 63, there is support for multiplexing and we can now better handle native events. See #311
@jennifer-shehane Is this on the road map to be implemented? Or should we not expect this any time soon?
I'd love to know as well. Just ran into this issue while writing a form validation test.
Me too . I was expecting some way to tab to the next field like .type({tab})
Same as the above. I'm testing an app that mimics desktop application and heavily relies on keyboard usage.
Has anyone found a good workaround for this? It seems as if we're not getting a tab function..
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
});
});
});
@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
@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
});
});
@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.
@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.
Whaaat? Tabbing was literally the first thing I tried testing :smile: 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?
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!
@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.
Currently working on this, however it may introduce breaking changes around cy.type(), so I've set the milestone for 4.0.0
@jennifer-shehane so, 24 days ago, you removed this from the 4.0.0 milestone. Does that mean there is no interest in fixing this? Or still blocked by browsers support?
We've repurposed the 4.0 release with other breaking changes that are closer to going out - you can see the roadmap for 4.0 here: https://github.com/cypress-io/cypress/issues/2840
This feature falls more closely under our Native Events issue which is also in progress, but has not been assigned a release number yet. See progress for this issue here: https://github.com/cypress-io/cypress/issues/311
Sorry to pile-on, but thought I would add my use-case here. Like the OP I am trying to add integration tests to assert that our open-source accessible React component ('React Accessible Accordion') complies with the WAI ARIA spec.
You can see the assertions which I needed to make here.
Unfortunately I didn't realise that Cypress was not going to support this functionality (or the 'end'/'home' keys it seems). I'm going to abandon Cypress because I can already get equivalent functionality out of the incumbent testing suite (Jest + Enzyme).
There is an issue with an open PR slated for release in 3.2.0 providing end and home key support here: https://github.com/cypress-io/cypress/issues/2033
We're still working on tab support (and other keys) as part of Native Events #311 , but in the meantime I've made a plugin that adds a .tab() command (supports .tab({shift: true}) as well). cypress-plugin-tab:
However, the actual tab implementation will not be a separate command, so know if you use this plugin, you'll have to refactor your test code when Native Events lands
:rotating_light: Please open/discuss issues with the plugin in the issues of the plugin repo, not here :rotating_light:
I see there has been talk about implementation for the tab key. I sort of need to trigger keypress and keydown events in most of applications I am testing.
I am looking for a work-around for the arrow keys, spacebar and the enter button.
Basically I have set up some custom key events for accessible keyboard navigation through list items but I have no way of triggering the events through keydown or keypress inside of cypress :S.
I'm really liking cypress and want to continue using it, but dont know how to get around this issue as all the applications we make and test for work need to be accessible.
(tried the work-around above with updated keycodes but that didn't seem to work)
Tab is a no brainer. Currently testing a javascript dropdown box where user types in a country for example and the list shortens per character typed and tab is the way to proceed with what's selected onto the next field. This is easy to use as a human, tab is a natural progression out of this field. Cypress is lacking by not having tab key support. Hope to see it arrive soon.
Update: Cypress plugin tab - https://github.com/Bkucera/cypress-plugin-tab - works very well! However, this plugin shouldn't have a reason to exist. Cypress needs to add this as core functionality.
I tried the cypress-plugin-tab, I have some differences in order at manual testing. For example if I have divs in body, which have different tabindices:
<html>
<head>
</head>
<body>
<div tabindex="10">1</div>
<div tabindex="5">2</div>
<div tabindex="3">3</div>
</body>
</html>
When using the plugin, the first cy.get("body").tab() selects the div with "10" tabindex. But at manual testing the "3" tabindex won.
Is it a bug of the plugin, or I did something wrong? How can I fix that?
@kvaternio-dev Maybe add that as an issue/question on the https://github.com/Bkucera/cypress-plugin-tab repo?
