Disabling HTML5's autofocus #6796
Comments
|
Can you please explain what behaviour you're actually seeing here and what
you're requesting instead? A test case would be even better. Currently, I
Have no idea how this even relates to NVDA or what attribute you're
referring to. Thanks.
|
|
Looks like you're actually talking about autofocus, not autocomplete. For future reference, please also include background information as to why you are requesting a feature; use cases, etc. A screen reader follows the focus set by the application. We can't override that without explicitly forcing focus somewhere else. Even if we wanted to, I don't think this is a good idea... and if we absolutely had to make it user configurable due to demand, it would definitely be disabled by default. The whole point of autofocus is to bring the user's interaction or attention to a specific part of the page, often for efficiency reasons. For example, when you open a search engine like Google, it makes sense that the thing you generally want to do is search. A user shouldn't assume they're going to land at the top of the page. Furthermore, if a form field gets auto focused, NVDA makes this very clear by indicating that it switched to focus mode. Having a way to disable this also raises a whole lot of other questions. Should we disable all programmatic focus movement or just on page load... and why? Should we disable scrolling to an anchor specified in a URL... and why or why not? I'm closing this as wontfix for now. We can always consider it if user demand is sufficiently high. |
|
Sorry @jcsteh - that was a multi-tasking fail. I've updated the initial comment to remove the "autocomplete" and make it "autofocus". It is titled correctly, but..... My bad. You provide some great examples for why autofocus is a good idea in some contexts. We definitely agree that adding autofocus can make a site more user friendly for the vast majority of people. In the Drupal community the module selection page is a good example. If you are an administrator of a site and you go there, the only thing you're going to want to do on that page is search for the module that you want to enable/disable. That goes for the advanced search page as well. There are a bunch of issues in the queue about this. We aren't doing that though as we've been told not to by blind users and I believe it validates WCAG Guideline 3.2. Not certain about that. I don't know if any browser supports this configuration, but I've created bugs in Chrome & Firefox. I do think it should be done by the browser. I just don't know that it should only be done in the browser. After all, NVDA is a user agent too, right? I totally agree with you that it should be disabled by default (for whoever adds it). From the W3C): "Use of the autofocus attribute can reduce usability and accessibility for users. Users of assistive technology can be adversively affected, because its use overrides the default behaviour of assistive technology to display content at the top of a document in the viewport, or announce content from the start of the document. Users with cognitive disabilities can also be disorientated by unexpected focus movement upon page load. User agents should provide a method for users to disable the autofocus attribute behaviour." I'd like to be able to add autofocus to select pages in Drupal Core and not be worried about reducing accessibility. Right now because no user agents (that I know of) support disabling autofocus we're at a bit of a loss. I can see that there will be some complexity, but I'd like to start by keeping things as simple as possible. Let's do this on page load (and just page load) so that we can start implementing |
|
The autofocus warning that @mgifford quoted in the previous comment is a proposed addition for HTML 5.2, so it's not found in the current HTML 5.1 recommendation. It was proposed in this W3C github issue, which is still currently open: add warning about use of autofocus attribute |
|
Thanks for the additional explanation.
From a screen reader perspective, IMO, users have a responsibility to learn
how to use their screen reader properly. I don't buy this argument that
reading from the top is the expected and correct behaviour in all cases. I
bet these same users would be annoyed if they opened a link including an
anchor and the screen reader always started from the top instead of the
anchor. And how would you even explain this functionality? "Ignore initial
focus"? The kind of user that is going to be bothered by this is probably
not going to understand what that means, assuming they even considered that
this might be configurable.
From an implementation perspective, this is also not trivial. We would
actually have to "guess" whether the focus was caused by "page load". We
don't even know if there is an autofocus attribute; it's just a focus to
us. While we could make an educated guess (focus event occurring within 200
ms of initial read or similar), it's still a guess. And there are other
problems such as "page load" being a blurry thing these days; often,
content gets read to the user before everything loads.
My wontfix still stands on this for now.
|
|
This is great info James. Sounds like a we've got a recommendation to use I had assumed that screen readers actually read the DOM and so would be able to look for attributes like "autofocus" and make decisions based on that. |
|
Context is the key. Developers often use unnecessary HTML features. I agree with Jamie that we should not be holding user’s hands at every little interaction. It adds complexity. If a search field needs to get autofocus, then it should. If it’s appropriate for sighted users, it should be implemented with the proviso that it be done in an accessible manner. The question I ask my clients when they propose a UI is if it makes sense for the business case they’re considering. If not, it’s superfluous.
|
|
Thank @PratikP1 - that is a good way to frame it. |
We're looking at a few Drupal issues where users are requesting autoFOCUS as per:
https://www.drupal.org/node/2846131
Can't NVDA make this a configurable option? Can't this simply be ignored by the screen reader if the user prefers?
I'm definitely pushing for this to be an option in the browser too, but don't understand why screen readers can't work with this HTML5 attribute.
The text was updated successfully, but these errors were encountered: