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

[jdgrimes]

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.

[jdgrimes]

Patch from ​https://github.com/WordPress/WordPress/pull/220

[jdgrimes]

Patch from ​https://github.com/WordPress/WordPress/pull/220

[jdgrimes]

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.

[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?
Also, maybe the CSS could be simplified and just add a generic #poststuff .hndle? (haven't tested though).

[jdgrimes]

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.

[afercia]

Replying to jdgrimes:

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

I'd go for that :)

[SergeyBiryukov]

Replying to jdgrimes:

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

Related: [28940]

[jdgrimes]

Patch from ​https://github.com/WordPress/WordPress/pull/220

[jdgrimes]

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

[afercia]

+1 I'd second this ticket because core shouldn't ever output HTML that is not filterable or can be changed in some way.

[pento]

Given that meta boxes will ultimately be deprecated in favour of blocks, I'm inclined to not add new features to the meta box API.