Make WordPress Core

Opened 9 months ago

Last modified 3 days ago

#47142 assigned defect (bug)

Disabled fieldset does not convey the disabled state of controls

Reported by: anevins Owned by: mikeschroder
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-screenshots wpcampus-report form-controls needs-patch
Focuses: ui, accessibility Cc:
PR Number:


Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15299

  • Severity:
    • Medium
  • Affected Populations:
    • Blind
    • Low-Vision
    • Motor Impaired
    • Cognitively Impaired
  • Platform(s):
    • All / Universal
  • Components affected:
    • Edit Media

Issue description
On the Edit Media page, when users haven't made any selections for
cropping the image, the "Selection" legend is grayed-out to indicate
that this section is disabled, and the inputs are meant to be disabled
by use of the disabled attribute on the fieldset itself.

The only visible clue that the fields are meant to be disabled is that
the legend is a slightly lighter color; the fields themselves appear
identical to enabled fields. The state is only revealed to users by a
mouse user's inability to click inside, and a keyboard user's
inability to focus them. Speech recognition software may indicate that
the disabled fields are enabled when users call out fields by type.

Additionally, the change of style is not even conveyed in IE11, in which
the "Selection" legend looks identical to enabled groups.

This can be confusing to users with cognitive disabilities and speech
recognition users.

Issue Code

    <fieldset id="imgedit-crop-sel-159" class="imgedit-crop-sel disabled" disabled="">


        <div class="nowrap">

            <label><span class="screen-reader-text">selection width</span>

                <input type="text" id="imgedit-sel-width-159" ...>


            <span class="imgedit-separator">×</span>

            <label><span class="screen-reader-text">selection height</span>

                <input type="text" id="imgedit-sel-height-159" ...>





    .imgedit-settings .disabled, .media-disabled {

        color: #a0a5aa;


Remediation Guidance
While the disabled attribute is allowed on <fieldset>
elements, it should be avoided as the sole method of conveying disabled
states, because it does not universally apply the disabled state to
the fields in all assistive technologies.

Instead, place the disabled attribute on the fields directly.

Explicitly set the <legend> style changes with a legend
selector so that it applies in all browsers, and style disabled controls
to be more obviously disabled; the current slight difference in
box-shadow is difficult to discern even for users without visual
disabilities. Ideally, the styling would use opacity rather than
color properties so that the difference is still visible in Windows
High Contrast themes.

Also ensure that the relationship between the <label> and
<input> elements is explicitly defined using for and id
attributes, for better compatibility with assistive technologies.

Recommended Code

    <fieldset id="imgedit-crop-sel-159" class="imgedit-crop-sel disabled">


        <div class="nowrap">

            <label for="imgedit-sel-width-159"><span class="screen-reader-text">selection width</span></label>

            <input disabled type="text" id="imgedit-sel-width-159" ...>

            <span class="imgedit-separator">×</span>

            <labelfor="imgedit-sel-height-159"><span class="screen-reader-text">selection height</span></label>

            <input disabled type="text" id="imgedit-sel-height-159" ...>




    .imgedit-settings .disabled,


    .disabled legend {

        color: #444;

        opacity: 0.5;







    textarea:disabled {

        opacity: 0.5;


Relevant standards

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-81 in Tenon's report

Attachments (2)

57185836-13e6a100-6e88-11e9-902b-944da271258b.png (95.1 KB) - added by anevins 9 months ago.
Screenshot at Nov 22 22-47-00.png (276.1 KB) - added by dinhtungdu 2 months ago.

Download all attachments as: .zip

Change History (21)

#1 @afercia
9 months ago

  • Keywords form-controls added

#2 @afercia
9 months ago

  • Milestone changed from Awaiting Review to 5.3

This ticket was mentioned in Slack in #core-media by anevins. View the logs.

8 months ago

#4 @mikeschroder
8 months ago

Haven't had a chance to dig too deeply yet, but I suspect this is likely a problem anywhere the cropper shows up.

Two places of interest so far:

#5 @anevins
5 months ago

Hey @mikeschroder , just checking you're okay owning this for 5.3? If not, no pressure, we can get this reassigned.

This ticket was mentioned in Slack in #core-media by anevins. View the logs.

5 months ago

#7 @joemcgill
5 months ago

  • Owner set to mikeschroder
  • Status changed from new to assigned

Assigning to @mikeschroder per Slack discussions. Mike, feel free to remove if this is incorrect.

#8 @afercia
5 months ago

Looks like something has changed between WP 5.0 and 5.1:

  • on 5.0: edit an image and on load (no selection yet) the fieldset has a disabled attribute
  • on 5.1: no disabled attribute

Not sure what changed, should be investigated a bit.

#9 @afercia
5 months ago

See changes from [42404]. Not sure there's now a scenario where these specific fieldsets are disabled.

However, there's the need to check across all core for other cases where a fieldset might be disabled with a disabled attribute:

<fieldset ... disabled>

and if there are, implement the recommended pattern to address the issue described above.

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

4 months ago

#11 @afercia
4 months ago

  • Milestone changed from 5.3 to Future Release

Discussed during today's accessibility bug-scrub: giving WordPress 5.3 Beta 2 is very close, sadly agreed to punt this ticket to Future Release.

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

3 months ago

#13 @afercia
3 months ago

  • Keywords needs-testing added; needs-patch removed
  • Milestone changed from Future Release to 5.3.1

Discussed during today's accessibility bug-scrub: agreed the issue on this ticket needs to be tested again as it seems to not be the case any longer. If there are no other occurrences of this pattern in core, this ticket could be closed. The testing part seems doable for the next minor release. Milestoning accordingly.

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

2 months ago

#15 @dinhtungdu
2 months ago

Tested with r46758. The selection label and input fields look like enabled even before I make a selection for
cropping the image. Another problem is those selection input fields are not disabled, I can input value to those fields before making any selection. See the screenshot below.

I think the ideal behavior should be disabling them until the users make a selection, then enabling them for easier to update the selection area.

Last edited 2 months ago by dinhtungdu (previous) (diff)

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

7 weeks ago

#17 @welcher
7 weeks ago

  • Keywords needs-patch added

#18 @welcher
7 weeks ago

  • Keywords needs-testing removed
  • Milestone changed from 5.3.1 to 5.4

Hi, All,

As per today's bug scrub, we're moving this to 5.4. This does seem to be an issue but just not a regression. If a patch is available in the next few days, we can look at getting it into 5.3.1.

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

3 days ago

Note: See TracTickets for help on using tickets.