Accessing chat using fx Danish keyboard on iPhone, chat does not work. It simply complains about something cache, making the chat useless for anyone on another keyboard and that’s a lot op people, I would assume. Just letting you know, so whenever a fix is around it’s good.
]]>Our company really wants to use the look “Nice dropdown with flags” since it looks, well, so nice. … is it possible to make this work?
Edited to add: I did get it to work if I used “Dropdown” and set it to appear in my main menu (not floating) but this is not ideal for us as we have limited space in our menu.
]]>However, the issue is more signigficant when Turnstile is set to be displayed only when interaction is required, and in the case when interaction is not required. In this scenario, it still takes several clicks of the Tab key to get from my last input field to the submit button. Turnstile is not visible but it still accepts the focus. This is a poor user experience.
Here is a video which demonstrates the problem.
It is possible to work around this by modifying line 12 of contact-form-7.php
as follows, making the Turnstile element inert
to all user interaction:
// echo '<div class="cf7-cf-turnstile" style="margin-top: 0px; margin-bottom: -15px;">';
echo '<div class="cf7-cf-turnstile" inert>';
However, while this solves the problem for the above two scenarios, it introduces a new problem whenever Turnstile asks the user to tick the box to confirm that they are human. Being inert
prevents the user from ticking the box. What is needed perhaps is for this attribute to be controlled by Javascript, so that it is only added when Turnstile does not require interaction?
I’m sure there are other ways the problem could be addressed, this is just one suggestion.
]]>I have a site a client is testing, and they’ve asked if possible that when you’re on a mobile and type a word, clicking the Go button on the OS doesn’t send you to search page. This way you’ll be kept seeing the autocomplete dropdown and be able to scroll through those.
This is a bit of a follow-on to this question I had resolved (which fixed that issue).
Many thanks,
role="button"
` but it needs tabindex=”0″ added to enable it to be accessed via the keyboard. I have tried adding this attribute using some JavaScript but whilst this works and enables the user to use the keyboard to access it the more critical issue is that the actual “accept” functionality does not work via the keyboard but will only work with mouse click / tap interaction.
Is there a way this can be updated or a way I can override / fix this behaviour? It has been flagged during an accessibility assessment so I need to find a way to resolve the issue.
Thanks for your help!
]]>I’m sure I can make a work-around with a little JavaScript, but if you can reproduce it on your end and beat me to a fix, I would love it!
]]><div>
elements instead of <button>
and <a>
elements, as they appear to be. This makes them inaccessible via keyboard navigation or similar assistive technologies.
Furthermore, the dialog/banner, regardless if “Block content until consent” is enabled or disabled, is not the first focusable element forcing one to navigate through the entire page to reach it.
Tested on Real Cookie Banner v3.7.2.
]]>Thank you so much!?
]]>