Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#37231 closed enhancement (wontfix)

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

Reported by: jdgrimes's profile jdgrimes Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Options, Meta APIs 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 8 years ago.
Patch from https://github.com/WordPress/WordPress/pull/220
37231.4.diff (2.1 KB) - added by jdgrimes 8 years ago.
Patch from https://github.com/WordPress/WordPress/pull/220
37231.5.diff (2.3 KB) - added by jdgrimes 8 years ago.
Patch from https://github.com/WordPress/WordPress/pull/220

Download all attachments as: .zip

Change History (17)

#1 @jdgrimes
8 years 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.


8 years ago

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


8 years ago

#4 follow-up: @afercia
8 years 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
8 years 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
8 years 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
8 years 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
8 years 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].

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


6 years ago

#10 @afercia
6 years ago

  • Milestone changed from Future Release to 5.0

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

#11 @SergeyBiryukov
6 years ago

  • Component changed from General to Options, Meta APIs

#12 @SergeyBiryukov
6 years ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#13 @pento
5 years ago

  • Milestone changed from 5.0 to 5.1

#14 @pento
5 years ago

  • Milestone 5.1 deleted
  • Resolution set to wontfix
  • Status changed from reviewing to closed

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.

Note: See TracTickets for help on using tickets.