Opened 3 months ago
Last modified 5 days ago
#62215 accepted defect (bug)
Remove `role="presentation" from h4 section headings in customizer nav menus
Reported by: | joedolson | Owned by: | joedolson |
---|---|---|---|
Milestone: | 6.8 | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Customize | Keywords: | has-patch needs-testing has-testing-info |
Focuses: | accessibility | Cc: |
Description
In 32715, @afercia recommended adding role="presentation"
to the headings that mark navigation menu sections in the customizer. At that time, the accordion behavior was attached directly to the heading, and it was confusing to have heading semantics and button behavior on the same element. Following [r59224], the accordion behaviors are attached to a button nested inside the heading, and restoring the semantics of those headings is reasonable.
I didn't do this in [r59924], because there are a number of other related changes that should also be made so that the heading hierarchy in the customizer makes sense.
There are also additional considerations because the headings hierarchy of the page being customized are also present on the page.
Attachments (1)
Change History (12)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
This ticket was mentioned in PR #7574 on WordPress/wordpress-develop by @hbhalodia.
3 months ago
#3
- Keywords has-patch added
#4
@
3 months ago
Hi @joedolson, I have added the patch for the ticket - https://github.com/WordPress/wordpress-develop/pull/7574.
Thank You,
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
#6
@
3 months ago
- Owner set to joedolson
- Status changed from assigned to accepted
The main reason for changing these from role="presentation"
is to improve the overall headings hierarchy when the customizer is open.
At some level, the customizer interface needs to be considered as a separate tree, because it's effectively impossible to integrate it with every theme, since each theme will use its own hierarchy.
But the customizer hierarchy could at least be self-consistent.
I think the main change we should make is to alter the "You are customizing {site title}" to an H2, so that there's a wrapping context for the rest of the customizer.
In theory, what that would mean is that for well-structured themes that start with an H1, we'd have an h2 tree that existed before the theme structure for the customizer; then we'd get to the h1, which would be the theme.
For themes that are poorly constructed, well...not much we can do.
That h2 would also give a stable point of reference in the headings structure, since all of the other headings change dynamically depending on which panel is active.
This ticket was mentioned in PR #8001 on WordPress/wordpress-develop by @guillaumeturpin.
6 weeks ago
#7
#8
@
3 weeks ago
@joedolson This is a Pretty straightforward patch for the ticket. Works fine. Have to combine both patches though.
I have tested the proposed change to remove role="presentation" from the <h4> section headings in the Customizer navigation menus. It works as expected without issues. I recommend proceeding with this update.
#9
@
3 weeks ago
I’ve just tested the patch that changes the <span> tag to the <h2> tag. The test was successful, and everything appears to be working as expected so far.
#10
@
6 days ago
Test Report
This report validates whether the indicated patch works as expected.
Tested Patch: https://github.com/WordPress/wordpress-develop/pull/8001
Environment
OS: Windows 11
Web Server: WordPress Playground
PHP: Playground Default
WordPress: current version
Browser: Chrome
Theme: Twenty Seventeen
Active Plugins: None
Actual Results
✅ Issue resolved with a patch.
#11
@
5 days ago
- Keywords needs-testing has-testing-info added
The updated patch adds styling so that
1) The visible heading doesn't inherit the heading's font weight and margins and
2) To put the hidden headings (used in mobile views) back into the DOM so that the menu and widget selectors have an appropriate heading ancestor.
Because the panels are inserted after the previewer, this still doesn't result in a perfect headings hierarchy, but I think that it is going to significantly improve findability to have *some* headings for these elements over having none. The customizer headings are internally consistent.
It might be nice to also update the customizer so that the panel insertions happen after the customizer controls, rather than after the preview, but I'm not sure that needs to be resolved as part of this ticket.
To test:
1) Open the customizer. Verify there is no visual difference, but that the top level heading (You are customizing / Theme Name) is an h2
heading.
2) Expand the Menus editor to reach the 'Add Items' panel.
3) Inspect headings to verify that there is an H3 (not visible in desktop) that gives Add Menu Items context & the section headings for menu items are H4.
Trac ticket: https://core.trac.wordpress.org/ticket/62215