Semantic elements for non-link links: /wp-admin/includes/widgets.php

[afercia]

See main ticket #26504

As agreed, will need styling by the UI/design team. Uses .button-reset

[Cheffheid]

The widget headers themselves are also clickable, and produce a list of clickable list items, intended to allow adding widgets to sidebars without dragging. I can not get to any of this with my keyboard and literally only just found out this functionality exists.

For example, after clicking the Calendar widget under "Available Widgets":

I presume they need semantic treatment too, but I'm not entirely sure what to do with them.

[afercia]

Thanks Jeff, this patch is just for /wp-admin/includes/widgets.php
Then, there's the JavaScript part and jQuery UI to tackle :)
Then, there's also /wp-admin/widgets.php
Please try disabling JavaScript in your browser to see the widget screen in pure PHP. Instead, when JavaScript is enabled, some controls are changed and no more focusable, as you pointed out. That should be handled in the JS part.

I'm proceeding file by file, as agreed, though in some cases editing some files requires to change also other files, I would try to be as clean as possible with patches, otherwise we will end up with very big "monster" patches, very difficult to handle.

[afercia]

Refreshed patch. Takes care of the buttons in the Customizer too. Also, a better string for translation. In the screenshot below, see the links in question, before and after the patch: they should be buttons. Please notice for a proper styling this patch needs to wait for #34242 and the review of the .button-link style.

About the accessibility part, there's a bug in Firefox/NVDA that prevents NVDA to announce the dynamic change of the aria-expanded attribute, see ​http://community.nvda-project.org/ticket/5247. We already faced this bug in the Customizer and the only workaround would be changing the markup. This issue should go in a separate ticket though.

[afercia]

Refreshed patch, now that the .button-link style was reviewed and committed in [35636]. Wondering if the .button-link CSS class should provide also the default/hover/active/focus blue colors. cc @helen
Please notice the Delete/Remove button is an edge case and has its own rule for the "red".

Screenshot with the patch applied and the buttons focused:

Left: in the Widgets screen, right: in the Widgets panel in the Customizer.

[michaelarestad]

Wondering if the .button-link CSS class should provide also the default/hover/active/focus blue colors.

@afercia Good question. I'm not sure if it's been discussed elsewhere, but I'd lean toward a yes on this versus trying to implement them every place the link style is used.

[afercia]

Replying to michaelarestad:

I'd lean toward a yes on this versus trying to implement them every place the link style is used.

I was thinking the same thing, after all if they should look like default links, it would be a bit annoying (and inefficient) having to implement the missing properties in every place.

[afercia]

Replying to michaelarestad:

Wondering if the .button-link CSS class should provide also the default/hover/active/focus blue colors.

@afercia Good question. I'm not sure if it's been discussed elsewhere

Should we open a separate ticket?

[michaelarestad]

@afercia Yep!

[afercia]

Related ticket for the .button-link improvements: #35126

[afercia]

To recap: blocked by #35126.

[afercia]

Punting, as #35126 was punted too.

[afercia]

Now that the .button-link class has been updated in [40052] it's time to move on and refresh the patch :)

[afercia]

Refreshed patch. After recent changes to the button-link CSS class in [40052], [40059], and [40358] the CSS part is a bit simplified. To recap:

• makes some links in buttons
• uses aria-expanded to announce the state of the toggle buttons
• changes two #f00 red in #dc3232, see #35622
• increases a bit the clickable area of the widget toggles
• ensures the "circular focus" doesn't get cut-off in some browsers by centering the toggle arrows within the button
• wraps a <span> element with an aria-hidden attribute around the toggle CSS generated icon as already done, for example, for the customizer menu, see comment:7
• standardizes on .toggle-indicator:before rather than :after

Note: testing with screen readers, seems NVDA has troubles in announcing the aria-expanded state change when a JS animation is running or a CSS class gets applied on an ancestor element; the order in which DOM changes, JS animations, and the aria-expanded change run, does matter and shouldn't be changed. Added a couple inline comments.

In the customizer, the widgets "Remove" and "Close" controls are now underlined, this matches other controls and should be ok based on this @celloexpressions (ping!) comment on 35126. Screenshot:

There's room for further enhancements, they should go in separate tickets. For example, other elements in the widgets screen are still not fully operable with a keyboard. Also, it would be nice to have a standardized CSS class for the "circular focus".

[celloexpressions]

@afercia the added underlines on widget remove is okay I think.

[afercia]

In 40480:

Accessibility: Make some Widgets buttons real buttons.

Links used as UI controls that behave like buttons, should be buttons.

• changes the widgets "toggle", "Delete", and "Close" links to buttons
• uses aria-expanded to announce the state of the toggle buttons
• increases a bit the clickable area of the toggle
• ensures the "circular focus" doesn't get cut-off in some browsers by centering the toggle arrows
• uses a <span> element with an aria-hidden attribute to hide CSS generated font icons from assistive technologies
• standardizes on .toggle-indicator:before rather than :after
• changes two #f00 reds in #dc3232, see #35622

Fixes #31476.

[westonruter]

r40480 introduced a regression in a widget control's contents when it is expanding, namely the widget is not taking the full
width while animating. See animated-widget-contents-width.mov​.

This seems to mostly fix the issue:

src/wp-admin/css/customize-widgets.css

@@ -87 +87 @@
         padding: 1px 10px 10px 10px;
         border-top: none;
         line-height: 16px;
+        box-sizing: border-box;
+        width: 100%;
 }
 
 .customize-control-widget_form.expanded .widget-action .toggle-indicator:before {

I say mostly because there is one other oddity in that there is a 1px border at the top of the .widget-inside while animating and then it collapses once the animation finishes.

[afercia]

I can reproduce this, but only when the browser's (Chrome or Firefox) console is open. Quick video:

​https://cloudup.com/coo28zBex7r

The real reason is when I open the console, the viewport height gets less then 700 pixels and this media query in customize-widgets.css kicks in: @media screen and (max-height: 700px) and (min-width: 981px)

At that point two things happen:

• the widget title gets a smaller height (different top and bottom padding)
• the toggle button has the same height, and now it's a bit taller than the title, see below

So seems that during the animation, the button exceeding the title height breaks things. However, I'd consider to remove the title height change. Seems this always worked this way and seems intentional (I've also commented in the stylesheet) but it makes things more difficult for a small gain. Thoughts?

If keeping the height change is preferable, the real fix would be changing this:

.widget-top .widget-action {
	padding-bottom: 8px;
}

to 6px.

[afercia]

Looking a bit into history, this feature was there since the introduction of widgets in the customizer, but completely broken now. See https://core.trac.wordpress.org/ticket/27112#comment:4

A wee bit more compact on screens sizes less than 700px tall and more than 981 wide.
​https://github.com/xwp/wp-widget-customizer/commit/d11574b598a984c7e38242bca44bc8650735fdc7

Compact widget-tops on smaller laptops, but not tablets.
​https://github.com/xwp/wp-widget-customizer/pull/88

See the original design intent:

[afercia]

31476.2.diff​ fixes the animation glitch introduced in [40480]. Also restores the original design intent. Worth noting the customizer menu items, which are very similar to the widget items, behave differently. It would be nice to introduce some consistency in the future.

[afercia]

In 40569:

Customize: Fix a visual glitch on the widget control animation introduced in [40480].

Also, restores the original design intent that was meant to "compact widget-tops
on smaller laptops, but not tablets".

See #27112.
Fixes #31476.

[joedolson]

#40677 was marked as a duplicate.