The current use of local tasks is confusing to some users

I tested it on my local and it works fine, it’s definitely an improvement 👍🏻

Just paired with @lauriii and we found that our current change in \Drupal\Core\Render\MainContent\HtmlRenderer::prepare() is incorrect as it also affects the browser tab title which we don't want. I'll revert that change.

Currently the title shown on page 'admin/structure/block-content/manage/basic' is 'Edit Basic block block type' because we override the title in '\Drupal\block_content\BlockContentTypeForm::form' but now in this current MR we again override it in 'PageTitleBlock' based on base route and now it shows the title as 'Edit Basic block'. So I think we need to decide what we want (which can be done in a follow-up). I think it should be 'Basic block' and not 'Edit Basic block block type' because the 'Edit' word is already shown on the tab and 'Block Types' is shown on the breadcrumbs. See the which shows edit basic block page based on the current MR.

The tests are failing because now we use the correct service '@router'(AccessAwareRouter) in 'RequestGenerator' but what this does is it checks the access for the route but PageTitleBlock uses '@router' for the matching of request for base route so it will check it's access and and it'll fail as the tests obviously don't grant the permissions for base route.

There's some excellent feedback on #2514218-120: [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity → from @rkoller. Looks like This has been also discussed several times on the Friday UX calls: #2514218-101: [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity → (which I had missed). I think the proposal for Pattern A is really interesting and it looks like something we should try to implement here. I think it aligns well with what is already being done here, but does increase the scope slightly. The reason we should implement the solution from there, is that it improves the accessibility of the current solution (the current solution has not been reviewed for accessibility yet).

The proposed pattern there is:

Page title:
[Action aka Primary Tab Name] for [Name] [Entity Type] | [Site Name]
Manage fields for Article content type | My Drupal 9 site

h1 for sighted users:
[Name - wrapped in em tag] [Entity Type]
Article content type

h1 for screenreader users:
[Action aka Primary Tab Name] for [Name - wrapped in em tag] [Entity Type]
Manage fields for Article content type

What could we implement here?

I'm wondering if we could change the page title to follow a simpler pattern? A separator character would provide a clearer separation between the two titles, which could help in particular with sighted users who would only see a shorter page title.

Another concern I have, is that "for" is not something that translates well in all languages, and if we use the same translation string for the screenreader and the page title, it may lead into substandard screenreader experience due to translations that are optimized for page title. For this reason, I'd propose following pattern for the page title:

Page title:
[Current page title] | [Section page title] | [Site Name]
Manage fields | Article content type | My Drupal 9 site

The screenreader and sighted users map pretty close to what we have here; we could just prepend the current page title to the section page title. Unfortunately, this won't include the current bundle name automatically in the page title. However, I believe this architecture is able to accommodate this requirement. Once we have set up the infrastructure here, in a follow-up issue we could update the page titles to append the bundle name to the section page title.

This would result in the following titles as part of this issue:

h1 for sighted users:
[Section page title]
Article

h1 for screenreader users:
[Current page title] for [Section page title]
Manage fields for Article

How should we implement this?

One idea for how we could implement this is to convert the current logic from \Drupal\Core\Block\Plugin\Block\PageTitleBlock::getTitleBasedOnBaseRoute into a new instance of \Drupal\Core\Controller\TitleResolverInterface which we could call from multiple places. This way we could retrieve the section title both in \Drupal\Core\Block\Plugin\Block\PageTitleBlock, as well as template_preprocess_html for the <title> element.

I discussed with @bnjmnm about the accessibility implications of this change. He recommended that we change the h1 for screenreader users pattern to:

[Section page title]: [Current page title]

This works more consistently across the board, e.g. something like "Uninstall for Extend" isn't nice, but "Extend: Uninstall" works fairly well. This also makes the title map more closely with the UI, because we give more weight for the section title than the current title.

He also mentioned that the pattern for the document title looks fine on principle, but that he'd like to give it some more thought. 👍

I accidentally bumped into #996302: Pages of local actions don't display local action title as page title → as I was doing research related to an another issue. Turns out, Drupal 7 had the behavior that we were proposing originally in this issue. 🤯 I had to research the history behind that to double check how that decision was justified, just to understand if we have been missing something as we have been working on this.

Looks like the behavior changed as part of the massive menu system refactoring during the Drupal 8 development; essentially #2068471: Normalize Controller/View-listener behavior with a Page object → introduced the new way of rendering pages which generated titles independent from the menu system. All uses of the old way was removed in #2194823: Ensure that all content/page routes have an _title → which essentially finally changed the behavior to what we currently have.

I also discovered to a feature request that requested to enhance the document titles with the current local task in ✨ Output title of current local task in HEAD title (e.g., "People » List") Closed: outdated , which is essentially what we are doing here. 🤩

I don't know how much usability consideration was given to this change. I didn't find any mentions of usability in these issues. At least it looks safe to say that it doesn't look like any of these changes were drive by the user experience.

I don't know how much usability consideration was given to this change. I didn't find any mentions of usability in these issues.

When the original router patch was committed, there wasn't even thought given to the relationship between a router item, its access, and a menu link (see #1793520-7: Add access control mechanism for new router system → downwards), and it took several people years, blocking Drupal 8's release, to repair some (but not all) of the damage done to the menu system. #2407505: [meta] Finalize the menu links (and other user-entered paths) system → and sub-issues has some of the pain, and you can see that wasn't even opened until two years after the original router commit landed. So short version: none, but also worse than none.

re #16 🐛 Page title should contextualize the local navigation Needs work

First about the points under "What could we implement here?":

In regards of the separator I don't have a strong opinion. I've just tested the latest state of the MR with VoiceOver on the Mac. The only downside with separators is see for screenreader users is that Manage fields | Article | Drupal turns into Manage fields vertical line article vertical line drupal even if the default speech verbosity is set to low. vertical line is a bit verbose and wordy. maybe pick another separator? if a separator is used for the h1 between Manage fields | Article it would make things consistent with the title as well. the separator would be visually hidden to sighted users anyway and for screenreader users it might be confusing otherwise if the title uses a separator while the h1 uses the word for instead?

The problem of translations you've brought up in the context of the word for is a relevant point - good catch. It would be interesting to make a brief ad-hoc survey in one of the translation related channels on the Drupal Slack and ask translators how easy or difficult a snippet like Manage fields for Article content type would be to translate?
As I've said I have no strong opinions in that regard neither for the use of a separator nor the use of the word for instead. but if i remember correctly, back when we've discussed the topic, either @benjifisher or @aaronmchale voted strongly for the usage of the word for instead of : (the separator we've planned to use back then). So i think it would be a good thing to bring them into the discussion. or better put this issue on one of the next ux meetings and restart the discussion around the topic (only next friday won't work because benji is away).

In regards of making the title and the h1 more concise and clear I think getting some momentum back into 📌 The 'Edit', 'Manage display' and 'Manage form display' tabs were hard to understand Needs work would be a good thing. We've discussed it during the UX meetings back then as well. The following Slack comment summarizes the outcomes. We were in line with the idea voted for in the issue to ideally make the tab labels one worded. It was mostly about removing the verbs Manage. The suggestions from the issue and our discussions back then were:

edit fields form view
edit fields form display
defaults fields form display
settings fields form display
edit fields form modes view modes

One suggestion for the decision process forward. It would be a good thing to discuss that aforementioned list and come up with a list of 4 to 5 different options for each tab everyone involved in the discussion would be comfortable with. then run a one-two punch survey for each tab label. the first question is a quantitive one about "the what" (a radio button list where the user is able to select the preferred term for example the options would be "view, display, view modes, other"). and an open ended question to get qualitative feedback. something like "tell us why you chose this answer. In case you chose "other" why would you use this word instead? Walk us through your thinking." That way the choice would be grounded in actual feedback and you could quickly get a feeling how comprehensible the choice of a one worded tab label would be. Because the folks involved in the issue already have an inherent bias.

re #18 🐛 Page title should contextualize the local navigation Needs work

I've tested the suggestion of @bnjmnm to use : instead of |. The colon is the only separator which is not announced by any screenreader. Someone created a comparison in the context of gender inclusive language in mainly german (but the introduction and conclusion are in english and the comparison table is quickly translatable. but it is a good resource: https://taner-aydin.dev/a11y-up/genderinklusive-sprache-und-barrierefrei... ). So as I already said in my previous comment personally i would be fine with the suggestion of using the colon but i would include benji and aaron as well.

about the current state of the MR - a few comments and suggestions.

[Section page title]: [Current page title] was suggested for the h1 in #18. I would strongly vote against that and use it the other way around: [Current page title] : [Section page title] . we've intentionally front-loaded the order to ease the scan and processabilitiy. the current page title is the most important piece of information then comes the section page title. and when the follow up issue gets in then the bundle name. (that bundle name follow up is essential otherwise it is impossible to determine which bundle type is in front of you. just based on the title and or h1 it is impossible right now)

when the h1 is using the colon as the seperator now how about [Current page title] : [Section page title] | [site title] for the title. that way you wouldnt have three separate pieces of information divided by the announcement of vertical line. instead you have manage fields article vertical line my drupal 9 site. that way things would be way more clear to screenreader users.

for other sections of the admin interface i have to take a closer look and think about it. back then we were entirely focused on the scope for 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed . we already saw the need for other parts in the admin ui but havent had an in depth discussion yet.

To get a feeling and an overview aside the bundle types from the postponed regression issue I quickly went through the admin pages and created a spreadsheet with all the titles, h1s, primary task labels, and secondary task labels based on the MR in this issue. i always prefer to have all the content in a spreadsheet next to each other. that way it is easier to assess the readability and consistency https://docs.google.com/spreadsheets/d/1XhQtXZA1JCwa8qnE3vp8gyW8HJT8zZxg...

@rkoller the spreadsheet doesn't have permissions be viewed :)


the current page title is the most important piece of information then comes the section page title

Agreed. The point is that the existing value for page title is not correct: it was wrongly switched to the value of the tab as comment #18 and #19 pointed out. Here’s an screenshot of Drupal 7: you’re in the Article content type itself and we use tabs to navigate across the options available for it.

We load each tab in different pages because it was built like this, but tabs are a standard pattern where you separate content in different groups that are part of the same “piece”. Call it Merge Request, Settings or Content type, but you can see patterns of this everywhere. So this is what users expect (you can see it was perceived as an improvement in our recent tests in 🌱 Toolbar Prototype Usability Testing Phase I Fixed ) and there is no need to repeat the value of the tab in the title: the rest of the UI elements give enough clues to understand the hierarchy.
 And another thing to add here, is that a solution like “Manage fields for Article content type” is worst for h1 than “Article”. It’s more verbose, but it results in worst scannability to quickly understand where you are in a first glance. For sighted users, a short and concise title is better if it’s combined with visual clues that help orientate/locate yourself. We’ve got already a complex UI and we should push to make it more clear, not more crowded if there is not a real need. I understand you also want to add the bundle, but that should be solved with UI elements (which we’re taking into account in 📌 [META] Layout redesign Active ) and not more text in the title. I can show a lot of examples, but we better discuss it in the follow-up and focus on the topic at hand here.

[Section page title]: [Current page title] was suggested for the h1 in #18. I would strongly vote against that and use it the other way around: [Current page title] : [Section page title]

Here we go back to the same: what we call currently the page title is not conceptually correct for Manage display for example. What we’re calling here “section title” (Article) is what should be the page title (and what it was already). So agreed that the page title should be first element because it’s the most important piece of info, it’s just that the value we’re getting here is not correct. Here it should be Article: Manage fields.

About the for vs :, as @lauriii said for doesn't tranalate well to other languages (AFAIK Finish is already an example) so is a strong enough reason already without the need to prove it with a survey. On top of that, patterns like "Update for Extend", "Extend: Update", "Update: Extend" make more sense with a colon even in English. It’s “agnostic” of the conceptual relationship between elements. So +1 to the “:” with the current info, subject to any new recommendation by @bnjmnm.

Also, totally agree with getting to 📌 The 'Edit', 'Manage display' and 'Manage form display' tabs were hard to understand Needs work again. Let’s discuss the changes for that in there and focus on the discussion here for the changes in the title :)

Thanks for creating the spreadsheet @rkoller! It makes reviewing the titles at scale much easier. IMO what's there currently makes sense for vast majority of the pages. There are few pages where we may want to adjust the titles, like the /admin/structure/block-content/manage/basic section, /admin/structure/media/manage/audio section, and /admin/config/people/accounts section. None of those seem glaringly broken so leaving the adjustments to a follow-up would seem acceptable to me.

I read the NN article on local navigation again to see if I could find examples that are relevant to the discussion around the screenreader <h1>. The one pattern where this is being used consistently is car brochures. In that use case the pattern seems to be to start with the currently viewed mode in the beginning of the title, e.g. "Mazda 6 Image Gallery". They probably made additional considerations on top of accessibility, but it does make sense that it's not just an image gallery, but it's an image gallery for that specific model.

Agreed that 📌 The 'Edit', 'Manage display' and 'Manage form display' tabs were hard to understand Needs work is one of the key issues we should focus next from Field UI UX perspective. It has been already been tagged as Field UX meaning that at least I'm actively tracking it.

This was discussed in the UX meeting last Friday (25th of August). During the call, there was clear consensus that:

1. The visual H1 should be consistent across all primary and secondary tabs.
2. The visually hidden H1 and the page title, should always contain the information from the active primary and secondary tab.

This issue is for the first item, but we'll need a follow-up for the second item. Second item likely involves updating titles for individual pages because on many pages where there is second level local tasks, the actual page title matches with the first level local task.

There was also a recommendation that we further research the screenreader specific page titles. I reached out to few contacts that I have to see if I could find someone who could help. 🤞

I did try to see if there is any prior research on this. I found few articles that seemed to touch this topic. There's a Nielsen Norman article on headlines which recommends front-loading the page titles with the context.

Birds Heal Post Traumatic Stress Disorder (PTSD)
Or
Post Traumatic Stress Disorder (PTSD) Healed by Birds

The second one is better because it sets the context first (the article is about PTSD, not about birds) and supports scannability

It's the same pattern that is recommended for links, where you first explain which site you are linking to, and only then what is the heading of that article. It's also the same experience with person viewing the page visually; the section title is displayed first, and has more visual weight.

All of the articles linked on this issue make it clear how prudent context is for good user experience, and highlight how bad the current experience is. I hope that we can come to some conclusion on which approach to go with, at least until we know better, because it seems clear (at least to me) that this is a net win, regardless of whether we have the context before or after the current page title.

> This works more consistently across the board, e.g. something like "Uninstall for Extend" isn't nice, but "Extend: Uninstall" works fairly well. This

True, but having 'Edit display for Article' would be *really nice*.

At the risk of derailing and adding complexity, what if there were a way to vary how the local page title & the tab parent title are combined?

Off the top of my head, could we pass the tab parent title in to the page title callback as a parameter, and let the callback decide how to combine them?

This could be done in a follow-up -- the perfect is the enemy of the good :)

Agreed! I understand wanting to nail the page title, but I'd recommend arriving to a minimum agreement with something not bad and refine it later in a follow-up, and land the h1 changes soon because it's a big UX improvement for sighted users.

I'd personally go with the pattern that results in the following structures because it avoids assuming an specific combination of order and connectors (from English):

• Article: Manage fields
• People: Roles
• Uninstall: Extend
• Synchronize: Import

(Again, thanks @rkoller for the spreadsheet, it's super useful)

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I slightly changed how the title is decided, which allows overriding titles for individual pages by using a #title render array item within a controller (similar to what we currently have). This is needed for some routes like entity delete, where the page title is overridden to "Are you sure you want to delete ...". We may need additional APIs to fully address #29 but as mentioned in that comment, this could be done in a follow-up.

Coincidentally, I was testing out Airtable and noticed that they are implementing the [Section title]: [Current title] format in their page titles. The demo they ship with is a product catalog. In that example, the page titles are Product Catalog: Furnitures, Product Catalog: Vendors, and so on. I'm starting to think that we should move forward with the current proposal and revisit the formatting, and the potential additional APIs to alter that behavior in a follow-up.

Postponed https://www.drupal.org/project/drupal/issues/2938129 🐛 PageTitle block is non-functional when not handled directly by \Drupal\block\Plugin\DisplayVariant\BlockPageVariant Postponed on this one.

Work can continue in the MR, but for the short term here is a snapshot of the changes backported to 10.1.x

Will work on remaining things like change record, release note, clean-up etc.

lauriii → closed merge request !4283

Created change record https://www.drupal.org/node/3386683 →

Created follow-ups 📌 Change the separator in document title Active and 📌 Refine the page title if possible Active .

Added release note

Looks like all feedback has been addressed and works as expected. MR looked good to me. Followups have also been created to revisit the formatting if need be but this is already a big UX improvement.

Woo this is huge improvement! Congrats everyone!

Testing this as Drupalcon today. I'm trying to understand the reasoning behind this change, and talked with lauriii about this. We added one more sentence to the change record to help existing sites/themes to make a decision.
I clicked through some example pages:

- /admin
- /admin/content (On this one 'Content' appears multiple times, but that seems correct, given that admin/content/overview is the default tab.
- /admin/modules
- ...

When the original router patch was committed, there wasn't even thought given to the relationship between a router item, its access, and a menu link (see #1793520-7: Add access control mechanism for new router system downwards), and it took several people years, blocking Drupal 8's release, to repair some (but not all) of the damage done to the menu system. #2407505: [meta] Finalize the menu links (and other user-entered paths) system and sub-issues has some of the pain, and you can see that wasn't even opened until two years after the original router commit landed. So short version: none, but also worse than none.

It is an interesting aspect that this moves the responsibility from the developer towards the site builder/theme, the layer that actually knows what sensible. From my experience this makes the most sense.
While reading the code I had two minor nitpicks

Added minor feedback in the MR

FYI gitlab and drupalCi seem happy but when I did a diff of the MR to apply locally I got

 trailing whitespace.
�`4n6�U�[�g[3�(Ng��^z��D�XYN�b�N��*QiN�Lyt��h�RQ        A=�     ]߸W�8z�0f����H\��P[LH�P`q���`��j�>oW��3
warning: 1 line adds whitespace errors.

Probably nothing but wanted to note.

Applied the MR and cleared cache several times but when I go to a manage display for any entity type it still just says "Manage Display" nothing changed from before.

If that's no longer the goal or it's something different could the issue summary be updated please

Thanks!!

@smustgrave Thanks for the review! Did you run update hooks after applying the patch? The title change requires a config change which we're doing automatically for Claro in an update hook.

The error is probably caused by the changes to binary files. 🤔

I posted one comment on the MR so moving back to NW for that.

Didn't realize it needed an update.

That did solve the issue but am noticing some differences based on entity type
If I go to manage display for the Basic block I get title "Edit Basic block"
If I go to manage display for the Article content type I get title "Article"

@smustgrave Those are caused by title overrides. We'll probably want to remove most of them, but we need to take a holistic look at it. I opened a follow-up to do this: 📌 Review page titles for consistency Active since it could end up being quite a lot for single issue.

Thanks for pointing out that follow up @lauriii.

Believe @kunal.sachdev has addressed the feedback.

yash.rode → made their first commit to this issue’s fork.

As this is targeting 10.3 and won't be backported to 10.2, here's a patch for 10.2

Hiding patches because there's an MR

Updating issue credits

Left a review, this is looking really good and is a great improvement - still a fair bit to do though - thanks!

I tested this manually on secondary local tasks, e.g. on 'teaser' under 'manage display'

For all the secondary tasks it will show something like this:

<h1 class="page-title">Article<span class="visually-hidden">: Manage display</span></h1>

I was expecting it might show the context of the view mode (e.g. Teaser)

But I checked what happens in HEAD and it shows Manage display so there's a definite improvement.

@lauriii mentioned he was working to improve things further and that would definitely be a nice thing to do in a future issue (follow up).

Postponed on 🐛 Display the page title, even if "0" in olivero Active and 🐛 Change usage of plugin IDs for base route in SearchLocalTask::getDerivativeDefinitions() Active to keep the scope of this issue small.

All tests are passing now and I think there is no need to postpone this issue anymore.

Left some small comments.

All the feedback was addressed @larowlan if you want to do a second pass until then RTBC'ed

Needs a rebase.

I discussed with @alexpott about the failing test. The performance test is failing because this is introducing an additional cache query. We discussed about potentially adding static caching but agreed that the additional cache query was fine. So basically what we could do, is bump up the query counts by one.