[regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity

I think this is also a WCAG 1.1.1 issue.

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

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

@mgifford

> We could have a range of colors that could be modified in a YAML file, also some simple SVG files could be added for images.

Are you saying we need to rescope this issue to consider that at the same time as the text, or can it be a follow-up?

tim.plunkett → made their first commit to this issue’s fork.

Discussed this issue earlier with @ckrina. The proposed solution makes the page title pretty long and hard to parse. We started thinking that there might be another solution to this; we think that we should try to approach solving this without adding all of the information to the title.

We believe that the root cause to the problem is that the current page hierarchy isn't entirely correct. The primary tasks are listed under the current page title which means that it's not clear what the tabs are related to. The page title in many cases is more related to the secondary tasks. The current "workspace", or "context" is only described by the breadcrumb.

Github has a similar page structure. Their page structure makes it clear where the user is navigating in, and what each of the tabs are related to.

Here's a mock that sets some direction to what we should explore. I don't think we should implement this as such because this isn't entirely right.

Based on this, it would probably make sense to postpone this issue on 📌 [META] Layout redesign Active .

Re-tagging this after talking with @rkoller

Experimenting with ML summaries.

Nixing confusing AI summary. Adding back in 1.1.1 SC.

re #115 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed . Apologies for the late and overdue reply. I was more or less out of the loop for the last few weeks, and trying to catch up slowly.

Discussed this issue earlier with @ckrina. The proposed solution makes the page title pretty long and hard to parse. We started thinking that there might be another solution to this; we think that we should try to approach solving this without adding all of the information to the title.

To which of the proposed solutions are you referring to? The one in the issue summary or the one in #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed . I agree that the proposed resolution in the issue summary is too long and too hard to scan. That is what we've tried to improve with the proposed changes in #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed , in particular with Pattern A, which visually hides the task aka the active tab's label for sighted users.
Both suggested patterns are meeting the WCAG 2.1 success criterion 2.4.2 (G88 https://www.w3.org/WAI/WCAG21/Techniques/general/G88.html) for sighted as well as screenreader users.
The most important information is front-loaded. First the task, visually hidden for sighted users, then the bundle name and then the bundle type. That way one is able to either stop scanning immediately and jump off or go on in case the person is visiting the content type for the first time or in case of uncertainty and or a small working memory. All necessary information is prominently available in the h1 and there is no need to search any further within the page.

We believe that the root cause to the problem is that the current page hierarchy isn't entirely correct. The primary tasks are listed under the current page title which means that it's not clear what the tabs are related to. The page title in many cases is more related to the secondary tasks. The current "workspace", or "context" is only described by the breadcrumb.

I agree that the current state (see regions_annotated.png) of having the primary tasks as the page title is super confusing. With the suggested Pattern A we went by the Ambiguous Tasks Title approach of Torrey Podmajersky from the Strategic Writing for UX book. Using a noun or a noun phrase that names the person's context that covers the entire set of ambiguous tasks (the primary tasks).
Having that entire context available in the h1 is mandatory due to the inherent nature of horizontal tabs in Drupal in contrast to vertical tabs. Each primary and secondary horizontal tab is a dedicated page with it's own route. For example

Manage display active as primary tab and Default active as secondary tab
/admin/structure/types/manage/article/display

Manage display active as primary tab and RSS active as secondary tab
/admin/structure/types/manage/article/display/rss

With the suggested Pattern A in combination with the proposed heading for the secondary tasks in the proposal_mock.png the page hierarchy looks clear and correct to me.

And I have to note while writing this comment that we completely forgot about those secondary tasks on the Manage display page in the two suggested patterns in #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed . Those suggested patterns would have to be updated and adjusted.

Github has a similar page structure. Their page structure makes it clear where the user is navigating in, and what each of the tabs are related to.

I agree it is sort of clear but cognitively I still consider Github challenging to visually orient in regards of the overall account (context) and repo (workspace). It is basically a breadcrumb and the list of available tasks as primary tabs.
The page is missing a clear visual anchor/heading what the page is about. You have the breadcrumb with the context and workspace which is placed on top but still not prominently. The most important piece of information is the workspace and for that you have to scan past the context in the breadcrumb. Plus the font size is rather small and subsidiary. And if you take a look into the head and at the title element in Devtools you get the following:

Code tab active
ckeditor/ckeditor5: Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.

Issues tab active
Issues · ckeditor/ckeditor5

Pull requests tab active
Pull requests · ckeditor/ckeditor5

The titles used on Github are more or less in line with #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed except for if the code tab is active which adds a wordy description instead of the active tab label like for the other titles. Plus in each case the title hasn't front-loaded the workspace before the context.

Cognitively I consider the prominent header in Drupal way more easy to scan and grasp. And as mentioned in #103 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed that header might be improved further by providing visual cues aside the improvements to the UX copy for the h1 discussed in this issue. So the user isn't necessarily required to read the entire h1 knowing in which bundle type one currently is in. I still have to write everything up and create that issue. Which would be the appropriate component to file it against? Should that go into Claro, the Node module or the Field_UI module?

Here's a mock that sets some direction to what we should explore. I don't think we should implement this as such because this isn't entirely right.

In regards of the Manage display page I like the idea of adding a heading/label for the View mode-tabs. That provides some sort context, clarity, and title to the secondary action tabs. Because without the permission Add, edit, and delete custom display modes. no regular user except admins would ever be in touch with the term View mode. Something I've realized when testing and commenting on the Same Page Preview module a few weeks ago. Regular users never really run into that term and concept within the admin ui.

In regards of the suggestion of using the bundle name for the h1 like in Drupal 7 (also suggested in #93 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed ) I would strongly disagree. Yes the h1 in the proposal_mock.png is shorter, but just using the bundle name has several downsides.

Sighted users can easily scan the bundle name. But you never know if another bundle type has a similar or identical name. Visually after scanning the h1 you have to switch one line up to the breadcrumb, but the bundle type isn't the first item on the right, you have to visually scan RTL (in contrast to LTR on the h1) to get to the bundle type. And then you have to visually jump to the primary tasks underneath the h1 and spot the active tab there. The overall context has to be chopped together from three different places which is visually challenging. For screenreader users the same task is even more cumbersome. In both cases WCAG 2.1 success criterion 2.4.2 isn't met, same as for the current state.

To reiterate and illustrate the thinking that went into Pattern A in #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed (see shortForm.jpg).

Screenreader users have all the necessary information available in the h1/title to grasp what the page at hand is about. First front-loaded the task aka the active tab label, visually hidden to sighted users, then the bundle name and finally the bundle type.

Ideally the h1's shouldn't differ for sighted and screenreader users Corbb O'Connor from the National Federation of the Blind recommended in one of the a11y office hours. Pattern B in #101 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed follows that advice. The downside with this approach is that the front-loaded task is redundant with the active primary tab, plus the h1 becomes too lengthy and hard to scan for sighted users. I've summarized that from my personal perspective as someone dealing with eye and vision problems in #102 🐛 [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity Postponed .

That is the reason why Pattern A visually hides the task from sighted users in the h1 and they are able to directly scan the front-loaded bundle name. In case they need to know the bundle type they can keep on scanning the current line instead of changing the line to the breadcrumb and scan there in a different direction.
The active primary task could then be easily spotted. Experienced users not even have to read but know based on the consistent tab position if the active tab is Edit, Manage fields, Manage form display, Manage display, or the Manage permissions tab.

In combination with the prominent and clearly structured header it would make the Drupal admin pages way more easy to process cognitively. It is also something I've noticed when comparing different versions of Drupal (OOTB and with all Core modules installed) with other CMSes (OOTB) for the reordering of the Drupal admin menu issue.

https://docs.google.com/spreadsheets/d/1o8JV3Qck92mV3CtoGdiRdqeRiW2L3Jk6...

I've slightly extended the effort and used the h1 or the apparent title in case no h1 was used on the particular page as the cell label. For sighted users many CMS systems were already difficult to navigate, for screenreader users even harder. And going through spreadsheets with just the h1 titles illustrates the necessity of having clear titles well in my opinion.

The only downside for sighted users with Pattern A is in case many pages are open in a browser window in horizontal tabs. The user is only able to see more or less the primary task label for each browser tab, the rest of each title is concatenated.

Overall Pattern A is still so far the most clear and scannable approach for sighted as well as screenreader users imho.

And there was a discussion with @aaronmchale about other related issues on the Drupal Slack. The direct link where the list starts within the thread is: https://drupal.slack.com/archives/C1AFW2ZPD/p1644603714706739?thread_ts=.... A meta issue might be created for those in case there is a wider agreement with the listed points.

Thank you @rkoller, I really like the proposal for Pattern A! My earlier concerns were aimed at the proposal in the issue summary, and I have to admit that somehow I had missed the proposal in #101. We have been working on a very similar proposal in 🐛 Page title should contextualize the local navigation Needs work and it has received positive feedback in user testing. I cross referenced your comments and tried to align the solution proposed here, which I believe is able to handle screen reader users in a more graceful way.

I'm going to mark this issue as postponed on 🐛 Page title should contextualize the local navigation Needs work because it will likely address 90% of the scope of this issue. Looking forward to your feedback on the solution there. 😊