As part of my login and registration forms, if there are errors then it will autofocus the related field. Actually, it not as simple as I thought. Let me try to explain!
Basically, on this project, pages are loaded with AJAX. Forms may include an autofocus attribute. This works great, but on mobile it just shows the cursor without bringing up the keyboard, meaning you still have to tap the input to start typing.
Am I missing something, or do I have to double-up the focussing with something like
document.querySelector("[autofocus]").focus();
// with appropriate verification that the element exists, of coursr
In mobile devices (at least in Apple's Safari), the keyboard isn't allowed to show up without the user clicking on the input field. It's by design, and I don't think there is much you can do about it.
http://www.quora.com/Mobile-Safari-iPhone-or-iPad-with-Javascript-how-can-I-launch-the-on-screen-keyboard
Related
In Material UI Autocomplete Free Solo, I noticed that the "Clear input" button is clickable, but not accessible by keyboard.
I went into the codebase to understand the reasoning behind this decision but didn't find anything. I also checked the A11Y docs but without success either... Could anyone give a little more detail about this? Was it a decision based on user testing?
Code that adds the tabindex="-1"
Testing the tabindex="-1"
Thanks :)
As far as why it's behaving the way it is, you already discovered that. tabindex="-1" means the element should be removed from the normal tabbing order but still allows the elmenet to be focused programmatically (if you call obj.focus() from javascript).
If you're asking why Material decided to not have that button focusable, #rafael is correct that that's not a stackoverflow question. Someone working for Material that happens to be on stackoverflow might see this question and try to answer it but you're more likely to get an answer if you ask them directly.
Note that WCAG 2.1.1 is often misunderstood that every interactive element on the page must be accessible via the keyboard. That's not true. What that checkpoint says is that all "functionality" of the page must be accessible through the keyboard. In the case of the X-clear button, that functionality is also available via the keyboard because when you TAB to the input field, all the text gets selected so you can either press DELETE or BACKSPACE to erase it or just start typing new text. Or you can press Ctrl (or CMD) + A to select all the text and delete it.
So all the functionality of the X-clear button is available to the keyboard user without the actual button being accessible.
Now having said that, I rarely, if ever, make a button that is clickable with the mouse not available to the keyboard user.
I recently added a location search field on my site which shows suggestions based on what you type, but on Microsoft edge, a menu pops up on clicking on the input field. How can I disable this menu from appearing on just this input field of my site?
Based on the image you provided, I think this should be caused by some default settings in Edge. If you want to turn off this prompt, just navigate to: edge://settings/personalinfo in Edge and disable this feature like this image below:
I had today the same problem. I had input field without label and empty placeholder. Setting placeholder"..." and making the placeholder transparent makes that edge does not anymore offer "type / ..."
Hth
I believe what you're looking for is:
spellcheck="false" autocomplete="off" aria-autocomplete="none"
The aria-autocomplete seems to prevent that box from popping up and the spellcheck seems to also stop the spell checker one from displaying.
There are places where autocomplete and spellcheck would come in handy, but NOT in single-line fields like email, website, or an <input> where I have my own Bootstrap dropdown-menu/dropdown-item list that displays retrieved DB records via AJAX as the user types (in this case, the Edge popups were ovelaying my DropDown list).
Anyway, adding this code to the <input class="whatever" id="whatever" spellcheck="false" autocomplete="off" aria-autocomplete="none" placeholder="whatever" value="whatever" > seems to solve the issue and you don't have to get all your users to change the browser attributes or mess with the placeholder. Hope this helps... :)
We have an existing web application with hundreds of input fields through different applications that has been installed at several sites. At this most recent site, however, we have started having an issue with the back button automatically filling in input fields. This is an issue because the only time we allow the back button is if an error occurred in processing. So the flow is as follows:
1) ask user to scan a barcode
2) an error occurs on the back-end and it directs them to an error page with only a back button
3) the user hits back and is directed to the input page, input form is now filled with the previously inputted data.
I know this is some form of caching or browser issue because when I hit the web app from my personal pc, it doesn't do it. But when they use their android scanning devices and if we load it up on the application server, it does.
I have fixed this on a couple of pages with autocomplete="off" on the input fields, but it just isn't feasible for us to change this on each of hundreds of input fields if we can avoid it. I'm looking for some browser or windows function to turn off to disable this.
I have tried turning off all of the chrome autocomplete fields, and I have tried disabling the cache in dev tools with no luck. Is there another way to disable this without using that autocomplete tag?
If inputs are inside form you can put it on form.
If not you've only one option to use a global script to add attribute on each input something like below but it'll put it on every input and I'm not sure if it'll have any side effects for your case:
field.setAttribute( "autocomplete", "new-password" );
Hope it helps.
I am developing an on-screen keyboard. I want to disable keyboards of mobile devices while the osk is open. One way is to make input read-only, so that focusing on it not opening the keyboard. But using that solution, the user can't change cursor pointer (and also does not see any cursor while writing with osk) and can't select one part of text to delete.
Is there any other solution to stop mobile device keyboard from openning while focusing on input? Something like a specific attribute or styling value or etc.
Thnaks in advance. TG.
// UPDATE
one solution with readonly
EDIT:
Okay, to hide the keyboard for mobile users is not something you can prevent directly, but there is an alternative.
The "OnFocus" Event activates when a specific elements gets focused. this way you can add a bit of code to prevent a mobile keyboard from popping up.
this way we can add the "Blur()" method to it.
so it would look something like this:
<input type="text" name="noKeyboardForMobile" onfocus="blur();" />
I manage several websites that use a featured article scroller on their homepages, which allows the user to click a forward or back arrow in order to see the next article headline and blurb while remaining on the same page.
I use WAVE's accessibility checker and any sites that have this particular plugin throw an error back because within the code there is an empty link, written as <a href="#">. Is there any way around this? I've defined a title attribute but the # is causing the empty link error to still come up.
Some places I've seen that this is perfectly acceptable and others claim this is a problem. What's the actual answer and potential workaround?
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
Some source suggests that link would be an invalid hypertext reference, but in fact the problem would exist only in non javascript browsers which is out of the scope of WCAG 2. This is not your problem here as this is not an error that WAVE considers.
The problem here is the fact that you have an empty link content and that adding a title attribute does not satisfy WAVE algorithm.
If your only concern is to satisfy WAVE, just put some content in the link and use any CSS trick to hide this content.