Set focus on the same input after clearing its value
I'd suggest focusing on the same input after clearing its value because the user intentionally deleted / cleared the value by clicking on 'x' to re-enter a new value.
Shifting focus to somewhere else or next available input definitely causes confusion and probably he/she may get annoyed. The User needs ...
Give the user what they asked for
If the user has to click something to bring up search ... they probably want to search. Focus the field to save them any extraneous clicks, then watch users in action to see what potential pitfalls that creates.
So, should I use a carousel?
Accessibility expert warns: stop using carousels
Web Accessibility Tutorials, Carousels Tutorial
Accessible Carousels: Part 1
Accessible Carousels: Part 2, Keyboard Control
Accessible Carousels: Part 3, aria-live
A Content Slider
Carousels Don’t Have to be Complicated
My piece of advice considering screen readers would be to set their focus on the information / H2 that tells the user how many results the search resulted in.
The reason for this is that the user need some kind of confirmation that his/her search actually was completed and that the search actually resulted in "no results" or "34 results" or whatever the H2 ...
Focus after a search should remain in the search input field.
When looking for "explicit guidance" on how to create best of breed search UX, google.com is the gold standard. Paraphrasing my own answer on another search-related question:
Consider google.com, undisputedly the market leader of online search. (...) Their design patterns are employed across ...
Yeah you can go ahead with this philosophy if the input is mandatory field.
When it is not mandatory, there is chance that user might just want to remove the information.
I just want to add a thought:
In case of mobile, screen keyboard appears after autofocus then user will know it is typable.
In other than mobile, user may simply click even after ...
Moving focus automatically is not a good idea. User may have done a mistake (e.g. swapped two digits by mistake, 37 instead of 73) and wants to modify it. When focus is automatically moved, user will press a couple of keys (like "Backspace", "7", "3" to change 37 to 73). But if the focus is in another field, it has two problems: this may initiate validation ...
would still indicate that the element's state had changed to "focused"
That's a key phrase. You're ok when you word it that way.
From a WCAG perspective, 2.4.7 just says that an interactive element needs to have a visible focus indicator. There are no rules (in WCAG 2.0) that say what the focus indicator needs to look like. You can do anything you want ...
Most of the answers here deal with forms with multiple inputs. There are certainly some scenarios (using an input for a search field) where there will only be one input on the page.
In this eventuality I find it would be better to remove the placeholder on focus. The user knows what was just in there, and leaving it in place can confuse them.
I think you meant SC 2.4.3 as SC 2.4.7 is whether there is a visible focus indicator (just to avoid confusion).
Would this fail SC 2.4.3?
This would not be a violation of SC 2.4.3 as the order is still logical in terms of page flow (if you went back to navigation and tabbed into the page I am assuming it would be the first item that is focused).
Replace the row with 'deleted' and focus it with tabindex="-1" (so you can only focus it programmatically).
Then once focus leaves the row you can make it disappear if you wish (but not necessary as it will not be focusable again).
I recommend this as if you focused the next delete button they user may not realise that an action was performed or think an ...
In order to comply with WCAG accessibility guidelines, the tab order of your site/app should follow the visual order of the page, so left to right (or right to left if the language is rtl) and top to bottom. Failing to comply with this guideline (2.4.3) would be an downside to your proposed solution.
The WCAG has another guideline (2.4.1) related to your ...
Have you considered that this order should be consistent through the entire website?
For accessibility purposes, it would seem confusing if in one page keyboard users would "see" Logo > menu itens > input, and in other pages he would see the input first.
Using a mouse click somewhere dead on the page, such as in between interactive elements, will achieve the removal of focus (blur) from whatever element had it..."
Well, kind of.
As you know, Tab just moves focus through the focusable elements in the document, stepping through each focusable child of each HTML element.
However, the browser ...
No - seems great. Fast solution - no useless info.
If you use tab in this post (First - tags active - later actions - your avatar - nick - and action add a comment)
question: what is the demand of users, tags, options or viewing your profile?
Is it worth skipping 9 actions - to reach 10 ultimately the most adequate (add a comment)?
However, in the case ...
There are two changes to be made if you are working on an accessible tooltip solution.
Avoid automatic presentation of a tooltip when user focuses a UI control with keyboard. There are warnings about it in WCAG.
There must be a clear action that would invoke a tooltip. Also, there must be a separate action that closes it, such as close button inside. ...
I am in favour of not using a carousel to begin with, you're hiding content that is apparently important to show..
But that aside, you could ignore the arrows in the tabbing order and go through the slides by using tab directly while focussing on the clickable component on each slide.
This is assuming you have a link on each slide and not that many (like ...
To me, option 1 is stronger, but your default empty state still suffers from its lack of contrast. It might be mistaken for a disabled state. I suggest making the text a bit darker.
Your second option gives the impression a bit too strongly that the input field is currently in focus. You should reserve border changes (color) to communicate errors and ...
Consistency is at the center of good UI design
Unless there's a good reason to, the weight and color of the text and the thickness of the input border of a dropdown selector should be the same in all states.
In your case, graying out the text in the "no value" state risks the field being mistaken for one that is disabled, and increasing the thickness of ...
For accessibility reason you don't want the focus being on the bottom of the page for any reason: if you click the back button it means that you want to navigate to the previous page (not the previous action). If you navigate to a page, you want to scan it from the top to bottom, especially if you are dealing with forms where the choices made on the top of ...
In my opinion:
Don't steal focus
Don't prevent user from entering any input e.g. copying and pasting, then correcting
Validate immediately, don't wait for loss of focus
User will eventually end up trying to enter input elsewhere and have the input reach the wrong place or get lost
User may try to copy a number from some place that also selects ...
The issue of focus stealing is well-known. In the Linux world, some desktop environments like Xfce have options to prevent it. GNOME 3 also prevents it by default.
In terms of security, the reality is a lot more complex, as until recently (~2011 and forward), graphic stacks had little to no protection against unprivileged apps listening in on the keyboard ...
Consider what your user will do with the search results. If this is a typical web content search where the user will hopefully identify a useful page and select it to see the content, there may be no need to focus anywhere - OR you could focus on the keyword field, in case the user does not see useful results and wants to modify the search. I'm not sure that ...
onchange is too slow, onkeyup is too fast -- fortunately there is a middle ground, which doesn't require pestering the user with a notification: debounce the input events.
Essentially what this means is that you set the event to trigger on both keyup and blur, but limit the speed at which repeated triggers are taken into account: on receiving a new event, ...
Need more context here. Behaviour is different for desktop (windows, mac) app as compared to web.
The dialog opens as a new window. Typically, the new window gets focus. User can tab to return focus to the main window, while keeping the smaller dialog. Or close the window using the close window shortcut (Windows: Ctrl + W , Mac: Cmd + W)