WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 9 months ago

#37231 new enhancement

Allow heading level to be specified when calling `do_meta_boxes()`

Reported by: jdgrimes Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6
Component: General Keywords: has-patch
Focuses: ui, accessibility, administration Cc:

Description

In #33557 the do_meta_boxes() function was updated to use h2 headings instead of h3, for better accessibility for the post meta boxes. However, plugins use meta boxes on a variety of different admin screens with different structures, with the result that the correct heading level will vary from one group of meta boxes to the next. I propose that we introduce a new $heading_level parameter to the do_meta_boxes() function. That will let the heading level be specified for each group of meta boxes independently, resulting in improved document structure of plugin admin screens and thus better accessibility.

The only thing that will need to be considered is that the CSS styles currently probably only apply to h2 and h3 (back-compat) meta box headings. I'd need them to also work with h4 headings as well. I'm not sure if any JS would be affected, but I figure that most JS will be using classes to identify meta box headers.

Attachments (3)

37231.diff (1.4 KB) - added by jdgrimes 10 months ago.
Patch from https://github.com/WordPress/WordPress/pull/220
37231.4.diff (2.1 KB) - added by jdgrimes 10 months ago.
Patch from https://github.com/WordPress/WordPress/pull/220
37231.5.diff (2.3 KB) - added by jdgrimes 9 months ago.
Patch from https://github.com/WordPress/WordPress/pull/220

Download all attachments as: .zip

Change History (11)

#1 @jdgrimes
10 months ago

  • Keywords has-patch added

I've added 37231.4.diff, which updates the related CSS (sans the RTL and minified versions, of course). I've tested this and it works perfectly, there is no visual difference between any of the heading levels when used as a metabox handle.

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


10 months ago

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


10 months ago

#4 follow-up: @afercia
10 months ago

  • Milestone changed from Awaiting Review to Future Release

Discussed a bit in today's accessibility weekly meeting. Yep, as a general rule core should avoid to output HTML that can't be filtered or changed. On the other hand, it's yet one more parameter... Instead of a new argument perhaps an $args array would be more flexible in the long run?
Also, maybe the CSS could be simplified and just add a generic #poststuff .hndle? (haven't tested though).

#5 in reply to: ↑ 4 ; follow-ups: @jdgrimes
9 months ago

Replying to afercia:

Discussed a bit in today's accessibility weekly meeting. Yep, as a general rule core should avoid to output HTML that can't be filtered or changed. On the other hand, it's yet one more parameter... Instead of a new argument perhaps an $args array would be more flexible in the long run?

Yes, I had considered that. So I guess we'd make $args the fourth parameter? Or were you thinking that we'd change the signature to accept a single parameter (with back-compat, of course)?

Also, maybe the CSS could be simplified and just add a generic #poststuff .hndle? (haven't tested though).

I also considered that, but like you say it would need testing. Might be worth checking if there are any other rules for .hndle that are leaving off the heading level. If so, that would seem to me to indicate that we're probably OK leaving it off here, too. Though of course that wouldn't be conclusive.

#6 in reply to: ↑ 5 @afercia
9 months ago

Replying to jdgrimes:

So I guess we'd make $args the fourth parameter?

I'd go for that :)

#7 in reply to: ↑ 5 @SergeyBiryukov
9 months ago

Replying to jdgrimes:

Might be worth checking if there are any other rules for .hndle that are leaving off the heading level.

Related: [28940]

#8 @jdgrimes
9 months ago

I've added 37231.5.diff, which adds an $args parameter instead of just $heading_level, and also updates the styles to just target .hndle. As far as the styles go, it looks like h2 is being targeted directly, without being qualified by the .hdnle class. I've left it this way, as it may be needed for back-compat, but it seems to contradict [28940].

Note: See TracTickets for help on using tickets.