Problem/Motivation

Setting autofocus in certain cases can be a usability improvement, provided it meets certain criteria.

The install forms currently do not have autofocus set on the first form control.

Steps to reproduce:

  1. Open install prompt
  2. Press "up" or "down" keys. If focus were on the language select form, the select menu would open and a different option would be selected. As it is, nothing happens.

Screenshots (first form control doesn't have focus):

Proposed resolution

Add autofocus to the first elements on each form.

The two most relevant issues are #2096347: Add "autofocus" attribute to the module search and #1932958: Cursor shouldn't be moved to module search field, which suggest a general tendency against using autofocus. The primary concern is that users will miss help text located prior to the form control autofocuses. However, on these screens, there is no help text before the first control element. So, these concerns are moot. (@mgifford quotes from Jared about that concern.)

In #2096347: Add "autofocus" attribute to the module search, @mgifford notes that Drupal uses autofocus on /user and /user/password, but not /user/register or /search/node, and has observed that there is no clear Drupal policy on using autofocus. @Falcon03 has expressed a preference against autofocus in general. The install forms are at least as non-controversial as /user and /user/password.

User interface changes

The first form control will have keyboard focus on page load.

CommentFileSizeAuthor
#7 autofocus-2787599-7.patch2.83 KBakalata
#4 autofocus-2787599-4.patch1.42 KBmiwayha
Screen Shot 2016-08-21 at 11.02.50 AM.png105.56 KBmiwayha
Screen Shot 2016-08-21 at 11.00.11 AM.png68.24 KBmiwayha
Screen Shot 2016-08-21 at 11.00.16 AM.png129.58 KBmiwayha
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

miwayha created an issue. See original summary.

miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented
Issue summary: View changes
miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented
Issue tags: +Accessibility, +Usability, +keyboard focus
miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented
Status: Active » Needs work
FileSize
autofocus-2787599-4.patch1.42 KB

Here's a patch that addresses the language select form and the configure site form. The other forms have radio buttons, so that will take a bit more work as it's not quite so direct.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented
Priority: Minor » Normal

Thanks @miwayha!

Promoting to normal per https://www.drupal.org/core/issue-priority#normal.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented
Status: Needs work » Needs review
Issue tags: +Needs accessibility review

It would be great to get an accessibility maintainer's review on the proposed improvement (given the information in the summary).

I think we can either fix the radios in this patch or in another one.

akalata’s picture

akalata CreditAttribution: akalata commented
FileSize
autofocus-2787599-7.patch2.83 KB

@miwayha, I was able to get the radio buttons working on autofocus just fine w/ Firefox.

Also, are we using the right language to describe the UI change? It's not a visual focus, but a keyboard focus (which typically comes with a visual component when rendered by the browser).

miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented

@akalata ah, you're right about the language. Nice catch.

miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented
Issue summary: View changes
mlhess’s picture

mlhess CreditAttribution: mlhess as a volunteer commented

Nice job seeing the Drupal community work. miwayha and akalata are in the same room and did not know it.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford at OpenConcept Consulting Inc. commented

There are problems with changing the default focus like this. Most screen reader users assume a page starts at the top, not in the middle.

miwayha’s picture

miwayha CreditAttribution: miwayha as a volunteer commented

@mgifford, thanks for commenting. I agree with the general concern about not setting an autofocus.

But, the install prompts are a special case. The only circumstances in which one would arrive at these forms is if, well, one set out to install Drupal, so their expectation would be explicitly to encounter interactions that allowed them to do that. Furthermore, the expected interaction is literally the only interaction that the page supports. Concerns about starting a page in the "middle" rather than the "top" also don't make sense in this case. There's not really any content at all before these forms, so there's nothing for a user to miss by setting focus on the first form element itself. (Even worse, the only content before this is an aside element, which semantically means that the content is separate and only tangentially related to the primary content.)

So by not setting autofocus, we force the user to navigate past information that is semantically not necessary, affords no interaction or navigation, in a scenario where the only way to get to the page is to deliberately seek out to perform the only interaction that the page supports. I tried to pay pretty close attention to the reasoning behind the autofocus decisions in the issues I relate to (especially your link to Jared's discussion of setting autofocus on Google), and I think this is a less controversial case than the other places that Drupal already sets autofocus.

I don't think a general "users expect the screen reader to start at the top" heuristic is helpful in such a special case. I'd be more persuaded if there were some argument specific to these screens.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commented
Issue tags: +autofocus

Granted, the install forms are a good example of pages where the form is the single available action on the page.

The main concern with autofocus here is that the focus is placed after any error messages. When you first load an installation step, there won't be any messages on screen. There are many mandatory fields during the installation process which are mandatory, or have some other validation. If a user omits one, the form will be returned with errors, and autofocus would bypass these.

Our error message area is marked up with role="alert". In theory these should be announced (they are a special case of aria-live region) but in most cases screenreaders don't actually do so; in practice they only announce the message if it changes dynamically. The only browser/AT combination I know of where role="alert" is announced on page load is ChromeVox - this behaviour seems to be very recent, and it represents just a small share of the user base.

Tagging, because I'm gathering up issues where autofocus has been requested. I hope to start a policy-issue for it soon.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commented
Status: Needs review » Closed (won't fix)
Issue tags: -Needs accessibility review

RE: #12

So by not setting autofocus, we force the user to navigate past information that is semantically not necessary, affords no interaction or navigation, in a scenario where the only way to get to the page is to deliberately seek out to perform the only interaction that the page supports.

This isn't a serious issue because:

  • There is no interactive content before the form itself. It can easily be reached by pressing TAB a couple of times.
  • There are headings on the page. Screen reader users can navigate to the form quite quickly using heading-based navigation.
  • There are landmark regions on the page, and the form is contained in the main region. Screen readers and other AT provide ways to quickly navigate by landmark region.
  • The amount of content before the first form element is rather short in any case, just a simple list of step names.

So we satisfy WCAG 2.0 SC 2.4.1 Bypass Blocks very well, and autofocus is not needed to address that. Meanwhile we must consider that autofocus would bypass important error messages.

I disagree with the notion that the sidebar content is "semantically not necessary". For any multi-step process it's important to be able to identify how far though the process you are. In this case, we have some visually-hidden text (providing hints equivalent to the visual styles): a heading ("installation steps") , as well as "done" and "active" for specific steps. This helps to address WCAG 2.0 SC 2.4.8 Location (at level AAA, which is going above our accessibility QA gate level).

Until a sufficient number of user agents provide a means of disabling autofocus (per the new advice in the HTML5.2 candidate recomendation), I'm disinclined to allow further instances of autofocus.

When browsers do provide a means of disabling autofocus, we can revisit this.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford at OpenConcept Consulting Inc. commented

@andrewmacpherson am I missing something? There's good support for autofocus in CanIUse.com http://caniuse.com/#search=autofocus

Could it be that the browsers are ahead of the spec?

andrewmacpherson’s picture

andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commented

That caniuse chart is about browsers supporting autofocus behaviour - i.e. whether the attribute is enough to move the focus on page load.

What I'm waiting on is this awesome new section about autofocus in the HTML 5.2 candidate recommendation (emphasis mine):

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 recall seeing some upstream issues about this in one or two browsers ;-)

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford at OpenConcept Consulting Inc. commented

I love that the W3C uses GitHub - here's a draft of 5.3's autofocus section:
https://w3c.github.io/html/single-page.html#element-attrdef-formelements...

Also useful is Mozila's docs on autofocus:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLSelectElement/autof...

I couldn't find anything more specific though on either FF or Chrome in my search today.