Problem/Motivation

In #2994702-107: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`, @rainbreaw found a small problem while doing accessibility review:

When in the dialog itself, if you rely on the tab key to navigate from field to field and fill out the form, your tab focus is captured by something mysterious between the caption checkbox and the submit button. Tabbing again will move focus to submit, so this is not a blocker as much as a possible point of confusion. It also appears to behave the same way on standard image embed, as well, and so may belong in a separate issue.

We determined that this is a thing which already exists in editor dialog boxes in core (quoting Wim Leers in #2994702-112: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`):

This is a pre-existing problem with jQuery UI dialogs — the same is true for EditorImageDialog.

Proposed resolution

We fixed it in the dialog added by that issue by setting a tabindex="-1" on a particular part of the dialog. Ideally the other dialogs in core would get this fixed too.

Remaining tasks

Add the -1 tabindex to other editor dialogs in core.

User interface changes

No visible changes, but keyboard users will find the dialogs slightly more pleasant to use.

API changes

None.

Data model changes

None.

Release notes snippet

TBD

CommentFileSizeAuthor
#4 3078966-2.patch1.32 KBwim leers

Comments

phenaproxima created an issue. See original summary.

Wim Leers credited oknate.

Wim Leers credited rainbreaw.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Needs review
StatusFileSize
new 3078966-2.patch1.32 KB

Thanks for creating this issue!

Crediting the people involved in discovering this problem and the fix in the other issue.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Needs manual testing

Marking for manual testing, since @oknate ran into trouble simulating tab key presses in tests, and it might be tricky to implement that.

andrewmacpherson’s picture

andrewmacpherson commented
Status: Needs review » Needs work

Possible duplicate of #3037781: Accessibility problem with invisible buttons in AJAX dialogs? I'm not sure how many different JS libraries we have for making a dialog. There's dialog.js, dialog.ajax.js, and some module-specific ones like dialog.views.js.

If the intention is to hide this button from everyone, then using tabindex="-1" is insufficient.

  • The negative tabindex will prevent it gaining focus as a result of pressing tab.
  • It may still be operable-but-not-perceivable-or-understandable with speech control. Saying "click button" or "show numbers" can offer visually-hidden controls as numbered options for the user to choose.
  • It will also be discoverable by a screen reader user, who has dropped out of forms mode into browse mode, and may be operable using the "list all buttons" or "jump to next button" tools. I'll try testing this manually.

If the intention is to hide this submit button from everyone, then use display:none;.

I tried setting the HTML hidden attribute in the FAPI code, but that didn't work. Something is giving the element an inline style of display:block, which overrides the user-agent styling for the [hidden] attribute.

bnjmnm’s picture

bnjmnm
he/him
Primary language English
Location Ann Arbor, MI
commented
Status: Needs work » Closed (duplicate)

I can confirm this is a duplicate of #3037781: Accessibility problem with invisible buttons in AJAX dialogs, and there's an explanation there as to why tabindex must be used instead of display:none;
The inputs still need to be displayed in order to submit with the return key -- but should otherwise not exist as they have been duplicated in the dialog buttonpane.