Inappropriate content in headings on admin screens

[grahamarmfield]

At the top of the themes.php page there is a second level heading which contains the following:

• The text Themes
• The number of themes being shown
• The Add New link
• The Search installed themes input and label

So on an example page a screen reader voices "Themes7 Add New Search Installed Themes".

The use of headings is good for accessibility as it gives screen reader users a way of finding what they are looking for on a page. But in this case there is too much within the heading.

Suggested solution: Keep the word Themes within the heading and move the other elements outside the <h2>...</h2>

#a11y-headings

[SergeyBiryukov]

The "Add New" links are a part of the <h2> element on other screens as well, so if that should be changed, I guess we have to do it consistently in a separate ticket.

26601.patch​ moves the label and the input outside of <h2> while keeping the same visual appearance.

[GrahamArmfield]

Believe patch needs refresh - can't test at the moment.

[SergeyBiryukov]

Refreshed.

[GrahamArmfield]

Have tested 26601.2.patch now using NVDA.

Whilst it is good that the search box has been moved out of the heading, the number of themes present and the Add New link is still within the <h2>.

My view is that this is too much, and I understand that this is common across many admin screens. A consistent approach is needed here.

Does it need a new ticket or tickets to remove all non-heading elements from the headings?

[GaryJ]

Replying to GrahamArmfield:

Does it need a new ticket or tickets to remove all non-heading elements from the headings?

I'd say yes, and +1 for moving the Add New's outside of the h2 - never understood what it was doing there.

[johnbillion]

This needs a refresh since the theme install screen now uses the Backbone-powered UI too. See #27055.

[samuelsidler]

Moving this out from 3.9. We should do this the right way and fix it across the admin UI, including in the new Backbone-powered theme install screen. Is anyone interested in taking that on for 4.0?

[afercia]

Also to consider: many admin screens display the search results inside the h2, for example:

Once the "Add New" etc. buttons will be moved out from the headings, I would propose to just change the search string in something like this:

[SergeyBiryukov]

Replying to samuelsidler:

We should do this the right way and fix it across the admin UI, including in the new Backbone-powered theme install screen.

The idea in comment:2 was to move the search box out of the heading on Themes screen (since there are no search boxes in <h2> on other screens), and move the "Add New" links out of headings on all screens in a new ticket.

OK, I guess we can repurpose this ticket instead.

[trishasalas]

I've created a patch that moves all the elements outside the <h2> tag. At this point I've created <div>'s but was torn between that and <span> tags. Open to feedback. I don't mind tackling the other areas mentioned but want to get feedback here first for sure.

[trishasalas]

Trying this again, hopefully this patch is a little cleaner. I also made the "Add New" and actual <button>.

[afercia]

Not sure this should be changed in a <button>. Links that point to a real resource (that "take you somewhere") should still be links and use an <a> tag. Just the "non-link" links, meaning <a href="#"> and links with a URL fragment, e.g.:

<a href="#post_status" class="save-post-status hide-if-no-js button">OK</a>

when they don't point to a target within the current document and they "do something" in the page instead of taking you somewhere, they should be buttons instead.

Anyway we should take care of all screens in the admin, including the network admin, not just themes.php. Wondering what's the best approach: all-in-one patch or discrete tickets? Any thoughts?

[trishasalas]

I've modified the patch to remove the <button> element. I also included theme-install.php as well.

As far as separate tickets, I don't have a strong opinion either way. I don't mind going into each screen and making the needed changes. At first glance it looks like the themes screen was the only one that involved the javascript. The others were just a matter of moving the code outside the <h2> tag.

[SergeyBiryukov]

Minified files should not be patched, a post-commit task takes care of that.

There's a ​SCRIPT_DEBUG constant you can add to your wp-config.php file to use unminified files.

Replying to afercia:

Anyway we should take care of all screens in the admin, including the network admin, not just themes.php. Wondering what's the best approach: all-in-one patch or discrete tickets? Any thoughts?

A single patch would probably be easier to test and review for consistency.

[trishasalas]

This patch has 'lessons learned' applied (i.e. script debug). I've gone over every screen and I think I have them all accounted for.

[rianrietveld]

The WPa11y tes team found 2 missing:

• edit post/page (/wp-admin/post.php?post=xx&action=edit)
• add plugins (link upload Plugin)

The rest was ok.

Tested by: Tina Tedesco, Malgorzata Mlynarczyk, Jeff de Wit

[trishasalas]

Thanks so much to the WP a11y test team! Fixed edit-post.php and plugin-install.php.

[valendesigns]

Hey Guys, sorry for the rapid fire patch uploads! I saw room for improvement right after I uploaded it. Anyhow, the previous patch did not apply cleanly anymore. As well, it wasn't very backwards compatible with plugins and themes that create pages using the old method of an h2 without a header. Additionally I added better support for notices. I tested my patch in FF, Chrome, & Safari on OSX and IE 8-10 on Win8, iPad4, and iPhone5. Everything looks good from what I can tell. Please test patch 26601.10.diff​ and let me know how it works for you. Cheers!

[joedolson]

@valendesigns

Can you summarize what the purpose of your changes was? The refresh is clear and appreciated, but I'm not really sure what you mean by "better support for notices" or what the backwards compatibility issue was. It's really helpful for others if when you change a patch, you provide some specific inforamtion about why you made the changes you made.

E.g. "I observed that this patch wasn't compatible with plugins and themes using the old method of an H2 without a header, because xyz happens", so I changed the patch to do abc".

Thanks!

[rianrietveld]

Hi @valendesigns, thanks for the patch.
Could you please take a look at the H2 in upload.php for mode=list?
The link there is still in the H2.

Maybe we should also include the network screens like /network/site-new.php and /network/users.php
Or will that better be done in a separate ticket.

[valendesigns]

Replying to joedolson:

Can you summarize what the purpose of your changes was? The refresh is clear and appreciated, but I'm not really sure what you mean by "better support for notices" or what the backwards compatibility issue was.

No problem, sorry for not being more descriptive. The issue with notices I discovered was with #local-storage-notice interacting with the floating h2. Basically, the float is not cleared and so the notice gets mangled beneath the heading when it displays. The second issue regarding backwards compatibility is that any admin pages created that rely on the h2 to be displayed without a header loose some of their padding and margin and feel tight.

To solve these issues what I did was clear the float in certain situations and add styles that are qualified within a heading and by leaving the old CSS in place we don't loose styles for plugins and themes that aren't updated. Which I would assume will be almost all of them.

Replying to rianrietveld:

Could you please take a look at the H2 in upload.php for mode=list?
The link there is still in the H2.

I will create a new patch today to address this heading.

Maybe we should also include the network screens like /network/site-new.php and /network/users.php
Or will that better be done in a separate ticket.

I think it would be best to cover as many of the admin pages as possible in this ticket. I can refresh the patch to include more coverage and if you see any other pages that need the same treatment we should handle that in this ticket, within reason and in the timeframe we have.

Since we are getting closer to 4.2's release and old styles are still in place I don't think it's critical that we convert every single heading. They'll still display correctly in the interim, and opening separate tickets for the headings we miss seems reasonable to me. So anything that we can update this week should be, and beyond that would likely need a new ticket as we find them.

With that said, it's only my opinion and I don't have commit access so one of the core devs will still need to chime in and give us some feedback on how to handle these missed headings.

[trishasalas]

Hi @valendesigns,

Thanks for helping out! :)

I did patch 7 and have just refreshed for the newest core changes. I tried to stick to just changing the specific pages that had the issue that was reported so as to keep things as simple as possible (since it's such a large ticket). I was thinking more accessibility than visual so there are some slight changes in spacing with the buttons in relation to the <h2> tag itself. (usually very slight depending on the screen)

By way of information, I added the <header> tag simply because I needed a block level element and that seemed the most appropriate given the location (no need for extra classes.) I did go ahead and carry that out to all the pages I edited for the sake of consistency. If a div (or even some css float fixes) are more appropriate here I'm very open....there is usually more than one way to do something :)

All that said, I very well could have missed some backwards compatibility, etc. What other changes where you addressing with your patch? I would love to see this be as thorough as possible for screen reader users without negatively affecting others (plugin authors, etc)

Trisha

[trishasalas]

Please use 26601.7b.patch

26601.7a is borked for some reason.

[ocean90]

Thoughts after a quick review of 26601.7b.patch​:

• wp-admin/upload.php: The second section doesn't have a <header> wrapper
• Can we think of a better class name for helper-content?
• echo __( 'Comments' ) should be _e( 'Comments' )

[valendesigns]

@ocean90 Can you please test 26601.10.diff​, as well. It's a different take on the issue.

[trishasalas]

@ocean90, thanks for looking at this. I'm attaching 26601.7c with the requested changes. That said, we discussed punting this to 4.3 early in the A11y meeting today, I'm personally fine with that fwiw. I just read the logs and saw Drew mentioned that as well.

[afercia]

Just noticed one thing to take into consideration, using position: relative on the <header> or any other block element may "cover" the Screen Options and Help tabs, making very difficult to click them also when they're open, see screenshot:

.wrap > header {
  display: block;
  padding: 9px 0 4px 0;
  position: relative;
}

[DrewAPicture]

Patch needs a refresh for wp-admin/edit-form-advanced.php.

[DrewAPicture]

After talking it over with @helen, @ericlewis, and @jorbin, we've decided to punt this to 4.3-early. It's too much structure to adjust at this point in a cycle. Let's keep the momentum and get this in in 4.3-early.

[trishasalas]

Patch from #31650 applied.

Edited all the theme screens and a handful of others including media.php, and edit.php

I opted to use the <header> tag again as it was the cleanest way to implement the changes.

I'm not sure if I'll be at the meeting but I will try to get to Slack for some feedback on this. If we're ok as-is I should be able to finish the week.

[trishasalas]

Patch from #31650 applied.

Edited all the theme screens and a handful of others including media.php, and edit.php

I opted to use the <header> tag again as it was the cleanest way to implement the changes.

I'm not sure if I'll be at the meeting but I will try to get to Slack for some feedback on this. If we're ok as-is I should be able to finish the week.

I just looked at the patch, should't be doing this at 3:30 am. It's a mess, I'll fix in the am and try to show up to get some feedback for moving forward.

[trishasalas]

31650.patch applied. Edits to themes.php, theme-install.php, theme-editor.php and related js and css files

[wonderboymusic]

This needs a massive refresh, soon please to be considered for 4.3

[trishasalas]

If we're still looking at 4.3 for this I'll have a patch ready tomorrow. I've been watching #31650 and wasn't sure where we were at with things. I just read through today's notifications so I'll proceed.

[trishasalas]

Got this done pretty quickly thanks to the patch on #31650.

I went with <div class="header"></div> for the block level element. I only added the header div to the screens I edited (as opposed to adding to all for consistency). Open to suggestions but didn't want to add unnecessary markup.

[trishasalas]

Replying to afercia:

Just noticed one thing to take into consideration, using position: relative on the <header> or any other block element may "cover" the Screen Options and Help tabs, making very difficult to click them also when they're open, see screenshot:

.wrap > header {
  display: block;
  padding: 9px 0 4px 0;
  position: relative;
}

@afercia, thanks for that observation! I went with a div as opposed to the <header> but in it’s current unstyled state it overlaps the ‘Screen Options’ tab in the same way. Adding display ‘inline’ remedies the situation but I’d like a sanity check that I won't be breaking anything further down the road ;)

[afercia]

Replying to trishasalas:
@trishasalas I think it overlaps because of the position: relative property, is that really necessary?

[trishasalas]

Replying to afercia:

Replying to trishasalas:
@trishasalas I think it overlaps because of the position: relative property, is that really necessary?

In this case, <div class="header"> does not have position: relative set but it is covering screen options in the same way.
​https://www.dropbox.com/s/h6io19vm4m3gz82/Screenshot%202015-06-28%2017.28.50.png?dl=0

[afercia]

Need to check if you can actually click on the whole area of the Screen Options and Help buttons, I think the Chrome inspector will always draw the blue rectangle "over" other elements regardless of the actual stack level.

[trishasalas]

Replying to afercia:

Need to check if you can actually click on the whole area of the Screen Options and Help buttons, I think the Chrome inspector will always draw the blue rectangle "over" other elements regardless of the actual stack level.

Sounds good, in that case (and I double checked) this is ready to go.

[afercia]

Refreshed patch after 33067. Additionally:

• also the search results subtitle should be moved outside of the heading
• reviewed and added a few missing things (e.g. network screens)
• updated the JavaScript to move notices under the main heading

[obenland]

.header is probably not the best class name we can use here. .page-title maybe?

I also wonder if we should give this a little bit more time, rather than rushing it in before beta2.

[trishasalas]

Replying to obenland:

.header is probably not the best class name we can use here. .page-title maybe?

I also wonder if we should give this a little bit more time, rather than rushing it in before beta2.

I think it would be good to wait so we can do a more thorough job.

In regards to .header, I used that as opposed to the <header> tag itself because of some discussion surrounding the use of HTML5 tags in the admin area. That in itself is reason enough for me to postpone. I'd like to do some cross browser testing to see if there will be any issues with the <header> tag.

[trishasalas]

Patch coming up...consensus is: 'Add New Button' === burn it with fire

(​https://wordpress.slack.com/archives/accessibility/p1450724332001548, ​https://wordpress.slack.com/archives/accessibility/p1450724340001549 and ​https://wordpress.slack.com/archives/accessibility/p1450724379001550)

[afercia]

Discussed a bit this ticket at today's accessibility weekly meeting and decided to try to fix this issue in small chunks :) One of the reasons why this ticket is not moving on is probably because it's trying to fix all the things in one go. It would probably be more productive fixing one heading at a time and keep this ticket as tracking ticket.

[afercia]

Worth reminding notices that are moved below the heading with JavaScript need to be taken into account, currently they're inserted after the first h1 or h2, see below:

Thinking we need a new element to target and this would also make the CSS part easier. I'm considering to use a <hr> that can be styled also with visibility: hidden if avoiding visual changes is a priority. Keeping the <hr> visible doesn't look so bad though, personally I like the subtle separation given by the detault WP styling for <hr>s.

[afercia]

New patch with a new approach. It patches just the Posts and Edit Post screens heading for now. Some testing would be greatly appreciated.

• needs to add a CSS class on the heading: the heading style can't be changed globally otherwise it can break the heading in plugins/themes settings pages
• adds a <hr class="wp-header-end"> element to separate the heading+stuff from the notices and the main content below, this is needed to preserve the layout and makes also appending notices easier
• the Plugins and Themes screen may need a special treatment, for now it would be great to check if this new approach is good enough ��

[rianrietveld]

Tested 26601.11.diff
Works ok, also for small screens.
I like the headerEnd solution

The only thing, maybe totally not an issue, but for long custom post names the indention and line height of the Add new button is not very pretty.

[rianrietveld]

Very long custom post type name

[afercia]

@rianrietveld yep good catch! I think it can be easily fixed adjusting margins for the responsive view. For the record, this is how a very long CPT name looks like now:

[afercia]

Refreshed patch to adjust margins for the responsive view.

[joedolson]

I quite like the solution put forward in @afercia's last patch; I'd like to see this start to go in. Being able to do it one instance at a time will make it much more manageable, so that we could hopefully get it started in 4.7 and completed in 4.8.

[afercia]

Changing this in a task, should be handled with separate patches for each screen so it can get started in 4.7 and hopefully completed in 4.8.

[afercia]

In 38983:

Accessibility: Remove inappropriate content from the Posts and Edit screens headings.

Props grahamarmfield, SergeyBiryukov, trishasalas, valendesigns, rianrietveld, afercia.

See #26601.

[joedolson]

Patch for media uploads screen.

[joedolson]

Patch for themes screen

[joedolson]

Theme installer patch

[joedolson]

For 26601.themes.patch, it might be better to inject the container div via JS, rather than having an empty container in the HTML.

[afercia]

26601.upload.patch​ and 26601.theme-install.patch​ look good to me. I'd rather refactor a bit 26601.themes.patch​, not concerned about the container since a similar container is used also in other places, but it can be simplified a bit.

[afercia]

26601.themes.2.patch​ uses a <span> instead of a <div>, no need for CSS changes. Also the JS can be simplified a bit.

[afercia]

In 39526:

Accessibility: Remove inappropriate content from the Media Library screens headings.

Props joedolson.

See #26601.

[afercia]

In 39527:

Accessibility: Remove inappropriate content from the Add Themes screen heading.

Props joedolson.

See #26601.

[joedolson]

I don't believe you can insert a <form> inside a <span> and validate, which is why I chose a block-level element and CSS. It's invalid nesting.

[afercia]

There's no form, just label + input :) Refreshed the patch with a small CSS adjustment for the responsive view.

[afercia]

In 39528:

Accessibility: Remove inappropriate content from the Themes screen heading.

Props joedolson.

See #26601.

[joedolson]

Headings patch for widgets screen

[joedolson]

Headings patch for nav menus screen

[joedolson]

Headings patch for plugins screen

[afercia]

Patch for the Users screen.

[afercia]

In 39534:

Accessibility: Remove inappropriate content from the Users screen heading.

See #26601.

[afercia]

Patch for the Plugins screen.

[afercia]

In 39535:

Accessibility: Remove inappropriate content from the Plugins screen heading.

See #26601.

[afercia]

Patch for the Add Plugins screen.

[afercia]

In 39536:

Accessibility: Remove inappropriate content from the Add Plugins screen heading.

See #26601.

[afercia]

Patch for the old Link Manager, add-link-form.php and link-manager.php.

[afercia]

In 39537:

Accessibility: Remove inappropriate content from the Link Manager screens headings.

See #26601.

[afercia]

Patch for the Edit User screen.

[afercia]

In 39538:

Accessibility: Remove inappropriate content from the Edit User screen heading.

See #26601.

[afercia]

Patch for the Widgets screen.

[afercia]

In 39541:

Accessibility: Remove inappropriate content from the Widgets screen heading.

See #26601.

[afercia]

Patch for the old Edit Media screen (media.php).

[afercia]

In 39542:

Accessibility: Remove inappropriate content from the old Edit Media screen heading.

See #26601.

[afercia]

Patch for the Menus screen.

[afercia]

In 39543:

Accessibility: Remove inappropriate content from the Menus screen heading.

See #26601.

[afercia]

Patch for my-sites.php and the network admin pages.

[afercia]

In 39551:

Accessibility: Remove inappropriate content from the Network screens headings.

See #26601.

[afercia]

In 39552:

Accessibility: Remove inappropriate content from the Edit Comments screen heading.

See #26601.

[afercia]

Patch for the Edit Comments screen :)

[afercia]

Patch for Edit Categories and Edit Tags screens.

[afercia]

In 39553:

Accessibility: Remove inappropriate content from the Edit Categories and Edit Tags screens headings.

See #26601.

[afercia]

For reference: [38983] missed to take care of the editor DFW mode, see [39619].

[afercia]

All the work here is done, this ticket was still open to check for missed edge cases. Going to close it as fixed. Discussion, and reporting missed edge cases, can happen also on closed tickets :)

[jbpaul17]

Related dev note: ​https://make.wordpress.org/core/2017/05/17/cleaner-headings-in-the-admin-screens/

[desrosj]

This was detailed in the following dev note: ​https://make.wordpress.org/core/2017/05/17/cleaner-headings-in-the-admin-screens/