Make WordPress Core

Opened 14 months ago

Closed 5 months ago

#47759 closed defect (bug) (fixed)

Suboptimal tab order on the installation success screen

Reported by: johnbillion Owned by: 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 14 months ago.
install.php step 2
setup-config step2.png (76.4 KB) - added by afercia 14 months ago.
setup-config.php step 2
47759.diff (1.5 KB) - added by audrasjb 13 months ago.
Unlink WordPress logo in setup screens
47759.2.diff (2.1 KB) - added by johnbillion 6 months ago.

Download all attachments as: .zip

Change History (20)

#1 @lwill
14 months 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 https://web.dev/control-focus-with-tabindex#avoid-tabindex-greater-0

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.

14 months ago

#3 @afercia
14 months 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
14 months 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.

14 months ago

install.php step 2

14 months ago

setup-config.php step 2

#5 @afercia
14 months 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.

14 months ago

#7 @audrasjb
14 months 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 w.org on this logo, during WordPress.org installation process?

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

13 months ago

#9 @audrasjb
13 months 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
13 months 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 wordpress.org in the first place?

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

Last edited 12 months ago by afercia (previous) (diff)

#11 @johnbillion
13 months ago

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

13 months ago

Unlink WordPress logo in setup screens

#12 @audrasjb
13 months 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
7 months ago

  • Milestone changed from Future Release to 5.5

6 months ago

#14 @johnbillion
6 months ago

47759.2.diff removes the link from install.php too

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

5 months ago

#16 @johnbillion
5 months 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.