Make WordPress Core

Opened 3 months ago

Last modified 9 hours ago

#60774 accepted enhancement

Make the user_login field readonly instead of disabled on the profile screen

Reported by: roytanck's profile roytanck Owned by: audrasjb's profile audrasjb
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: Users Keywords: has-patch commit
Focuses: accessibility, administration Cc:

Description

This came up in an accessibility audit of one of the sites I work on. On the profile edit screen in wp-admin, the username is displayed using an input field with the disabled attribute. This field is skipped by screen readers, which leads to a "loss of information" for visually impaired users.

It's better to use readonly here. This is exactly what the field is used for, and readonly fields are read by screen readers.

Attachments (1)

60774.diff (1.0 KB) - added by roytanck 3 months ago.
Patch that makes the user_login field readonly instead of disabled.

Download all attachments as: .zip

Change History (11)

@roytanck
3 months ago

Patch that makes the user_login field readonly instead of disabled.

#1 @SergeyBiryukov
3 months ago

  • Focuses administration added
  • Milestone changed from Awaiting Review to 6.6

#2 @SergeyBiryukov
3 months ago

  • Keywords has-patch added

#3 @audrasjb
3 months ago

  • Keywords commit added
  • Owner set to audrasjb
  • Status changed from new to accepted

This proposal and the associated patch looks good to me, thanks.

#4 @rajinsharwar
5 weeks ago

  • Keywords 2nd-opinion added

Though this is working, still I am still wondering about this dark focus change in this field.

Before: https://prnt.sc/KchVURPJkIxI
After: https://prnt.sc/-3MQdWlekexp

Isn't this a little hard to identify if that field is actually disabled or not? Should we add an extra class, and add the CSS from the input:disabled styles we have?

#5 @roytanck
5 weeks ago

@rajinsharwar From a usability perspective I think it makes sense for there to be a visual distinction between fields that are readonly versus disabled. The instruction text also makes it very clear that this field's value cannot be changed.

If we're unhappy with how the field now looks, perhaps we should introduce new styling specifically for readonly fields?

#6 @audrasjb
5 weeks ago

  • Keywords commit removed

Unlike on disabled inputs, readonly ones need a compliant contrast ratio so I think the implementation proposed in 60774.diff works fine. Also, there is indeed a detailed instruction sentence for that field, so I believe we're good to go with that implementation.

(removing commit workflow keyword just to make sure to keep this ticket a chance to be discussed before committing)

#7 @audrasjb
2 weeks ago

  • Keywords commit added; 2nd-opinion removed

Alright, let's go with the proposed patch.

Last edited 2 weeks ago by audrasjb (previous) (diff)

#8 @joedolson
11 days ago

Agreeing that this patch and styling is sufficient. If a user is not able to distinguish the color change, the text description provides a secondary hint that the field is not editable.

LGTM!

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


7 days ago

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


9 hours ago

Note: See TracTickets for help on using tickets.