Disabled fieldset does not convey the disabled state of controls

[anevins]

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="">


        <legend>Selection:</legend>


        <div class="nowrap">


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


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


            </label>


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


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


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


            </label>


        </div>


    </fieldset>


    ...


    .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">


        <legend>Selection:</legend>


        <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" ...>


        </div>


    </fieldset>


    ...


    .imgedit-settings .disabled,


    .media-disabled,


    .disabled legend {


        color: #444;


        opacity: 0.5;


    }


    input.disabled,


    input:disabled,


    select.disabled,


    select:disabled,


    textarea.disabled,


    textarea:disabled {


        opacity: 0.5;


    }

Relevant standards

• 1.3.3 Sensory Characteristics (Level A) ​https://www.w3.org/TR/WCAG20/#content-structure-separation-understanding

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

[kirasong]

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:
​https://github.com/WordPress/wordpress-develop/blob/master/src/js/_enqueues/lib/image-edit.js#L83
and
​https://github.com/WordPress/wordpress-develop/blob/master/src/wp-admin/includes/image-edit.php#L64

[anevins]

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

[joemcgill]

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

[afercia]

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.

[afercia]

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.

[afercia]

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.

[afercia]

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.

[dinhtungdu]

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.

[welcher]

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.

[kirasong]

Unassigning this from myself so that others that understand the issue better feel more free to work on it.

[audrasjb]

Hi,
This ticket still needs a patch and 5.4 beta 1 is tomorrow. Let's move this ticket to 5.5.

[afercia]

This ticket was discussed during today's accessibility bug-scrub. This ticket needs an owner and needs testing to check if there are still occurrences of <fieldset … disabled>.
If so:

• set the disabled attribute on the fields directly

Also still to do:

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

[joedolson]

Note: this is where setDisabled was changed to apply to fieldsets in imageEdit. Haven't found other instances where this is done.

However, if there are other examples done the same way (assign disabled to any element in a collection), those are going to be pretty tough to find.

I reviewed everything that turned up in code for either 'disabled' or 'fieldset' and there are no other obvious cases where a fieldset is assigned the disabled status. I can't say with 100% confidence that it doesn't exist, but it's clearly rare.

[joedolson]

Could've sworn I included the link there... https://core.trac.wordpress.org/changeset/36223

[afercia]

This ticket was discussed during today's accessibility bug-scrub: it appears there are no more cases where a disabled attribute is set on a fieldset. Agreed to close the ticket as "fixed".