If I have a form that is the main part of a page's content, will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
The short answer is no it doesn't make things inaccessible but it can make it confusing. The longer answer follows. Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page.
It might a bit, if we've got a keyboard user (either using a screen-reader, or just a habitual keyboard user) who's expecting to be navigating the links at the top of the page on first Tab press. For screen readers, you could also consider adding WAI-ARIA to add directions if users who don't expect to be dumped into the middle of a form.
If it's much more likely that the user's going to be wanting to type in the field straight away, then I think the autofocus is worth it. But for the reason above I wouldn't use it on every page with an input field.
If you do autofocus, make sure to do it right away, in a script as soon as possible following the input element, or in future using the HTML5 autofocus attribute. Don't do it as late as window.onload. It's annoying to have clicked the focus elsewhere only to have the document belatedly finish loading and steal the focus onto another element as you type.
A lot of sites will do this, google is a good example, the only issue is when you are typing something into the address bar, or into the search input in your browser, the action of focusing the form field tends to steal focus from where you are typing. It's a small nuisance.
will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
I can't think of any. In between fields might irritate whatever assistive software a user might be running, but the first field - hardly. I have no experience with braille and similar clients.
Seeing as even Google do it on their front page, I don't think it can be that big a deal either way.
Quoting MDN autofocus -> accessibility considerations (retrieved 9/28/2022):
Automatically focusing a form control can confuse visually-impaired people using screen-reading technology and people with cognitive impairments. When autofocus is assigned, screen-readers "teleport" their user to the form control without warning them beforehand.
Use careful consideration for accessibility when applying the autofocus attribute. Automatically focusing on a control can cause the page to scroll on load. The focus can also cause dynamic keyboards to display on some touch devices. While a screen reader will announce the label of the form control receiving focus, the screen reader will not announce anything before the label, and the sighted user on a small device will equally miss the context created by the preceding content.
To add some practical examples, at the time of writing, https://www.google.com autofocuses on the search box, while Wikipedia and Amazon don't. If typing into a search box is the sole purpose of the page and the risk of confusion is low, then it's worth considering autofocusing on it. Otherwise, probably skip autofocusing.
I wouldn't say so, fragments are an ingredient of HTTP and they set the focus of an *html page..
I wouldn't say so. A screenreader will probably not even notice this since it doesn't interpret the JavaScript on the page.
Another user which has a "normal" browser will get the advantage of having the cursor already at the right place which facilitates the navigation by using just the keyboard.
Related
As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
I have an input type email.
<form>
E-mail:
<input type="email" name="email">
</form>
As soon as the user start typing, I would like to give them the option of most popular emails. Ex. #gmail.com ...
See the image below for details.
How would one go about and implement something like this?
Is there any plug-in or framework that help me achieve this kind of task?
Will HTML/CSS/JS have the ability to do that or only swift2 can ?
QuickType is part of the built-in iOS keyboard, and here is no way to access and/or modify it with JavaScript from a simple website. Unfortunately, you can't even detect the keyboard's height, and position some fake QuickType-like buttons over the keyboard, because the keyboard animates up from the bottom, over the current application without resizing or moving anything.
I'm afraid your only option is to add these as small buttons under the input, or maybe you can create something similar to the iOS copy/paste menu, that becomes visible, when the user starts typing in the input, and append the email endings on a click/touch.
I agree with #frzsombor, but I can think of a different workaround. It would take a lot of code though, so it might not be worth it. Anyway, what you could do is periodically take a screenshot and check for one of the colors on the keyboard in a certain position, maybe #ACB3BB (the return button color). If it is there, you could display another Quick Type Bar above the built-in one. The only problem would be if an update to iOS changes what the bar looks like, but you could always update your website. Another possible way to detect the keyboard is here. I think you need jQuery for that, though...
Requirement: on each page change the screen reader must read the entire page content.
We use firefox+NVDA to do our testing, and since angular doesnt "change pages" we have tried the following to make it read the entire page when changing states:
aria-live="assertive"
This for the most part read the changes in text in our site,but it only reads what its being added, in our case we have a table being filled with ng-repeat and it reads the information being added but without any context (it doesnt say what row or column is being read)
Another issue was forms, when being filled by angular, the screen reader will read it before they were populated by angular, this was solved with a $timeout but still when aria-live reads the changes it would skip some parts, and if we added aria-atomic to force read, we had some selects with multiple options, and those were read (all of them, we have more than a hundred options). which is not how screen readers read, they only read the first ten options or the ones visible when you click on them.
Remember that without any aria-live or aria-atomic, when you change states in angular the user is not notified of any changes.
after almost giving up we decided that maybe our focus was wrong, we needed to make each state its own page so we used the following:
function ForceNVDARead() {
$(window).on('hashchange', function () {
location.reload();
});
}
This for every change in the URL will force a reload. This works GREAT, everything was being read correctly, we almost thought this solved everything. Except this causes double requests from the client to our server.
Is there any way to make NVDA read the contents of an angular state like a regular page load, without having to force the reload of the page?
Please dont say use aria-roles only or something like that that doesnt work for this and we already have them, we need the application to read everything when changing states.
ANY help is appreciated, we are about to give up, and restart the project without angular as we are not able to achieve our accessibility requirement.
Requirement: on each page change the screen reader must read the entire page content.
This is fundamentally not a requirement from an accessibility point of view, it is the equivalent of making someone looking at the screen to read everything one line at a time, or use readquick, it is not natural usage.
Screenreader accessibility is acheivable when using Angular, but we need to reset some assumptions:
When you have page updates, the key is to manage the focus, and move to the new content. That allows people to read in their own way, not the way you have been assuming they have to read.
ARIA live is intended for small updates elsewhere on the page (away from the keyboard focus), not the whole content, it is not the answer here, I would drop it completely.
If people are reading forms before they have loaded, that might be a side effect of trying to force the reading with ARIA-live. If not, then trying using focus-management to place focus at the top of the form when it has loaded.
It is probably worth reading a tutorial on NVDA usage, or talking to a 'native' user. I can say from experience you are not using it in the way end users do, so get to understand better what 'normal' interactions are like.
If you drop the use of ARIA-live and go with focus management you'll probably solve most of the issues, but there may well be more questions later from a different point of view.
my site page's goal is to get information from a fairly complex (but concise) form. Ease of use is a big deal for me so when I tested the form on a WAP emulator, I was disappointed to see nothing happen when I clicked on radio buttons that successfully display the correct portion of the form on normal browsers, including the iPhone's. I've realized that this is because the code in the page is javascript and most dumb WAP phones don't support it. When I implement javascript, it's so that form options below a radio button don't show up until they are selected, and I know what you're thinking - "just make default forms options pop up" - but I couldn't figure out how to do that without ruining the whole appearing/disappearing act.
I suppose I could ask the browser if it supports javascript and redirect it to the javascript-enabled page if it does, or one without dynamic stuff if it doesn't... I wish there was a better option but how would I do that? BIG thanks in advance!
you could either use <noscript> to display the whole form on "dumb phones" or you could make some "config wizard"-like thing, like showing the radiobuttons on one page, submit it, and then (using php/ASP/whatever) send only the fields that depend on the previously checked options.
I heard someone mention that one could theoretically position an invisible iframe on top of content and receive the input that someone wants to put in a form. How would this be possible and not get suspicion? It scares me...
Yes it is possible! It's called clickjacking, and is very real indeed. Check this out for more information: http://en.wikipedia.org/wiki/Clickjacking
Michal Zalewski, of Google, has a theoretically example (Source: Page 1, Page 2):
A malicious page in domain A may
create an IFRAME pointing to an
application in domain B, to which the
user is currently authenticated with
cookies," Zalewski said in a message
to a mailing list on Thursday. "The
top-level page may then cover portions
of the IFRAME with other visual
elements to seamlessly hide everything
but a single UI button in domain B,
such as 'delete all items,' 'click to
add Bob as a friend,' etc. It may then
provide [its] own, misleading UI that
implies that the button serves a
different purpose and is a part of
site A, inviting the user to click it.
It's not possible to do this without drawing suspicion, someone will always notice. If you're not a standard user, I would recommend you try downloading noscript (a firefox plugin). It prevents any website not on your personal whitelist from running javascript. This should alleviate a lot of your worries! I hope! I know it makes me feel better.
In the realm of possibilities, there are many stupid ideas. :-)
Theoretically, you can hijack a form and place a region that captures input. This is not a simple exercise, as you need to mimic the form or have the user step outside of the security box of the browser. It is far easier to phish with a look alike form than do this.
I see someone mentioned clickjacking, which hijacks the click event. Overall, this is different from the form capture, although it could be used to cover a button once a form was filled in. Once again, there it is similar to a phish attack, as you are hitting their site. Without this misdirection, they can't inject the JavaScript necessary to make this work.
What is your real concern? That someone can hit your site and be hijacked without another site on top? Unlikely. That people can be fooled. Well, PT Barnum taught us there is one born every day.