🇺🇸United States @charles belov

Tested the patch on simplytest.me, and I'm not seeing the local tasks menu.

Steps:
1. Go to https://simplytest.me/
2. In the project name Field type admin
3. Choose admin_toolbar from the auto suggest
4. In the version drop down, choose 3.x–Dev (I also tried 3.6.1, with the same result.)
5. Click advanced options
6. Leave Drupal core at 11.2.1
7. In the patch field, paste https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/127.patch
8. Click Launch Sandbox
9. Copy log before it redirects to the site
10. Locate 127.patch in the log

Expected and actual results:

6876a2366cd631d7cc96a161# /bin/sh -c cd stm && composer patch-add drupal/admin_toolbar "STM patch 127.patch" "https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/127.patch" --no-update
Gathering patches from patch file.
The patch was successfully added.

11. Log into the site as admin

Expected result: I am on the admin user page /user/1. I see the following menus, not necessarily in this sequence:

• Manage
• This User
• Shortcuts
• admin
• Announcements

Actual result: I am on the admin user page /user/1. I see the following menus:

• Manage
• Shortcuts
• admin
• Announcements
• Edit

12. Go to /admin/config/user-interface/admin-toolbar

Expected and actual result: I see the default options for the admin toolbar module, indicating to me that the admin toolbar module is active.

13. Create a new basic page (Content, Add content, Basic page, type "test" in title field, Save)

Expected result: /node/1 has the following menu items:

• Manage
• This Content
• Shortcuts
• admin
• Announcements

Actual result: /node/1 has the following menu items:

• Manage
• Shortcuts
• admin
• Announcements
• Edit

Updating issue to follow current template.

I actually did update the summary. Is there anything else you need?

Updated to Drupal 11.2.x. Still relevant.

I have tested the patch in Firefox and I believe the focus indicator gives good contrast.

In that second image, is there a reason one of the inactive tabs has a white background? (Image resize)

charles belov → created an issue.

Thank you for that update. Here are my findings, tested in Firefox with factory settings:

1. The focus indicators for the most part are much better.
2. For some strange reason, only part of the focus indicator is showing up on some items. The worst of this is for Content, which only has a focus indicator on one side, making it ambiguous as to whether it applies to Content or to Structure. For the others, it shows up on three sides, which, while aesthetically unpleasant, is at least unambiguous.

Please see the screen recording that I took for the current state of patch 149 → . (Note: Sorry about needing to download the video. drupal.org doesn't let me embed it, and it is longer than 5 seconds so I can't convert to an animated GIF without violating WCAG 2.1 for Pause, Stop, Hide.)

charles belov → created an issue.

@quietone Thank you! I had only looked in the module, not in the library.

@smustgrave I'm not sure what additional information you need. The code is still in 11.x and is therefore potentially an issue. Of course, the patch is out of date.

I just did a test on simplytest.me, which is apparently not a Windows machine.

• File name on my Mac: file name with special chars /*?"<>|.txt
• File name once uploaded to simplytest.me: file%20name%20with%20special%20chars%20%3A*%3F%2522%3C%3E%7C.txt
• File name as shown in the Windows Edge address bar: file%20name%20with%20special%20chars%20%3A*%3F%2522<>%7C.txt
• File name as downloaded to Windows 11: file name with special chars ___%22___.txt

So, it's not an issue that files originally stored on a non-Windows machine can't be accessed by a Windows machine.

My concern would be if the site were moved from a non-Windows host to a Windows host that the files would no longer be accessible. However, I have not tested this and, as QA not developer, don't have a way to test this hypothesis.

Added Windows 11 wording for setting.

There doesn't appear to be any corresponding code in the file module for Drupal 11. Closing as obsolete.

Also noting that the Drupal 10 version doesn't show a use count, so I won't restate this as a Drupal 10 Redirect issue.

I think the tabbing is greatly improved and works predictably. I do notice one issue:

If I am on /admin/structure and I tab to Structure, not the caret to the right of Structure, the focus indication disappears and I'm left to wonder where the focus is.

I notice Structure is a link on /admin/structure, so technically it needs to be capable of being tabbed to. I'm not a fan of pages linking to themselves, but I'm guessing that is outside the scope of the current issue.

But if it's a link, and can be tabbed to, it needs to show the focus.

Similarly, if I am on /admin/structure/display-modes/form and tab to Structure, Display Modes or Form Modes, the focus appears to disappear.

Actually, as it turns out, the underline toggles on focus/loss of focus. This is inconsistent with how focus is indicated in the rest of the Admin Toolbar and it took me several tries to notice that. It isn't user-friendly, at least to this user, and adds to cognitive load, taking my focus away from my task.

Please do not over-engineer focus indication.

Indeed, thank you. Closing as duplicate of #3057679.

Yes, I do think that a best practice would be not to override the browser's focus indicator ever, as it increases cognitive load for the website visitor. The next best practice would be to be consistent, not to have every contrib module come up with its own focus indicator. I recognize that the admin site is distinguished from the visitor site.

@mgifford, would you want to weigh in on this?

Please note my comment on Focus indication clashes with active tab indication 🐛 Focus indication clashes with active tab indication Active . There is code in patch 138 which conflicts with the patch 149 for that issue.

Thank you for the clarification. I might have to file an issue against core then.

Anyway, yes, it passes. I must say a 4.5:1 contrast of background to text, while compliant, is a bit hard for me to read. If you could also darken the text on focus to #000000, that might help. That said, it's compliant. Unfortunately, there's no way to lighten the green background without breaking 3:1 contrast with the white.

There does seem to be a conflict with patch 138. For the following steps:

Steps:
1. Go to https://simplytest.me
2. Enter admin_toolbar for the project
3. Select 3.x-dev
4. Open the advanced options
5. Keep Drupal core 11.2-dev as the core version
6. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/149.patch
7. Click add additional patch
8. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/138.patch

Expected result: I get both the improvements in tabbing sequence provided by patch 138 and the contrast improvements provided by patch 149

Actual result: There is no evidence that admin toolbar is active. However, if I go to Extend, it shows that the admin toolbar module is in fact active.

And for the following steps:

Steps:
1. Go to https://simplytest.me
2. Enter admin_toolbar for the project
3. Select 3.x-dev
4. Open the advanced options
5. Keep Drupal core 11.2-dev as the core version
6. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/138.patch
7. Click add additional patch
8. Paste patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/149.patch

Expected result: I get both the improvements in tabbing sequence provided by patch 138 and the contrast improvements provided by patch 149

Actual result: I get the improvements in tabbing sequence provided by patch 138 but not the contrast improvements provided by patch 149

Actually, I'm seeing inconsistent behavior as I navigate through the admin toolbar menu.

Focus on specific menu and submenu items are indicated with the green highlight.

Focus on Manage, Shortcuts, the user name, and Announcements are indicated by a thin underline.

Focus on Edit appears to use the browser default.

It would be good to unify the focus indicator so users don't have to hunt it out and perceive changes to it as they navigate through the menus. I would expect the focus indicator to be consistent through the entire menu navigation.

It took me a while to figure out the following: Light gray in a menu item indicates that there a menu subordinate to it. That is, Content, Structure, Configuration, and Reports are gray while Appearance, Extend, People, and Help are not. Additionally, in the Content and other such menus, if an item in that menu has a submenu, there is a chevron indicating the presence of more items, so the light gray there is cosmetic and does not require contrast remediation.

However, the menus for Content, Structure, Configuration, and Reports do not have a chevron, so the light gray currently cannot be considered cosmetic. Either the contrast between gray and white needs to be improved to 3:1 (while retaining a 4.5:1 contrast between text and background) or a down chevron needs to be added to Content, Structure, Configuration, and Reports to indicate the presence of an additional menu.

Testing only admin_toolbar 3.x-dev version and Drupal 11.2 (without the other patch, which is a separate issue):

- Focus is shown differently from Active.
- Active is bold and underlined. I do find it odd that it's shown as a link (underlined), since it's active and I can't tab to it. That might be a separate issue.
- Focus is shown as a light green background. Styled as #abe4e0, it has only a 1.4:1 contrast with the white background, so is insufficient to use as an indicator to distinguish from unfocused. Using #33a39d for the focus background would provide 3.05:1 contrast with the unfocused background, which slightly exceeds the 3:1 contrast requirement for non-text contrast.
- But if we change the focus background to #33a39d, then the text color of #3d3d3d fails with text contrast of 3.55:1. We need to darken the text to #2d2d2d to get a contrast ratio of the required 4.5:1.

tl;dr: Use the following styling:

Focus background color: #33a39d
Focus text color: #2d2d2d
Non-focus background color: #ffffff
Non-focus text color: Can remain at #3d3d3d or be changed to #2d2d2d to be consistent with the text color for focus.

After attempting on simplytest.me to apply patch https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/138.patch to admin_toolbar 3.x-dev version and Drupal 11.2, I'm getting an error:

This may be the error:

Fatal error: Cannot redeclare function admin_toolbar_update_8005() (previously declared in /var/lib/tugboat/stm/web/modules/contrib/admin_toolbar/admin_toolbar.install:84) in /var/lib/tugboat/stm/web/modules/contrib/admin_toolbar/admin_toolbar.install on line 98
[warning] Drush command terminated abnormally.

charles belov → created an issue.

Interesting. 11.x-dev still fails for me but 11.1.x-dev works. Tested with 11.1.x-dev on simplytest.me.

Tested:

• description required and initially not entered, then enter when prompted
• description required and entered first time
• description optional and not entered
• description optional and entered

All work for me.

I thought that's what I did when I specified Drupal core 11.x and a patch of https://git.drupalcode.org/project/drupal/-/merge_requests/5876.patch

Is there some other URL I need to use to apply the patch?

Alas, I could not apply the patch.

simplytest.me gives the following errors:

This may be the error:

[warning] Drush command terminated abnormally.
Command Failed (Tugboat Error 1064): Exit code: 1; Command: cd "${DOCROOT}" && ../vendor/bin/drush si standard --db-url=mysql://tugboat:tugboat@mysql:3306/tugboat --account-name=admin --account-pass=admin -y

Doing a file compare between a successful simplytest.me (Drupal core 11.x dev only) and my attempt to include this patch on Drupal core 11.x dev gave the following notable differences in the simplytest.me log, from the patch attempt:

09447f901e195c35cd0dee# /bin/sh -c composer global config --no-interaction allow-plugins.szeidler/composer-patches-cli true
Changed current directory to /root/.config/composer
6809447f901e195c35cd0dee# /bin/sh -c composer global config --no-interaction allow-plugins.cweagans/composer-patches true
Changed current directory to /root/.config/composer
6809447f901e195c35cd0dee# /bin/sh -c composer global require szeidler/composer-patches-cli:~1.0
Changed current directory to /root/.config/composer
./composer.json has been updated
Running composer update szeidler/composer-patches-cli
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
- Locking cweagans/composer-patches (1.7.3)
- Locking szeidler/composer-patches-cli (1.0.8)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
- Downloading cweagans/composer-patches (1.7.3)
- Downloading szeidler/composer-patches-cli (1.0.8)
0/2 [>---------------------------] 0%
1/2 [==============>-------------] 50%
2/2 [============================] 100%
- Installing cweagans/composer-patches (1.7.3): Extracting archive
- Installing szeidler/composer-patches-cli (1.0.8): Extracting archive
Generating autoload files
No security vulnerability advisories found.
6809447f901e195c35cd0dee# /bin/sh -c cd stm && composer patch-enable --file="patches.json"
The composer patches file was created.
The composer patches functionality was enabled successfully.
6809447f901e195c35cd0dee# /bin/sh -c cd stm && composer patch-add drupal/core "STM patch 5876.patch" "https://git.drupalcode.org/project/drupal/-/merge_requests/5876.patch" --no-update
Gathering patches from patch file.
The patch was successfully added.
6809447f901e195c35cd0dee# /bin/sh -c cd stm && composer update --no-ansi
Gathering patches from patch file.

(later)

- Applying patches for drupal/core
https://git.drupalcode.org/project/drupal/-/merge_requests/5876.patch (STM patch 5876.patch)
Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/drupal/-/merge_requests/5876.patch

(later)

Fatal error: Cannot use Drupal\Core\Config\Entity\ConfigEntityUpdater as ConfigEntityUpdater because the name is already in use in /var/lib/tugboat/stm/web/core/modules/file/file.post_update.php on line 12
[warning] Drush command terminated abnormally.
Command Failed (Tugboat Error 1064): Exit code: 1; Command: cd "${DOCROOT}" && ../vendor/bin/drush si standard --db-url=mysql://tugboat:tugboat@mysql:3306/tugboat --account-name=admin --account-pass=admin -y
6809447f539fecb43c9c5a94 (simplytest) is suspended

Incorporating @sreenivas-bttv comment, which also has the advantage of backwards compatibility.

Corrected "external-video" to not have a space.

I'm not seeing a color background to the focused item, I'm seeing the same gray background on both the Report and Structure, as shown in my screen print.

But since you asked... And thank you for asking:

I suggest, just as Drupal inverts the colors on the active tab in the first row (Active Manage is black on white, other tabs are white on black), that you invert the colors on the active tab in the second row (Active Reports would be white on black, other tabs would remain black on white).

I also suggest that you not override the browser's default focus indicator with site-specific styling, but let the browser show its default focus outline, which varies by browser, just as the Drupal website does as of April 23, 2025. This would reduce cognitive load on the part of the user, as they would not have to figure out what the focus indicator was and could instead rely on the normal appearance of the focus indicator in their browser.

Testing with Drupal Version 11.1.7-dev on simplytest.me.

Yes, the issue still exists.

Steps:
1. Go to Simplytest.me
2. Create a website using 11.1-dev
3. Login as admin
4. Go to manage, reports
5. Press the tab key until the focus is on Structure

Expected result: the focus is clearly indicated and is well distinguished from the active tab, and both are well distinguished from other tabs (3:1 contrast)

Actual result: the focus and active tabs are styled identically and have 1.09:1 contrast with other tabs.

This has turned out to be an issue for us when a page title has a comma in it. Outlook uses semicolon as a delimiter in autocomplete fields.

If you want to keep it as a comma, maybe add an instruction below the field to quote strings containing commas. Now if a string has both comma and quote marks, that might be a problem.

This has not been implemented. In 11.1-dev, the steps still produce the result that I documented.

That said, this is no longer an issue for us as we no longer give editors the ability to set a page language, and we automatically set all new pages to English.

charles belov → created an issue.

I like Page Actions, as that most closely describes what the menu contains and will allow editors to accomplish. It says that the menu pertains to the current page and will allow you to do things with that page.

Page Tools would be my second choice.

"Quick Actions" and "Actions" don't work for me because it is not clear that they apply to the current page.

10.4.4 is available but the current version is 11.1.4 which isn't.

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

I can't seem to discuss the Drupal Accessibility Statement → at that page, so I'll post my comment here. I believe some of us legally need to follow WCAG 2.1. WCAG 2.2 drops Parsing, so we might need to support WCAG 2.2 plus Parsing. At the very least, I would expect Drupal and modules to not intentionally introduce parsing errors.

I am not an attorney and this is not legal advice.

charles belov → created an issue.

The search button does meet contrast on hover, but hover is not easy on mobile (I've never figured out how to do it), and requires action on the part of the site visitor. It needs to meet contrast when simply viewing the page without taking any action.

It is especially potentially annoying on Save/Preview/View Changes as they will potentially need to hover over three buttons to find the button they want or even know it exists, since it doesn't even meet 3:1 contrast. But it really needs to meet 4.5:1 contrast, since it's text.

charles belov → created an issue.

And after a meeting and then stepping away from the computer for a few minutes it hit me. "Hey, those banners for DDEV and DrupalCon probably had differently styled links below them, didn't they?" Went back, and yep, they do. So I had originally looked at three different banners which had action links and totally missed that they had links. Even the DDEV icon bleeding into the link div wasn't enough to get me to see that there was a link and not just promotional text.

Please consider changing your banner design to make it visually clear that the banner text and link are related to each other and are not unrelated pieces of content. The link as currently styledf looks more related to the breadcrumb trail, which I tend to tune out unless I need it, than to the banner text.

As a side note, it's odd that a banner about Drupal 7 end of life has a class dc-singapore-registration.

Hmmm, I find the HTML strange. The DOM copy contains:

<div class="region region-banner">
    <div id="block-drupalorg-announcements" class="block block-drupalorg">
<div class="block-inner">
    
  <div class="content">
    <div class="announcement"><img class="photo" src="https://www.drupal.org/files/styles/grid-2-2x-square/public/announcements/drupal-evergreen-logo-280X280px%20%281%29_0.jpg?itok=PHpn6rCb" width="280" height="280" alt="Announcement icon" title="Announcement icon">Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.</div>
<div class="cta"><a href="https://www.drupal.org/about/drupal-7/d7eol/migration-resource-center/enterprise" class="global-announce-banner dc-singapore-registration">Migration Resource Center</a></div>  </div>
  </div>
</div>
  </div>

where I would expect something like:

<div class="region region-banner">
    <div id="block-drupalorg-announcements" class="block block-drupalorg">
<div class="block-inner">
    
  <div class="content">
    <div class="announcement"><img class="photo" src="https://www.drupal.org/files/styles/grid-2-2x-square/public/announcements/drupal-evergreen-logo-280X280px%20%281%29_0.jpg?itok=PHpn6rCb" width="280" height="280" alt="Announcement icon" title="Announcement icon">Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our <a href="https://www.drupal.org/about/drupal-7/d7eol/migration-resource-center/enterprise">Drupal 7 End of Life resources page</a> to review all of your options.</div>
 </div>
  </div>
</div>
  </div>

I am using Firefox on Mac with quite a few preferences overridden in both Settings and about:config. I went to Safari, Chrome, and a factory-settings Firefox to test, but I'm not getting the Drupal 7 end-of-life banner on those browsers - either getting a banner about DDEV or DrupalCon or getting redirected to new.drupal.org - so have no way to test if it's something about my Firefox installations.

(Added after previewing my post)

Oooooh! I see it. It's a usability issue for the link. I was examining the code and wondering why I wasn't seeing a link for "Migration Resource Center" on the banner.

• The link to Migration Resource Center doesn't look like a link, it looks like page content, so I tuned it out because I was trying to use the link I expected
• The words "Migration Resource Center" doesn't match the words "Drupal 7 End of Life resources page," so I didn't make the association that they were related
• It would be much more obvious and easier to succeed at if "Migration Resource Center" were removed and "Drupal 7 End of Life resources page" in context was the link, or if the link to "Migration Resource Center" appeared as a button within the white area banner area rather than as a separate div with separate styling.

So the page isn't broken, it was just too hard for me to use. (Fortunately, we're already on modern Drupal, so I didn't need the info; I was just trying to be helpful by reporting the issue.)

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

charles belov → created an issue.

Would this issue properly be Closed (Won't Fix) given that Drupal 7 is end of life?

@arijit acharya Thank you for your suggestion. Again, "Contextual" strikes me a jargony and not meaningful to the average content editor. The simpler, yet meaningful, language the better. I don't think of pages as being a "context", I think of it as being the current page. I don't think of users as being a context, I think of it as being a user.

I'd really like to see something simple and straightforward like:

This page
This user

I also don't think of the various actions available as "tools."

Thank you for that suggestion. However, as with "Local Tasks," "Quick Links" does not imply it relates to the currently-displayed node.

What about "This Node"?

Although "node" is also jargony.

"This Page" if it's content?
"This User" if it's a user page?

I am QA, not a developer, so I am not able to comment on the relevance of the other issue.

I disagree that just not showing the module is an appropriate result of the version being missing from the info.yaml file for the module. I believe the correct behavior would be to show the module in the report; wherever version info was missing, the report would show "Missing" rather than a version number.

Just not showing the module at all makes the report look broken. In a long report, it could lead to incorrect assumptions about the current website.

Updating the issue description to show a new expected result.

charles belov → created an issue.

Confirmed it works, including testing adding a redirect.

I'm not sure my review is sufficient, so leaving in Needs Review.

charles belov → created an issue. See original summary → .

charles belov → created an issue.

I've reviewed the patch and the code looks good. I am running into problems figuring out how to run it in Simplytest.me, and will need to request help separately. I'll come back to this issue when I've resolved that.

Did some HTML in that last comment get rendered as HTML instead? There appears to be blank space between "necessary to add" and the period.

charles belov → created an issue.

I'll note "Suggest the minimum font size for Admin UI." might be too small for some people to read if they haven't set it. Although I realize they can use browser zoom to read it, make the setting, then reset browser zoom to actual size once they've set it.

@nayana_mvr That mock-up is exactly what I have in mind, thank you. I would be likely to use the Unreduced setting.

Actually it could be a drop-down for minimum font size:

Extra Extra Small (default)
Extra Small
Small
Unreduced

Then could the separate window could be generated from the database? The source doesn't matter; what matters is that it be the same source.

+1 for parsing the yaml tour as it ensures the steps and labels are in sync and no duplicate effort.

Hmmm, if the behavior of whether or not a new content type is automatically enabled is dependent on whether or not all existing content types are enabled...

Then is there any feedback to the administrator that this logic decision has taken place? While this may be the expected behavior, it is still easy to overlook if it is not the desired behavior for a particular content type. I recognize that the change in configuration may have occurred in code rather than through interaction with the administrative user interface. Just trying to avoid surprises.

Another use case is accessibility. Words in all caps can be misread by screen readers. Sentences in all caps also present cognitive load to some - myself included - and are also harder for people with low vision to read. Therefore, we want to be able to review all content in all caps to ensure that they are acronyms/initialisms and not words in all caps. Definitely two consecutive word units in all caps would be highly suspicious as being words in all caps.

Adding accessibility tag. While it doesn't affect Drupal's accessibility, it is a blocker to monitoring for accessibility in editor content.

I'm not sure why it would be harmful if something has been specified twice to only do it once. That said, I guess if one removes something, then one would expect it to go away, which wouldn't happen if it were specified twice.

Then I would suggest the following wording for Source editing:

This plugin adds a list of HTML tags that can be used while editing source. Remove or do not add tags that are already supported by other enabled plugins. For example, if "Bold" is enabled in the toolbar, do not add the tag. If another plugin requires a tag but does not supply it, you will need to add that tag here.