WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 4 months ago

Last modified 4 months ago

#31476 closed defect (bug) (fixed)

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

Reported by: afercia Owned by: afercia
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.1
Component: Widgets Keywords: semantic-buttons has-patch has-screenshots
Focuses: ui, accessibility, javascript Cc:

Description

See main ticket #26504

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

Attachments (6)

31476.patch (5.3 KB) - added by afercia 2 years ago.
31476.2.patch (8.7 KB) - added by afercia 22 months ago.
31476.3.patch (10.6 KB) - added by afercia 22 months ago.
31476.diff (13.8 KB) - added by afercia 5 months ago.
animated-widget-contents-width.mov (420.8 KB) - added by westonruter 4 months ago.
31476.2.diff (1.5 KB) - added by afercia 4 months ago.

Download all attachments as: .zip

Change History (44)

@afercia
2 years ago

#1 @afercia
2 years ago

  • Keywords has-patch added

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


2 years ago

#3 @Cheffheid
2 years ago

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":
http://i.imgur.com/493fV6P.png

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

Last edited 2 years ago by Cheffheid (previous) (diff)

#4 @afercia
2 years ago

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.

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


2 years ago

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


2 years ago

@afercia
22 months ago

#7 @afercia
22 months ago

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.

https://cldup.com/7Jj0tPrItq.png

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


22 months ago

@afercia
22 months ago

#9 @afercia
22 months ago

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:

https://cldup.com/-FbKnKcFZL.png

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

#10 @westonruter
22 months ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to afercia
  • Status changed from new to assigned

#11 @afercia
21 months ago

  • Milestone changed from Future Release to 4.5

#12 follow-ups: @michaelarestad
21 months ago

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.

#13 in reply to: ↑ 12 @afercia
21 months ago

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.

#14 in reply to: ↑ 12 @afercia
21 months ago

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?

#15 @michaelarestad
21 months ago

@afercia Yep!

#16 @afercia
20 months ago

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

#17 @afercia
18 months ago

  • Keywords ui-feedback added

To recap: blocked by #35126.

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


18 months ago

#19 @afercia
18 months ago

  • Milestone changed from 4.5 to Future Release

Punting, as #35126 was punted too.

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


9 months ago

#21 @afercia
9 months ago

  • Keywords needs-refresh added
  • Milestone changed from Future Release to 4.8

#22 @afercia
8 months ago

  • Keywords semantic-buttons added

#23 @afercia
6 months ago

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

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


6 months ago

@afercia
5 months ago

#25 @afercia
5 months ago

  • Keywords commit added; ui-feedback needs-refresh removed

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:

  • changes some links to 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:
https://cldup.com/GwFmZ8wPny.png

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

Last edited 4 months ago by afercia (previous) (diff)

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


5 months ago

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


5 months ago

#28 @celloexpressions
4 months ago

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

#29 @afercia
4 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

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


4 months ago

#31 @westonruter
4 months ago

  • Keywords needs-patch added; has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

     
    8787        padding: 1px 10px 10px 10px; 
    8888        border-top: none; 
    8989        line-height: 16px; 
     90        box-sizing: border-box; 
     91        width: 100%; 
    9092} 
    9193 
    9294.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.

#32 @afercia
4 months ago

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

https://cldup.com/VDknjrHPcZ.png

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.

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


4 months ago

#34 @afercia
4 months ago

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:

https://cldup.com/Wshe8u_3Df.png

Last edited 4 months ago by afercia (previous) (diff)

@afercia
4 months ago

#35 @afercia
4 months ago

  • Keywords has-patch has-screenshots added; needs-patch removed

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.

#36 @afercia
4 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#37 @joedolson
4 months ago

#40677 was marked as a duplicate.

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


4 months ago

Note: See TracTickets for help on using tickets.