Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#47759 closed defect (bug) (fixed)

Suboptimal tab order on the installation success screen

Reported by: johnbillion's profile johnbillion Owned by: audrasjb's profile audrasjb
Milestone: 5.5 Priority: normal
Severity: normal Version: 5.1
Component: Upgrade/Install Keywords: has-patch
Focuses: accessibility Cc:


On the success screen shown after successful installation (wp-admin/install.php?step=2), the W icon is the first focused element when the user presses the tab key. The first element to be focused should be the Log In button.

This is a regression caused by [44545].

Attachments (4)

install step2.png (77.0 KB) - added by afercia 4 years ago.
install.php step 2
setup-config step2.png (76.4 KB) - added by afercia 4 years ago.
setup-config.php step 2
47759.diff (1.5 KB) - added by audrasjb 4 years ago.
Unlink WordPress logo in setup screens
47759.2.diff (2.1 KB) - added by johnbillion 3 years ago.

Download all attachments as: .zip

Change History (20)

#1 @lwill
4 years ago

Hi there,

(first ticket I am working on, I am really excited)

I am wondering if it would be correct to use tabindex="1" attribute, as it's not recommended to disturb normal DOM hierarchy

But maybe in that case, the Login Button is more important in terms of accessibility than the W logo.

autofocus is not possible on an <a> element, which would be interesting to just type enter when the user is on install.php?step=2

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#3 @afercia
4 years ago

  • Keywords 2nd-opinion added

In [44545] / #42632 the negative tabindex was removed to provide a native tab order. Tabindex attributes with a negative value should be used only to make non-focusable elements focusable via JavaScript.

Removing natively focusable elements from the tab order is often not ideal: why WordPress should put a link (or a button or whatever focusable element) in a page and then make it not usable for some users?

When a page, or a set of pages like in a multi-step flow, have a very specific, unique, user task it might make sense to set focus on the first form field or actionable item in that page. In all cases, this should be carefully evaluated. For example:

  • does relevant content gets "skipped" by setting initial focus on an element?
  • would screen reader users have a clue there's important content before the focused element?
  • would the skipped content still be visible for users with low vision?
  • same for users with cognitive impairments, etc.

I'd need to check again the installation process but at a first glance I'm not fully sure this can be considered a regression.

#4 @afercia
4 years ago

Going through the installation process, seems to me there are 2 similar cases: the install.php?step=2 page mentioned by @johnbillion and the setup-config.php?step=2 page. See attached screenshots.

4 years ago

install.php step 2

4 years ago

setup-config.php step 2

#5 @afercia
4 years ago

While the textual information in the two pages shown above is minimal, I'm not sure skipping that info and setting focus on the button would be beneficial for all users. For example. screen reader users wouldn't have a clue there's actually some content before the auto-focused button.

On the other hand, the current implementation guarantees a native tab order and requires to sighted keyboard users only one additional Tab key press.

Not fully sure these pages text is actually that useful and maybe should be reviewed. Also, auto-focusing an element should be always evaluated on a case by case basis. See for example #40302.

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.

4 years ago

#7 @audrasjb
4 years ago

  • Keywords reporter-feedback added

As said during today's accessibility bug scrub, while we agree that it would be cool to directly tab to the first interesting actionable item, it would be definitely better to keep the native tab order.

The only way to "fix" the "issue" of having the WordPress logo focusable is to unlink this logo. If this is not possible for some reasons, it's probably better to close this ticket as wontfix.

Question: do we really need a link to on this logo, during installation process?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#9 @audrasjb
4 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to audrasjb
  • Status changed from new to accepted

As per today’s accessibility bug scrub, the accessibility team proposal is to unlink the logo.
Patch welcome :)

#10 @afercia
4 years ago

  • Keywords 2nd-opinion reporter-feedback removed

Summarizing the team reasoning:

  • After all: these are installation screens.
  • Users are in the process of installing WordPress.
  • That likely means they just downloaded WordPress and even if that’s not the case it’s very likely they know it’s WordPress.
  • Why would they need a link to in the first place?

Seems there's no good reason to have the logo linked in these specific pages.

Last edited 4 years ago by afercia (previous) (diff)

#11 @johnbillion
4 years ago

I'm +1 for removing the link from the logo.

4 years ago

Unlink WordPress logo in setup screens

#12 @audrasjb
4 years ago

  • Keywords has-patch added; needs-patch removed

In 47759.diff:

  • Unlink WordPress logo on setup screens.
  • Changes in the stylesheet to insure to keep the same visual rendering than before.

The patch is tested and looks good on my side.


#13 @johnbillion
3 years ago

  • Milestone changed from Future Release to 5.5

3 years ago

#14 @johnbillion
3 years ago

47759.2.diff removes the link from install.php too

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

3 years ago

#16 @johnbillion
3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 47746:

Upgrade/Install: Unlink the logo on the installation and config setup screens.

This allows for a natural tab order during installation, without negatively impacting users who use the keyboard for navigation, those who use a screen reader, or those who use neither.

Props lwill, afercia, audrasjb.

Fixes #47759

Note: See TracTickets for help on using tickets.