🇩🇪Germany @rkoller

This week, instead of discussing a particular issue, we have taken a general look at the skipto module. I wanted to get some feedback about its general direction. After there is no issue to comment on I use the comment here to provide a summary. These are the three issues that got created:

✨ Make the skipTo module configurable on a per user basis Active
📌 Add a percentage suffix to the position option Active
📌 Remove main-only option from heading checkbox list and add radio buttons instead Active

The other detail about making div and nav lower case will be covered in the already existing 🐛 Improve the microcopy on the settings page Active . The rest of the raised issues will get issues upstream at https://github.com/skipto-landmarks-headings/page-script-5 :

• If the focus is moved from the last available heading to the about skipto.js the focus outline remains on the last heading
• the form of the landmark regions is hard to read due to the front loading of the landmark type and its potentially redundant nature - several landmark regions starting with for example Navigation: in a row
• the indendation based on the heading level makes the heading list very hard to read - and the heading level is already communicated by the number

benjifisher → credited rkoller → .

rkoller → created an issue.

we have discussed the issue in yesterdays a11y office hour. The other attendees, @katannshaw and @the_g_bomb, were also uncertain what the expected behavior would be with voiceover activated in regard to the start and end of dialog modals. I have asking over in a11y slack still on my to do list - hope i will get to it over the weekend. but i've remembered https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ and there safari with voiceover behaved the same like in safari.mp4.

i've pulled the latest changes for MR100 (see safari_latest.mp4). you managed somehow that tab and VO-arrow left and right behave the same in regard to reaching the end or the start of the dialog modal! wow! firefox behaves the same now like safari. the only thing, in edge i still have a "VO arrow trap" on the privacy policy link.

I like the consistency inbetween tab and VO arrow but it would be still good to find out what the expected behavior would be for actual screenreader users.

p.s. i completely agree that going with the dialog element would be the cleanest approach, but yep that should ideally happen upstream.

rkoller → created an issue.

rkoller → created an issue. See original summary → .

updated the user interface changes section in the issue summary (uploaded another screenshot so the before and after are both in a dialog modal.

i not necessarily meant that the icon color should be lighter. i was just thinking out loud if there was some intention behind the lighter color choice for the default icon . but strictly speaking, if some information would be conveyed via a different color that would be against SC1.4.1, therefore a +1 for the consistent colors you've went with from my end. and i've also discussed that question in todays accessibility office hour with @katanshaw and @the_g_bomb and both agreed as well. overall this looks good to go imho. not sure if it would be ok for me to rtbc the issue, since i've opened it. maybe wait for a second opinion, but a +1 for RTBC from my end.

thanks @lostcarpark! that looks good, going with the same color like the rest of the icons is definitely fixing the color contrast issue (it has a contrast of 6.7:1 now). the only thing i wonder, was it the intention by going with a lighter grey for the default icon to differentiate from the bespoke ones so it "stands out" somehow? I have no strong opinion either way as long as the contrast is meeting the minimum requirement.

about the question if the original version should be removed, definitely a valid question, but i dont know. i would assume it would make sense to clean that up if it is not needed anywhere else anymore.

one addition, other dialog modals in core (tested admin/structure/types/manage/playground/fields) when testing in safari and edge behave the same way like the safari.mp4 example does. firefox is close but also shows some unique odd behavior. when you are back at the beginning of the dialog with VO arrow left you then jump between the close button and the title instead of sticking to the close button. i will research the expected behavior for the voiceover cursor still, but that quick test proofs that something more is off in klaro within the scope of this MR or klaro in general compared to the behavior of drupal core.

thank you! i've tested MR100 on macOS Sequoia. the tabbing problem looks like solved now. but in addition to that i've also tested the stepper in voiceover (ctrl-option arrow left and right) within the dialog modal, but i am not entirely sure what the expected behavior should be. should it be as shown in safari.mp4 (better mute your audio cuz i am skipping through the interface fast which can be very distracting) so that it stops at the last and first element in the AOM or should it behave like with tabbing and jump from the last element to the first (tab) and from the first to the last (shift tab)? i am gonna do some more research (we have the a11y office hour in about an hour, gonna ask others there, and i am gonna ask over in the a11y slack if necessary as well - made me curious).
and there is another detail i've noticed, when testing the same in edge the voiceover stepper gets trapped within the privacy policy link (edge.mp4). as soon as the voiceover cursor is on the privacy link i cant step forward but also am unable to step backward, i am trapped within the link. and finally i've tested the same setup with firefox. at first i've thought it is behaving like safari, first with the tabbing and then with the voiceover stepper. but well, watch the video until the end, and you will notice the stepper is able when getting back to the close button to step past it outside the dialog modal and you then start stepping through the entire background of the dialog - you are actually leaving the AOM (firefox.mp4)

is that problem already covered in ✨ Add alternative link for opening Consent Manager Active ?

Sorry took a little longer than anticipated, but my eye problems have flared up again, making longer text where you have to focus a bit cumbersome. I have taken a look at MR199 and played around with the merge request. I’ve noticed a few things:

1. It looks like there is some additional padding between the Enabled services heading and its table underneath - that way the heading looks pushed towards the Add service button and the gap between the heading and the table is way bigger for the Enabled services compared to the Disabled services. It is probably due to margin-block-start within the .tabledrag-toggle-weight-wrapper class selector. I suppose due to the fact that the other pages that are using the enabled/disabled pattern don’t have the option to sort in consequence they also have don't have the Show row weights link on top of the table, and the div that is containing that link has that margin causing the larger gap.
2. The drop buttons in the Operations column are way bigger than usual - they look like twice the height compared to the drop buttons on for example admin/structure/display-modes/view, admin/structure/view, or admin/content.
3. The status checkbox pattern for enabling and disabling services works as expected, but it has a few downsides.
   • It is introducing a new pattern for handling the enabling and disabling of services, that is breaking with the existing one users are already familiar with - the other pages are using an Enable and Disable options on the drop buttons in the Operations column.
   • With checkboxes in place you have one additional click for saving the configuration, after selecting/checking all the services you want to enable or disable.
   • Those status checkboxes make you, the user, think. Depending on what you are trying to change, for disabled services you want to enable you might catching yourself thinking do i select the services to enable by ticking them, while the other way around if you want to disable services and you are still in that “selection mindset” you might leave those services checked you want to disable. Also due to the fact that the position of the service is only changed when the save button is clicked you might have both sections with checked and unchecked services. The cognitive load is high that way. :/
   • Save configuration button label and the Status<code> column header are decoupled semantically from the section headings <code>Enabled services and Disabled services.
   • And finally the width of the columns differs between the two tables.
4. If you enable or disable all available services, either way you are getting No services have been created yet.. This is sort of inaccurate since Klaro is shipping with 23 services by default.

In the following a few suggestion how to tackle the aforementioned points:

about point 1: If possible I would reduce the margin between the Enabled services heading the associated table.

about point 2: The other pages using the enable/disable pattern are using the extra small variant size for drop buttons from the Drupal Design System. I would suggest to stay consistent in regard to the styling. →

about point 3: I would suggest to follow the pattern the other pages with the enable/disable pattern are using. Remove the status column and adjust the width of the remaining columns in-between the two tables. On the drop buttons of the Enabled services section, keep Edit the default option and add a Disable option as secondary action. In the Disabled services section make Enable the default option on the drop button and move Edit to the secondary actions. If you enable a disabled service it is directly moved to the enabled services section, same as the other way around.
The only slightly “odd” detail about that pattern is having those handles for changing the order of enabled services by dragging them vertically. My first impulse was testing if it would be possible to disable services by drag and drop. But it was clearly communicated that dragging a service to a different section doesn't work/is not intended AND the disabled services section doesn't have those handles.

about point 4: Uncertain if it might be too granular, but the most accurate approach would be to check if there are no services created yet and then show No services have been created yet. in the enabled as well as the disabled services section. If there are services created, and none of them is enabled use something like There are no enabled services. in the enabled services section, if none of them is disabled use something like There are no disabled services. in the disabled services section.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

I forgot to leave the direct link to the summary of the meeting in a comment here as well, it can be found at #3511972-42: Allow Composer and rsync location to be configured via the UI →

rkoller → created an issue.

updated the link on the issue we've discussed so it is pointing to this issue instead of the one i've closed down.

updated the parent issue, moving to the other issue for the 6th of june

closing this issue for 📌 Drupal Usability Meeting 2025-06-06 Needs work and i also remove the parent issue to exclude it from the issue chain of ux meetings

benjifisher → credited rkoller → .

rkoller → created an issue.

rkoller → created an issue.

Created followup issues in the olivero queue ( 📌 The title of a dialog modal is getting truncated Active ) and the umami queue ( 📌 The title of a dialog modal is getting truncated in Umami Active )

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

I've taken a look at the MR92 on macOS Sequoia with the latest Safari and VoiceOver. At first, both are things i've tried to get into a PR upstream in klaro-js a few weeks or already months back, but I've struggled to get the tooling working properly and then got distracted :(, but i guess in the long run it might still be reasonable to create a PR for those changes upstream. But for now it is already fixing the imminent issue within the context of drupal, therefore a double thumbs up for creating and working on the issue.

about point 1: semantically, it feels odd to have a link element that is styled as a link but with a role of button. I consider it cleaner to use links for what they are made for, to point the user to another page, while buttons are used to let the user do something on the current page. if the element should be a button then i usually prefer to also use an actual button element - except overriding the markup by klaro would complicate things and it would be a jumping through hoops. :/
aside the question if a link or a button element is used in regard to semantics, i wonder what type of button should be used styling wise: a secondary button, a button or an action link? (for context see the drupal design system ) . It also feels odd to have two primary buttons (decline and accept) on the dialog, shouldn't it be only one primary button there?
In regard to the aural interface there is another detail to note, all the three buttons are missing a context, if a person is navigating by for example the rotor and gets only announced the available buttons on a page it is close to impossible to figure out the context for each button, and it should be avoided that a user has to inspect the close proximity of the element to learn about the context (check rotor.mp4 - close your eyes and try to make sense of things without the visual context). but the points about the styling and the labeling are probably out of scope for this issue.

about point 2: There is the problem that the focus isn't contained within the dialog modal, you are able to tab in and out of the modal and into the background of the modal or into the browser window (see tabbing.mp4)

Left a brief comment on the issue #3370326-54: Refine labels and descriptions for field types → and i will push the changes we've discussed to the issue later today.

At 📌 Drupal Usability Meeting 2025-06-13 Active , we continued work on this issue, I will push some of the discussed changes later today. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.

I’ve demo’ed the current state of the MR at the monthly NWDUG meetup last Tuesday. For the record the attendees I am aware of their nickname on d.o were: @asherry, @bernardm28, @dydave, @h2cm, @mr_scumbag, and @philipnorton42. All in all, the first impression was also a good one, an improvement over the current state. They had a few comments on certain field types and groups we’ve taken a look at, in no particular order:

• On the first step the hyphenation used on the descriptions was considered distracting and making it harder to skim
• It was suggested to move the bullet point Recommended for to the top of the bulleted lists. It was argued that what a field type is recommended for is the most important information people are interested in, and they could then still read on in case they want to know more in-depth information.
• In regard to the bullet point Efficient storage on for example short plain text it was asked does that imply that the other ones listed are not efficient then?

left a comment on the issue: #3511972-42: Allow Composer and rsync location to be configured via the UI →

and for the record the attendees of the meeting last friday were @simohell, @worldlinemine, and myself

Posted a comment on the composer and rsync issue: #3511972-42: Allow Composer and rsync location to be configured via the UI → ... and it looks like the file name issue still needs a comment.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-05-30 Active . The recording of the meeting: https://youtu.be/18q8p7xz7VE. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.

We revisited this issue at 📌 Drupal Usability Meeting 2025-06-06 Needs work . That issue will have a link to a recording of the meeting. For the record, the attendees at the second meeting were @rkoller, @simohell, and @worldlinemine.

We have taken a look at the new settings page on admin/config/system/package-manager, the change to the check for composer on the status report page admin/reports/status, and simulated a few scenarios by renaming composer and rsync binaries in the DDEV web container, and experimented with overriding those executable path settings via the settings.php file. A few observations:

1. Having a status message that is reporting that the paths for composer and rsync were automatically detected each and every time a user is visiting admin/config/system/package-manager raises many potential questions and might be confusing to the user. One might ask themselves is it necessary to access this settings page first, before package manager is able to autodetect composer and rsync, until then the two binaries remain unavailable to the site and package manager since the auto-detection was not trigged yet? Furthermore one would expect as soon as the two binaries were autodetected the status message wouldn’t show up ever again as long as the path and/or file name don’t change - why is something auto-detected and announced again and again after it was already detected and the executable path set for that location? Having a status message informing the user about a state change, a newly arisen situation, and/or a successfully completed task is the right purpose, but having a redundant message about a task that was already successfully accomplished feels counter productive and leaves a certain uncertainty about the persistence of that autodetected setting.
2. It seems the accuracy between the auto-detection on admin/config/system/package-manager and the composer test on admin/reports/status is divergent. Out of the box with /usr/local/bin/composeravailable in the DDEV web container admin/config/system/package-manager reports that composer is automatically detected, and admin/reports/status reports it checked successfully for composer returning 2.8.9 (/usr/local/bin/composer). If you rename /usr/local/bin/composer to /usr/local/bin/composerer, reloading admin/config/system/package-manager returns again that the path to composer was automatically detected, while admin/reports/status is throwing an error on reload that composer is not found. If you now change the executable path on admin/config/system/package-manager to /usr/local/bin/composerer and save, the status message again returns that composer was automatically detected, same for reloading admin/reports/status, it reports that it successfully checked for composer returning 2.8.9 (/usr/local/bin/composer). The only time you are able to trigger an error on admin/config/system/package-manager is by changing the executable path to /usr/local/bin/composer while path and binary are still renamed to /usr/local/bin/composerer. In consequence, the auto detection on admin/config/system/package-manager feels not trustworthy compared to the status check on admin/reports/status.
3. If you change the composer executable path from /usr/local/bin/composer to another binary that is available in the same directory within the DDEV web container, like /usr/local/bin/node, the form is still getting validated successfully.
4. If you set $config['package_manager.settings']['executables']['rsync'] = '/usr/bin/rsync’; in the settings.php and change the rsync executable path to /usr/bin/rsyncer on admin/config/system/package-manager the following two warnings show up twice:
   

   Warning: Undefined array key "#parents" in Drupal\Core\Form\FormState->getError() (line 1176 of /var/www/html/repos/drupal/core/lib/Drupal/Core/Form/FormState.php).
   Drupal\Core\Form\FormState->getError() (Line: 166)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 126)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 126)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 26)
   Drupal\Core\Form\FormErrorHandler->handleFormErrors() (Line: 200)
   Drupal\Core\Form\FormValidator->finalizeValidation() (Line: 119)
   Drupal\Core\Form\FormValidator->validateForm() (Line: 585)
   Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
   Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
   Drupal\Core\Controller\FormController->getContentResult()
   call_user_func_array() (Line: 123)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 622)
   Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
   Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
   Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
   Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
   Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
   Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
   Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
   Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
   Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
   Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
   Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
   Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
   Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
   Drupal\Core\DrupalKernel->handle() (Line: 19)
   
   Warning: foreach() argument must be of type array|object, null given in Drupal\Core\Form\FormState->getError() (line 1176 of /var/www/html/repos/drupal/core/lib/Drupal/Core/Form/FormState.php).
   Drupal\Core\Form\FormState->getError() (Line: 166)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 126)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 126)
   Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState() (Line: 26)
   Drupal\Core\Form\FormErrorHandler->handleFormErrors() (Line: 200)
   Drupal\Core\Form\FormValidator->finalizeValidation() (Line: 119)
   Drupal\Core\Form\FormValidator->validateForm() (Line: 585)
   Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
   Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
   Drupal\Core\Controller\FormController->getContentResult()
   call_user_func_array() (Line: 123)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 622)
   Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
   Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
   Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
   Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
   Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
   Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
   Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
   Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
   Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
   Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
   Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
   Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
   Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
   Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
   Drupal\Core\DrupalKernel->handle() (Line: 19)

   . The warning is also shown if you set the executable path and the settings override to /usr/bin/rsync but set a none existing executable path for composer like /usr/local/bin/composerer. So the warning seems only to show if either of the two executable paths is failing the form validation and one of the two fields is overridden in the settings.php.

The points we came up with:

• We had a clear consensus in both meetings to recommend replacing the status message with a text box (solves point 1). Instead of auto-detecting and creating “noise” every time you visit admin/config/system/package-manager, simply display the path the two binaries are available at and auto-detected in a text box. Only return an error message, with the same accuracy as experienced on the reports page (solves point 2), if package manager is unable to auto-detect the binary/binaries. That way the user is always in control and gets the reassurance everything is in place and package manager is fully operational. At the same time it is clearly communicated that it is possible to change/override the executable path(s) - for that the two fields should not use any placeholder text and be empty instead.
• In addition to adding the text box, we would also suggest to change the title of the field set underneath from Executable path to Custom executable path to further clarify that you are actually overriding the auto-detected defaults here and/or provide working executable paths in case one or both binaries are not available on the host.
• We also had a clear consensus adding the check available for composer on admin/reports/status for rsync as well. We’ve already created a follow up issue for that: ✨ Add a runtime requirements test for rsync analogues to composer Active
• The warning about the undefined error key in case settings are overridden via the settings.php should be fixed. (solves point 4)
• In the end we wonder if one of the following scenarios we’ve observer and/or discussed have any security implications:
  • Adding a different binary, like for example node, for composer and/or rsync (see point 3)
  • Adding an executable path to a binary in the sites public or private folder, a location where users are able to upload files.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

the_g_bomb → credited rkoller → .

About the styling, i am not that savvy and familiar with Figma for being able to extract the exact specifics, but in case I interpret the current changes in the MR correctly then:

• the padding between a breadcrumb item and a breadcrumb separator is 0.5rem in the MR while in the styleguide it is set to 0.75rem same as for Claro without the MR
• the separator has the extend of 4px by 4px (width by height) while in the figma file it looks like 3px by 6px..

the increase in separator size got fixed. thanks! oh and the separator is still pointing upwards for RTL languages.

The reason why the pipeline is failing, the linter requires vertical-align come before border-inline-end, but vertical-align is at the end. and looking at https://git.drupalcode.org/project/drupal/-/merge_requests/12046/diffs that also notifies that the file was modified in the source and the target branch - needs someone with write access to resolve that. and i guess the MR could need a rebase in any way, due to the rename of the SandboxManagerBase class in package manager, that is requiring me to uninstall project browser when i try to checkout this MR for testing.

and i am in the process of reviewing the latest changes by @ll66382, will post another comment later.

your latest commit did the trick. tested with the combination of claro and navigation module, gin and the navigation module, and gin, gin_toolbar and the navigation module, all in safari, firefox, and edge on macos sequoia, and in every scenario the toolbar is shown now! thanks!

the_g_bomb → credited rkoller → .

the_g_bomb → credited rkoller → .

rkoller → created an issue.

nice thank you! I've manually tested the MR12310, and i can confirm that the WSOD is gone when I am installing workspaces and workspaces_ui. also tested step wise uninstalling. everything works fine (only noticed a color contrast issue on the confirmation dialog for switching the workspace - will check existing issues later and in case file an follow up, after it is clearly out of the scope for this issue). i'll leave the issue at needs review since i am not able to review the actual code.

probably a duplicate of 🐛 InvalidComponentException when workspaces and workspaces ui is installed Active ... someone already opened a merge request there but that isn't fixing the issue (but the issue wasnt set to needs review yet so the MR is probably still a work in progress)'

and on a side note while going through the info files i've noticed too more detail probably out of the scope for this issue.

in pii_ui.info.yaml the second dependency is pii:pii_ui shouldnt that be just pii? and i guess it might make sense to also remove the requirement for drupal 9 in pii_ui.info.yaml and pii_api.info.yaml

After a brief discussion at todays monthly track meeting i'Ve changed the suggestion from Privacy to Privacy & Data protection per the recommendation from @jurgenhaas. According to him, the scope of the term privacy alone would have been too narrow.

the only detail, looking at the screenshot, the module names might need some adjustment as well, the three look sort of inconsistent.

rkoller → created an issue.

rkoller → created an issue.

benjifisher → credited rkoller → .

and while writing up the summary in the previous comment i've also noticed one other detail, for consistency reasons it might be worth a thought moving the help text on the field upload group on the second step right before the field types instead of after them, after we've enabled help text on for example the selection list group right before the field types.

I’ve demo’ed the current state of the MR at the weekly lean coffee table call from the Drupal User Group Munich on Tuesday. For the record the attendees were @drubb, @franz-m, @jurgenhaas, and @martin mayer - most experienced longtime backend developers). All in all, the first impression was a good one, an improvement over the current state. They had a few comments on certain field types and groups we’ve taken a look at, in no particular order:

• On the first step in the dialog modal, with the list of field types and groups, they commented that some field types might be placed more prominently, for example finding the link field type close to the end felt surprising - it was considered an important and often used field type, and with more additional field types listed it could get easily missed.
• In regard to the description of the group for Formatted text “…with option to assign text editor”, the with “option to assign” sounded odd and off for none native english speakers.
• Looking at the descriptions for the three field types within the Formatted text group their first remark was about the order of the descriptions.
  • They considered the detail about, if a field type is single row or multi row the most important detail, instead efficient storage was the first bullet point on the field type for short text.
  • Even though the group title is formatted text, short is explicitly mentioning that you have certain formatting options, the other two don’t have that mention. By explicitly naming it for one field type , the indirect assumption/conclusion is that it is not available on for the others.
  • Aside reconsidering the weighing of bullet points for the different field types by importance, they also suggested to reconsider the grouping of text related field types. Instead of going with Plain text and Formatted text, the suggestion was as already mentioned to make the single and multi row aspect more prominent by grouping by single row and multiple row.
• In regard to the description “Maximum values depend on the system” on the integer number field type, attendees have asked, where would it be possible to find that kind of information if it is mentioned here? A direct pointer is sort of missing.
• in the File upload group it was confusing to see the example of jpeg/png/webp/gif for the file as well as the image field type.
• Within the Reference group, why the “Other” field type label? It was considered confusing and sort of ambiguous.
• On a related note in general it would be helpful to provide clear and brief instructions for media/file/image when to use which

rkoller → created an issue.

re #61 ✨ META: Provide locale (regional) formats framework for automated translation of non textual data Active i agree, that adding an option for following the defaults for the display language for the thousand and decimal marker is a good idea. the only thing i might object is moving that setting into the field settings (if i understand the proposed resolution correctly). the fields settings is mainly about storage in the database, but those settings are about how thousand markers and decimal markers are presented in the frontend to the user. that way i guess the better choice would be to keep those two select fields where they currently are on the manage display page and simply add those options to the select lists (and set them as default)?

re #62 ✨ META: Provide locale (regional) formats framework for automated translation of non textual data Active i completely agree and i wonder if aside adding those localization setting to /admin/config/regional/settings it would make sense or even be necessary to consider adding those settings to the user profile page as well. so a user is able to override the global localization settings.

added before screenshots for selection list and reference and also added before and after screenshots for the first step to illustrate the change there (removing the mention of the concept of field as well as the periods at the end as well as the general streamlining of the descriptions)

Added two screenshots so that they can be used in the to be updated issue summary. and i also adjusted the the issue title to the updated MR title, after the issue is not only about the descriptions but also about the labels. and the draft status got removed from the MR as well since all the changes are in and tests are passing thanks to @benjifisher

left comments on #3370326-31: Refine field descriptions → and #3511972-41: Allow Composer and rsync location to be configured via the UI →

We haven't had the time for a full review in today's meeting ( 📌 Drupal Usability Meeting 2025-05-23 Active with @benjifisher, @rkoller, and @simohell), we just got to it during the last ten minutes. We will revisit the issue hopefully next week. But I am writing this comment cuz we stumbled across one noteworthy detail:

while demonstrating the MR, i wanted to demonstrate the detail about when the binary is not available (for that i've simply renamed rsync to rsyncer and composer to composerer within the webcontainer in ddev). when i got to the settings page from the reports page i think ive adjusted the names to the new naming in the executable path fields and saved - then the contradictory message showed together (see the screenshot). problem is when i was trying to reproduce the behavior the settings page behaved odd. the reports page was properly noting when composer was available and when not (when i'Ve renamed it). but on the settings page sometimes the binary was shown as autodetected even though it was renamed, at one time it seeemed even the path and file name got auto adjusted to the renamed file name. have to test some more tomorrow.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-05-23 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.

In todays meeting we've discussed the remaining questions in #3370326-27: Refine field descriptions → , the changes we've agreed on were already committed by @benjifisher and myself. To contain the scope we've created three followup issues:

• ✨ Add the option to customize the order of field types in field type groups Active
• ✨ [PP-1] Make the titles for the field creation flow more consistent and communicate that it is a multipage form Postponed
• ✨ [PP-1] Make field types and field groups distinguishable Postponed

the fourth point we touched today we've already opened another followup 📌 Add media reference to the same field type group as file and image Active , it is about the question where to place the media field type and the potential confusing of the naming of the group that is containing the file and image field type. and it has to be pointed out that 📌 [PP-1] Move label and machine name fields to the field config edit form Active is also important in the context with this issue.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

rkoller → created an issue.

rkoller → created an issue.

And forgot to postpone the issue on 📌 [PP1] Refine field descriptions Active

rkoller → created an issue. See original summary → .

should the default branch also be set to 2.1.x, at the moment it is still at 2.0.x?

it might be good to discuss 📌 Allow composer location to be configured via the UI Active ... Ran into that issue and after some initial testing #3511972-32: Allow Composer and rsync location to be configured via the UI → and due to the fact that according to the issue it looks like there wasnt a pattern in core so far to edit the paths for certain binaries it might be a good idea to discuss that topic in a meeting on friday.

one question, i've checked out the MR and tested in DDEV. Both binaries, composer and rsync, are available within the ddev webcontainer at the default locations, and ssh'ed into the container to make sure that it is the case (*and it is, both are available).

The question i have, when the composer and rsync binaries are available and in default places (/usr/local/ & /usr/bin/), is package manager then fully functional with no further actions necessary?

At the moment the ui is sending mixed and a bit confusing messages in my testing. For one the path for composer has "auto-detected" appended. strictly speaking a placeholder text is about to inform the user what kind of data could be entered into that field not a status check. it imho can't be taken for granted that a placeholder text informs you about everything is all right, that the binary is available and composer will be available to package manager. and if i would take for granted that auto detect placeholder would inform me about the availability then i would assume that i have to enter a path for rsync because it is not available in the default location in /usr/bin/.

that placeholder approach leaves a quite a bit of uncertainty to me the user imho.

Created the followup 📌 [PP-1] Update all comments and documentation in Project Browser to refer to "sandboxes" and related terminology Active

rkoller → created an issue.

@acbramley i couldnt remember at all what i was referring to that i've outlined in point 2. i did some digging and first installed drupal 10.1 (thought the discussion were around that time) but the block types page havent had any help text - same as in 11.x. i've then installed drupal 10.0.0 et voilá, mystery solved:

So I guess most of the points in #34 are listed as fixed. the only point not labeled with fixed would be #34.5. so i guess i agree with you and @quiteone for closing this issue, and reassess the status quo soon and open up a new in case there is a need?

forgot to upload the mp4 i've mentioned.

thanks for the thorough and thoughtful comparison in #4 🐛 Breadcrumb separators are focusable Active between the approaches in Gin and Claro @batigolix. i've also discussed the topic with @the_g_bomb in the weekly drupal cms a11y call today. In addition to your assessment we've done a smanual test and simply checked out MR12046 which fixes the issue for Claro ( 🐛 Breadcrumb separators are focusable with the voiceover cursor and get also announced Active ) and then switched the theme to Gin with the MR still active for Claro - the breadcrumb separators remained focusable in Gin - q.e.d. to your assessment

After the meeting I've manually tested MR617 in Gin. The only minor nitpick to note is checking out the MR adds some slight padding (see padding.mp4) which is "probably" negligable (tested in safari in sequoia)? or would that slight padding shift be easily preventable?

Aside that everything looks good. The seperators are not focusable anymore and i've also cross checked if the separators are displayed correctly for RTL - all fine. excellent thank you!

I agree it is a disruptive change, but also a necessary one. There is actually already an issue where discussions and work happened over the course of the last few months: 📌 [PP1] Refine field descriptions Active . The issue has a broader scope since we are also refining the descriptions as well. I've quickly skimmed through the suggestions in the issue summary, and they are mostly in line with the suggestions in the current draft. Sole difference, with ✨ Use modal in add new field flow Active in and the field creation flow moving into a dialog modal, we wanted to make the dialog modal title more explicit for each step of the wizard. In consequence instead of something like Long formatted text, the title would be called "Formatted text" (and maybe something like "Step 1 of 3:"prefixed) and the available fields would be called "Short text", "Long text", "Long text with summary" - we also disliked parenthesis within the labels which puts a toll on readability.

A summary of the current state and the open to-dos can be found in #3370326-27: Refine field descriptions → . The issue itself contains a lot of information and discussion, and most of the initial thought process is contained in https://docs.google.com/spreadsheets/d/1Lx7L40eRHotr5KQGn6au5WxQO3lFv19a... (there are also some more ideas for follow ups in the comments there).

If it would be ok with you @tstoeckler i would suggest, to invite you to join the discussion over in 📌 [PP1] Refine field descriptions Active (would be really valuable to get some additional feedback there - the recent discussions were solely around the regular attendees of the ux meetings) - simply to focus the effort in a single issue if that would be ok with you?

would it make sense to open up a follow up issue for comments and parts of documentation that are still using the term stage as a reminder? for core that is also handled in a follow up issue ( 📌 Update all comments and documentation in Package Manager to refer to "sandboxes" and related terminology Postponed ).

thanks for the MR @ll66382, i finally found the time today to test MR12046, a few observations:

1. The MR fixes the basic problem the issue is about. i've tested in voiceover on macos sequoia and neither by tabbing nor by the voiceover cursor the seperators are announced anymore, excellent!
2. If you compare the styling of the seperator between 11.x and the MR you will notice that the MR increases the separator size (compare in styling.mp4) - it seems like the separator is bigger now compared to the drupal design system
3. The orientation of the separator in LTR is correct but for RTL it points up instead of to the left

And the separator looks fine in forced color dark mode - it is possible to test those in for example edge on macos (what i did) . In the screenshot you see the necessary settings to set the forced color dark mode in the rendering tab:

the other option is the page color setting in the accessibility section of the edge settings.

and there things look also fine in for example the desert theme

the_g_bomb → credited rkoller → .

Left a comment: #3163716-24: Add next and previous buttons to database log entry pages →

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-05-16 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were benjifisher, rkoller, shaal, simohell, and worldlinemine.

We have based todays discussion on MR12089, in the following a list of details we’ve noticed:

• Previous and Next are styled as buttons, but they are actually links.
• In the current state each button only contains a button label, the user is required to read/skim the label, there are no visual cues like additional iconography.
• Since the two buttons link to other pages, strictly speaking SC2.4.4 (Link purpose - in context) applies here - after the labels Previous and Next are missing some sort of context.
• When you are on a details page and press the Previous or Next button repeatedly, you will notice that the column with the row labels is sort of uneasy and shifting constantly in width in between log messages - on some page the column gets even that narrow that the label wraps to a second line. From a readability point of view, you don’t have a fixed starting point for your eyes, you have to adjust on every page, which leads to an increased cognitive load if you are clicking through several error messages in a row (see column_width.mp4).
• If you consider the use case of a site with thousands of recent log messages, there is the problem that the Previous and Next button are not respecting the applied filters. If you filter your log messages for example for a particular error message, and then click on one of the filter results, the filter scope is being reset - pressing Previous or Next on the details page will not bring you to the next/previous log message of your filter results, but to the next log message overall.

Aside the aforementioned points we’ve also asked ourselves if there is already a pattern in Core using such a Previous and Next pattern to step through instances - but we were unable to come up with one - there is only the remotely related Pager pattern used on Views (for example on /admin/content). In conclusion, these are the points the group reached a consensus on to suggest in scope for this issue:

1. Instead of displaying links as buttons, style them as actions links (see Drupal Design System → ) - that would be semantically more appropriate since each of the two point to a new page. Also re-add those single forward and backward step icons shown on the Figma link.
2. Add some context to the button label by using the slightly more verbose Previous log message & Next log message as the label for the action links.
3. Let the Previous and Next action links respect a set filter value. If you are for example filtering for the type “php” with a severity of “error” and you get four matches, log message number 25, 126, 134, 175, and you click on the detail view for number 126, the behavior on the detail page should be as follows:
   • There should be a button with the label Clear filter
   • Clicking Next, forwards you to log message number 134
   • Clicking Previous twice, forwards you to log message number 25
   • Clicking the Clear filter button, the button would get hidden, and in this case the previous button would get shown again (since in the scope of the filter results 25 is the first available message and Previous button hidden) - clicking the Previous button would forward you to log message number 24, clicking the Next button to log message 26, instead of going through the four available numbers of filter results.
   • Through the display of the Clear filter button it should be self explanatory that the current scope of displayed log messages are filter matches, while when the Clear filter button is not shown the scope is all the existing log messages. But ideally that could be validated in user tests, perhaps additional (visual) cues might be necessary.

In regard to the problem with the shifting column width, we’ve thought that is not “directly” related to this issue and should probably be moved to a followup issue instead.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Thank you @dev.drupal.ln & @batigolix for picking up and working on the issue, and apologies for the late reply, i am quite behind on going through all the a11y issues across issue queues that received attention recently. :( Todays a11y meeting was a timely and necessary reminder. So I went ahead and have taken a look at MR93 - a few observations:

1) The styling of the filter field needs some work - in general for Claro the design should orient to the Drupal Design System, for Gin I am not aware of any Figma file. Problem with the current state of the MR, the border has a color contrast of 1.2:1 rgb(235, 235, 235)/rgb(255, 255, 255) in Claro and Gin which is not in line with WCAG 2.2 SC1.4.11.
claro

gin

For Claro the border color should be var(--input-border-color) and on hover var(--input--hover-border-color), the border should be solid and the size var(--input-border-size). The filter field in Claro has a height of 48px (the min-height property for that is calc(((var(--input-padding-vertical) + var(--input-border-size)) * 2) + var(--input-line-height))).
For Gin the border color should be var(--gin-border-color-form-element) and on hover var(--gin-color-text) (checked the filter field on admin/content for the variable on hover), the border should be solid, the size is 1px, and the corners should be rounded.
The filter field in Gin has a height of 40px (the min-height property has calc(var(--input-padding-vertical) * 2 + var(--input-line-height)). There might be more styling details for Claro and Gin to mind, the variables provided for Gin are only for the light mode, they might vary for the dark mode.

2) The input field is missing a label (WCAG 2.2 SC 3.3.2)

3) The filter field is missing an outline when being in focus (WCAG 2.2. SC 2.4.7 & SC 1.4.11)

4) If you are entering a term to filter for into the filter field the list underneath is immediately updated accordingly. This would happen to non-sighted users unexpectedly, which is not in line with WCAG 2.2. 3.2.2. In project browser ( 🐛 Improve the accessibility of the search field Active ) we’ve applied the following approach, we’ve added a search button (for the token module the button could be labeled Filter analogous), and the user can either press enter within the filter field or tab to the filter button and then filter. That way the user is in control.

5) If a user wants to clear the input of the filter field they have to use the back space button. If someone assumes pressing the ESC key would clear the field that closes the token dialog instead. It might be worth to consider to again apply the same approach that is used for project browser and currently proposed for the field ui ✨ Add a clear button to the fields ui Active , that way the behavior would become consistent across Core.

6)

If you click on a token in the list, it will populate the last field that had focus. With this change, the last field will become the new token filter field.

this behavior is problematic. That way a keyboard user has no way to accomplish their key task, inserting a token into a field in the background of the token dialog.

7) the hierarchical list becomes hard to read after you have filtered for a string. the treetable is already hard to comprehend in the unfiltered form, but if you enter something into the filter field (for example user), you dont have a top level element as the first element but one that is from the second or third level (the exact level is impossible to assess)

8) Looking at the treeTable problem, that reminds me to the more fundamental question, about how to proceed - there is 📌 Token UI 2.0 Active about Token UI 2.0. It is the question what would be the best approach for the Token UI going forward.

• Should there be a fundamentally different UI and all other issues postponed until a consensus is reached on Token UI 2.0?
• Should there be a fundamentally different UI but until a consensus is reached there should be smaller issues like this one improving the status quo.
• Or should we proceed in the current direction and iterate in small steps with issues like this?

Uncertain what the best approach might be. In regard of the ideation for Token UI 2.0, I’ve suggested in today’s a11y meeting to raise the topic in one of the future weekly UX meeting on friday.