WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 4 weeks ago

#47759 accepted defect (bug)

Suboptimal tab order on the installation success screen

Reported by: johnbillion Owned by: audrasjb
Milestone: Future Release Priority: normal
Severity: normal Version: 5.1
Component: Upgrade/Install Keywords: has-patch
Focuses: accessibility Cc:
PR Number:

Description

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 (3)

install step2.png (77.0 KB) - added by afercia 2 months ago.
install.php step 2
setup-config step2.png (76.4 KB) - added by afercia 2 months ago.
setup-config.php step 2
47759.diff (1.5 KB) - added by audrasjb 8 weeks ago.
Unlink WordPress logo in setup screens

Download all attachments as: .zip

Change History (15)

#1 @lwill
3 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.


3 months ago

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

@afercia
2 months ago

install.php step 2

@afercia
2 months ago

setup-config.php step 2

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


2 months ago

#7 @audrasjb
2 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.


2 months ago

#9 @audrasjb
2 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
2 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 4 weeks ago by afercia (previous) (diff)

#11 @johnbillion
8 weeks ago

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

@audrasjb
8 weeks ago

Unlink WordPress logo in setup screens

#12 @audrasjb
8 weeks 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.

Cheers,
Jb

Note: See TracTickets for help on using tickets.