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?

[theTestingApproach]

This does not seem to have been implemented yet. Do we have a workaround pls.thanks

[stefcameron]

@theTestingApproach

This does not seem to have been implemented yet. Do we have a workaround pls.thanks

https://github.com/Bkucera/cypress-plugin-tab is a workaround -- but nothing more. It's quite useful, but it does have its limitations and bugs you'll have to workaround (or just not test some particular thing it doesn't work for). We're using it on https://github.com/focus-trap/focus-trap

[dmtrKovalenko]

I do not recommend cypress plug-in tab because it is a mock of browser focus tree which may not work correctly.

There is my plug-in https://github.com/dmtrKovalenko/cypress-real-events which exposes cy.realPress("Tab") and fires native tab event which is equal to puppeteer pressing tab.

Maybe we can disable conversation on this issue for now because I reply with a workaround for the 3d time

[stefcameron]

I do not recommend cypress plug-in tab because it is a mock of browser focus tree which may not work correctly.

There is my plug-in https://github.com/dmtrKovalenko/cypress-real-events which exposes cy.realPress("Tab") and fires native tab event which is equal to puppeteer pressing tab.

I appreciate the link. Unfortunately, your library relies on Chrome DevTools, and therefore Firefox is not supported. So with your library, we can perhaps "fully" or reliably test with tabs on Chrome, but cannot test at all on FF. With cypress-plugin-tab, while it has its limitations, we're able to test on both Chrome and FF, which is technically better coverage.

[dmtrKovalenko]

Hardly disagree, that is technically less coverage. Because when you are mocking something and exactly know that it didn't work like a real browser API you are kinda lying yourself that this part of my app work. But in fact you can't be sure that it works correctly with or without this test.

But I agree, having firefox browser automation api available will be nice for real events

[dwilches]

I do not recommend cypress plug-in tab

Why is that? Does it fail under some circumstances?

El jue., 14 de oct. de 2021, 10:54 a. m., Dmitriy Kovalenko < @.***> escribió:

Hardly disagree, that is technically less coverage because when you are mocking something and exactly know that it didn't work you are kinda lying yourself that this part of my app work. But in fact you can't be sure that it works correctly.

But I agree, having firefox browser automation api available will be nice for real events

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cypress-io/cypress/issues/299#issuecomment-943490472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6KR2L54WXMJMGP5MKC5OLUG34JPANCNFSM4CWTTSBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[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.

[harryeastwood]

This would be a great feature and I don't know why it's not already supported for tabbing between elements. It is required a great deal in most web based workflows.

[arashid-sh]

Just use cypress-real-events, works great.

just FYI for those who are testing in firefox. cypress-real-events is not supported in firefox

[ghost]

How many more thumb ups do we need?

[AlexDaniel]

@walleyyang could very well be that the way Cypress works does not allow an easy implementation of this. How many more times people need to tell you to use Playwright instead? 😆

[mryellow]

Just use cypress-real-events, works great.

No. It does not work great.

[jops87]

Is there any update on this feature request?

[thomasboyt]

Will Cypress's new paid accessibility product cover tab navigation of forms and other interactable elements? https://www.cypress.io/blog/2024/02/16/introducing-cypress-accessibility

[WORMSS]

Wow, is this still going on? May I suggest everyone do the correct thing... cough Playwright cough

[mryellow]

Will Cypress's new paid accessibility product cover tab navigation of forms and other interactable elements? https://www.cypress.io/blog/2024/02/16/introducing-cypress-accessibility

From my read that just checks tags and things exist. Some kind of basic checklist, surely not worth paying for.

While Cypress itself will continue being incapable of actually testing the types of interactions needed to confirm accessibility.

Well the website for the underlying service certainly has the "Use enough contrast as to be painful to look at" part down ;D

https://dequeuniversity.com/checklists/web/

[alexzavg]

I'm gonna add another vote "pro" multiple tabs feature.

I got a case where all pages open in new tabs by clicking on respective buttons.

The buttons don't have "target" attr or anything like that which would allow me to manipulate the DOM.

And changing the whole system behavior based on one guy's request (who's just a QA and not an end-user) is absurd and nobody will do that, as the organization is huge. Nobody is gonna change the tool as it's already deeply rooted into the system architecture.

I hope it will be added someday.

[scottohara]

@alexzavg This issue is in relation to Cypress not having support for simulating a press of the TAB key.

It sounds like your comment may be for something related to multiple browser tabs?

[sebb-m0]

I stumbled over this feature today and can't believe, that Cypress does not support the {tab} key since 2016 and still do not support it natively. 😮

+1 for adding {tab} to this list: https://docs.cypress.io/api/commands/type#Arguments

[alexzavg]

@alexzavg This issue is in relation to Cypress not having support for simulating a press of the TAB key.

It sounds like your comment may be for something related to multiple browser tabs?

oh, yeah, sorry about that, I was referring to the multiple tabs feature which is also something of importance. I guess I've misunderstood the thread title.

[luciarodriguez]

+1 for adding {tab} to this list: https://docs.cypress.io/api/commands/type#Arguments. Is there any timeline?

[mryellow]

+1 for adding {tab} to this list: https://docs.cypress.io/api/commands/type#Arguments. Is there any timeline?

It's not that list.

It's that you can't test pressing tab to navigate between fields. Thus can't test accessibility.

It will never be implemented. We're all just hanging out here for the laughs.

[lazarljubenovic]

The laughs is the only way to play right!