🇩🇪Germany @rkoller

and in regard to the labels for the landmarks referring to #63 ✨ back the ID and aria-labelled-by with JS Postponed . i completely agree to the concern @mherchel raised. in the latest iteration the landmark labels are (also see landmarks.mp4):

"administrative sidebar" navigation
"administrative top bar" complementary

that way they are clearly distinguishable from any menu in the frontend. the only worry i have, for sighted users or in the general discussion on slack, the issue queue, or forums, the navigation is addressed by either navigation or navigation sidebar / top bar or navigation top bar. having a different name/label in the aural interface for that component, screenreader users might have trouble searching for something like "administrative sidebar" in the documentation. that might be potentially confusing.

i've applied the latest changes and the landmarks look good now imho (see landmarks.mp4). and left one comment in regard to the word sidebar over on gitlab

thanks to you two for cross checking. out of curiosity when going into the "voice over utility" and there under verbosity in the speech tab, which option have you picked for the default speech verbosity? mine is set to high.

good point, i am adding SC1.4.13 as a tag per #4 🐛 Top-level menu items in the footer region are too far away from their submenu items Active

benjifisher → credited rkoller → .

benjifisher → credited rkoller → .

and one question if i take a look at https://git.drupalcode.org/project/gin/-/merge_requests/635/diffs?commit... the changes are only about altering the hex values while looking at the diff there are more: changes? https://git.drupalcode.org/project/gin/-/merge_requests/635.diff . shouldnt those two have the same set of changes?

added the before and after screenshots provided in #12 🐛 Increase the color contrast of the iconography on the status report page Active to the user interface section in the issue summary.

the_g_bomb → credited rkoller → .

the_g_bomb → credited rkoller → .

the_g_bomb → credited rkoller → .

the_g_bomb → credited rkoller → .

thanks for the MR! I've taken a look at the interface not the code, and noticed a few details:

From the points listed in the proposed resolution section the background of the warning message looks good now. thanks! The other details probably need some more work:

• in light mode the entire background color for the sidebar remains homogenous while in dark mode when edited the navigation blocks have now the lighter rgb(59,59,63) (--admin-toolbar-color-gray-050) instead of the general darker rgb(42,42,45) (--admin-toolbar-color-white) background color. I would suggest to go with the darker color (rgb(42,42,45)) for the navigation block background as well.
• another detail not listed in the issue summary yet, but from my perspective within the scope of the issue, but it could also moved to a follow up if necessary, the outline rgb(0,0,0) for the active navigation block has a too low color contrast against rgb(42,42,45). it has a color contrast of 1.5:1 but 3:1 is required.
• the plus in the add block button has a color != the accent color in use - same for the light mode while claro is using a grey color here. havent noticed that before. but it looks odd. i am not sure on what color that plus is based on, is it the same for every accent color in light mode and the same for ever accent color in dark mode? or do the colors also shif based on the chosen accent and focus color? or is it one consistent color for the plus in light and another in dark mode?

The rest of the remaining issues (current menu item, navigation block title labels, expand and collapse nav button) are already covered in other issues. And i've updated the issue summary adding the detail about the outline of the active navigation block. setting the issue back to needs work.

rkoller → created an issue.

We've continued the walkthrough we've started in the meeting last week: 📌 Drupal Usability Meeting 2025-07-11 Active . The basis of the discussion are still the set of the following four issues:

• 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active
• ✨ Allow media items to be edited in a modal when using the field widget Postponed
• ✨ Media items translate items in modal Postponed
• ✨ Override media fields from the reference field Postponed

This week covered mainly revisions, translations ( ✨ Media items translate items in modal Postponed ) , alt text as an extended special case of overriding fields ( ✨ [META] Improve workflows for image alternative text Active with special focus on comment #16 ✨ [META] Improve workflows for image alternative text Active ), the deletion of media items ( ✨ Migrate Media File Delete Contrib to Core Active ), and a contextual popup for media items ( 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active ).

p.s. i will leave a comment on 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active when the recording for this week is ready. that way we can link the two recordings there as well. since the popup issues turned into the parent for this "meta" it might be a good idea to provide the additional context in addition to the summary of our discussion.

benjifisher → credited rkoller → .

yep i agree with that. i was just confused that that old key came up again after i already successfully tested an iteration of the MR that was using the new key and approach. and now running into that error again was confusing, in particular with no trace of the old key in the code anymore. but i've set up a new fresh testing instance and there is everything working properly again with this MR (see #34) .

after pulling the latest changes i run again into the 'disable_delete_control' is not a supported key when activating the When deleting media items, also delete the associated files checkbox.

Another detail if you check both checkboxes on admin/config/media/media-settings ("Delete files from file system when deleting media entities" & "Disable user control of file deletion") and if you then delete a media item you only get " are you sure you want to delete the media item" and that this action cannot be undone. but if you confirm the deletion, in the next step the status message says one item got deleted and one associated file. that way the user is only aware about the implication that the file is also deleted after the media item and the associated file got already deleted. It is correct that with the "Disable user control of file deletion" option active not to provide the "Also delete the associated files" option on the confirmation step, but nevertheless the user should be informed that the associated file is getting deleted on the confirmation step not only after the deletion already took place..

We did a walkthrough of a set of problems outlined by the following four issues:

• 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active
• ✨ Allow media items to be edited in a modal when using the field widget Postponed
• ✨ Media items translate items in modal Postponed
• ✨ Override media fields from the reference field Postponed

The current state of the https://www.drupal.org/project/media_library_media_modify → module was the basis for our discussion, and we worked through a set of user tasks. We've highlighted the problems we've encountered along the way within the media_library_media_modify module as well as the media module in general. Other issues that were touched during the meeting:

🐛 Impossible to override a media item on a node that is not saved yet Active
🐛 The form for overriding a media item is a homogenous mix of content and meta data fields Active
🐛 on the node edit page contextmod only shows global values for media items even though some are overridden Needs review
✨ Expose triggering update of media metadata + thumbnail to end users Needs review

Due to the fact that we haven't had enough time left to finish our exploration, we will need a second round. That is also the reason why there will be no comment on any of the referenced issues yet nor have we got to any discussions how to tackle the problems we've encountered. We will get to that when we have an overview of the entire problem space.

rkoller → created an issue.

rkoller → created an issue.

If we have a big enough group we might tackle one of the "skeletons in the closet" in the issue summary for the meeting issue: ✨ Allow media items to be edited in a modal when using the field widget Postponed . Have prepared a few tasks covering many parts of the media module in general as well as https://www.drupal.org/project/media_library_media_modify → in particular (that module contains the code of the aforementioned issue).and along the way we could also cover 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active which also has the needs usability review tag and has the needs review status for a few weeks now. and finally we could tackle overriding alt text/decorational images covered in ✨ Override media fields from the reference field Postponed (that issue is also referenced in 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active ). Everything is interconnected and has to be looked at as a whole.

as i'Ve said all the combinations are already listed in the google sheet.

focus:
https://docs.google.com/spreadsheets/d/1won35PxhRFexJYE8FmZ4DCNTo7xEAxC8...

accent colors:
https://docs.google.com/spreadsheets/d/1won35PxhRFexJYE8FmZ4DCNTo7xEAxC8... (and the components tab contains all the components from the rest of the issues)

and it is a bit more complex since it is not just a single background color but several for light and several for dark mode plus the colors are semi transparent and for the focus outline you have two colors due to the fact how the focus is currently built in gin.

Could you please move it back to gin ( i dont have the permissions to move issues in between projects). this issue is specific about gin and some of the interface components only available in gin. as mentioned in the proposed resolution there is also 🐛 [meta] Some interface components don’t meet the minimum target size Active for claro and core in general.

? this issue is about adding color contrast checks for the color chosen in the custom color widget (against all relevant colors depending if the light or dark mode is chosen)

and what are those color combinations of yours refer to? focus colors accents colors? all the combinations are covered in the google sheets.

We really need to fix the accent colors. People can make choices with bad color contrast, but Drupal should not be presenting bad defaults to admins. We can't assume they are testing for color contrast (if we aren't).

agreed... and that is the reason why there is also ✨ Add color contrast checks to custom focus and accent color dialogs Active so ensure that custom picked colors are checked for color contrast in the future as well. to prevent that custom focus and accent colors have a too low color contrast for the chosen color theme (light or dark)

that button is strictly speaking in the navigation module. i posted it in the gin queue as well due to the fact that there is a dark and light mode and navigation in core only has a light mode so far. that was the reasoning behind opening an issue in gin as well.

hm just rechecked, i "thought" when we tested and compared back then it was only happening in gin but it looks like the problems apply to core as well. so the problems arent due to gin doing something different than claro.

xjm → credited rkoller → .

benjifisher → credited rkoller → .

xjm → credited rkoller → .

hm took the time to install an old drupal 10 site and so being able to install media library media modify 1.x. that way i was able to apply the patch with composer patches. but on the node edit page still the global field value instead of the overridden one is shown. unfortunately the patch isnt fixing the problem outlined in the issue summary. :( i am setting the issue back to needs work.

To add to the discussion. There might be an approach to solve the fundamental problem of how to handle hotkeys, aka keyboard shortcuts in Drupal. Instead of solving that problem just in the context of Experience Builder, why not solve things consistently for core and contrib, in general - that approach would be more sustainable, beneficial, and future proof. Recent discussions in the accessibility track for Drupal CMS lead to ✨ Add an API for hotkeys to Drupal core Active . That proposal would provide a solid foundation for hotkey management in core and contrib, which is also the reason why the proposed API probably would not work as a contrib module. People new to Drupal could potentially be unaware that they have to install the module, and it would be rather challenging to establish a consistent, well-adopted pattern for the entire contrib space, plus it would be pretty unusual for core to integrate with a module in contrib.
The other option to mention might help to improve how keyboard users are able to navigate more easily on pages in the Drupal front and backend. https://www.drupal.org/project/skipto → integrates https://skipto-landmarks-headings.github.io/page-script-5/ into Drupal. It also exposes the page’s landmark regions and headings to sighted users by making them keyboard accessible (WCAG2.2 SC2.4.1). The SkipTo module is currently a work in progress, with no stable release yet. In interplay with well-thought-out and structured landmark regions, keyboard users would be able to navigate more flawlessly between the main regions of complex pages such as Experience Builder.
Those two suggestions might provide a solid foundation for keyboard usage and could be expanded and interwoven with approaches like the roving tabindex ( #7 → ) and others, suggested on this issue. Another good resource to mention for inspiration is: https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/

rkoller → created an issue.

rkoller → created an issue.

@katannshaw, @mgifford, @the_g_bomb, and myself discussed the matter back and forth for the last couple of days to weeks about how to tackle and, in particular, scope the problem at hand.

In summary we agree with most of the problems raised in this issue, but from our point of view it would be a reasonable step to chop the issue up, create an overarching meta issue, and have this issue rescoped and create a few additional follow up child issues alongside.

In regard to scope, it also has to be noted, during our testing it turned out, it is not only the file field affected, but also the image field, the formatted long text field and the formatted long text with summary field that are missing a required attribute.

In the following we would suggest three general steps how to chop up the problem - at least one of the steps might be subdivided even further.

1. Add the required attribute
We would advise to stay consistent with the field api in Core. Instead of going with aria-required=“true” for the input elements for file and image fields, as suggested in #22 → , better go with required=“required” that is used on all the other input elements. Problem is for div elements (formatted long & formatted long with summary) that approach probably won’t work, there the aria-required=“true” might be required.

In regard to scope it might make sense to rescope this issue and make it solely about adding the required=“required” attribute to the image and file field and open another issue for adding aria-required=“true” to the formatted long & formatted long with summary fields.

Next, the following two issues should be postponed until step one is fixed and all field types in Core use a required attribute.

2. Improve the asterisks in the aural interface
In the aural interface for for example VoiceOver the announced text for a field with the label plain text currently is plain text *, required invalid data, edit text, main.

We are in line with #16 that the asterisk is potentially confusing for screen reader users. But instead of adding a visually-hidden “required” text snippet to the asterisk we would simply exclude and hide the asterisk from the aural interface. With the required attribute in place with step 1 completed the asterisk is now redundant information. →

The fix could be worked on in the already existing 🐛 Drupal should not use full CSS required marker in forms according to WCAG 2.0 Needs work . As the proposed resolution, wrap the asterisk in a span adding aria-hidden=“true” so it is hidden from screen reader users for all available field types while still visible for sighted users.

3. Improve how required fields are communicated in general
As previously stated, required fields have a few inherent problems - Adam Silver outlined those in: https://adamsilver.io/blog/how-to-highlight-required-and-optional-form-fields/

Our suggestion would be to open another follow up child issue, that will probably require a lot of discussions and testing with actual users, but as a discussion starter the following approach could be suggested.

In node edit forms, based on the number of required and optional fields, the group of fields that is smaller in number should get the (required) or (optional) suffix appended to the corresponding field labels. That way it would be clearly communicated what the requirements for that node edit form are - the automatic approach. Another option might be to add a vertical tab to the edit page for a content type and provide the user options to set the to be discussed behavior of the node edit form in regard to required and options fields.

The following video https://www.youtube.com/watch?v=mvIaUHr2i5U covers most aspects of that discussion. It includes the aspects of the article Adam Silver posted, and discusses https://www.nngroup.com/articles/required-fields/ as well as https://www.deque.com/blog/anatomy-of-accessible-forms-required-form-fields/. The arguments in the nngroup article argue for example against 🐛 Forms with required fields marked by asterisk do not have text explaining what the asterisk means Needs work a related issue that was raised during the discussions for this issue - providing some description for the asterisks is considered rather pointless according to the nngroup, since most users don’t read the instructions at the top of a form.

But looking at all those resources shows two things, that the current state of how required fields are handled in Drupal has room for improvement and that there might be no one-for-all solution. Either way the issue for step three will require a lot of discussion and user testing.

the first issue i've noticed is that there are no focus outlines shown in safari. but the css is there. the focus outline is 2px dotted transparent and the focus box shadow then with the claro focus green. (other interface components in safari using the same properties are showing the outline, only the buttons in bpmn are not) . firefox and edge show the focus outline properly

for the rest i have to test some more (and i can also discuss the detail about buttons in tomorrows a11y track meeting for drupal cms as well).

jurgenhaas → credited rkoller → .

I've tested the steps to reproduce against 2.x-dev again. the problem still applies. changing the version to 2.x-dev. in regard to the patch. would it be possible to move it to a MR and does the changes apply to 2.x-dev as well or are there additional changes necessary?

i've restored the removed issue summary. why it got removed? next i will see if the issue still applies, and after that i'll take a look at the patch.

the_g_bomb → credited rkoller → .

the_g_bomb → credited rkoller → .

added one additional aspect/problem and a question i forgot to the issue summary

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

alexpott → credited rkoller → .

benjifisher → credited rkoller → .

oh interesting, thanks for investigating! i am not a developer therefore i dont feel qualified to make a recommendations about the approach how to fix a certain problem :/ the only thing i can say, it at least sounds reasonable staying consistent and choose the same approach claro uses.

argh apologies, missed the conflict line :( was only focus on the version number. thanks for the explanation!

hm the MR is setting dealerdirect/phpcodesniffer-composer-installer to 1.1.0, but the actual fix in https://github.com/PHPCSStandards/composer-installer/pull/245 that got merged is targeted for the to be released 1.1.1?

rkoller → created an issue.

updated the issue summary and added the detail about preventing conflicts with AT keys raised by @mgifford in #2 ✨ Add an API for hotkeys to Drupal core Active

rkoller → created an issue.

rkoller → created an issue.

thank you! I've updated the issue summary to reflect the ui changes. and as said in the issue summary the contrast of 3.1:1 is meeting the requirement. so looks all good now.

thanks for the MR! i agree #949494 has a high enough contrast, but problem is that this color is not one of the available color variations for claro. the list of available variables is:

  /* Gray variations. */
  --color-gray: #232429;
  --color-gray-900: #393a3f;
  --color-gray-800: #55565b;
  --color-gray-700: #75767b;
  --color-gray-600: #828388;
  --color-gray-500: #919297;
  --color-gray-400: #adaeb3;
  --color-gray-300: #c1c2c7;
  --color-gray-200: #d3d4d9;
  --color-gray-100: #dedfe4;
  --color-gray-050: #f3f4f9;
  --color-gray-025: #f9faff;

I've created 🐛 Top-level menu items in the footer region are too far away from their submenu items Active and added it to "other" for now - none of the other categories is a good fit for it. and i've also added ✨ back the ID and aria-labelled-by with JS Postponed

rkoller → created an issue.

Thank you for working on the issue! I've tested MR8, two observations:

1) It looks like the set radio buttons has no effect at all. no matter if i select main-only or full-dom, each time all the headings of the entire dom are displayed in skipto

2) the label for the first radio button (Only within the <main> element) is broken, main is being hidden and you only see

Only within the
element

probably no need to use angle brackets. will have to think about the wording

that was a good idea! completely overlooked that possibility, i've tested now on 3.x-dev and i ran into the same issue. so the problem is out of the scope of this issue. probably a bug with voiceover and edge?

Thanks for the initial work! I've taken a look at MR7 and i am not sure if using javascript for adding a suffix is the right solution here. i guess the suffix itself could be solveable simply with plain php and the field api. by adding something like

'#field_suffix' => $this->t('percent', [], ['context' => 'skipto']),

to

$form['buttonSettings']['positionLeft'] = [

would solve things (except the wrong label for the number field, but that has to be fixed in 🐛 Improve the microcopy on the settings page Active - still havent had the capacity to work on it). imho it is always preferable to go with to write something out instead of using a symbol like % for screenreader users. but talking of screenreader users, i've tested the solution in MR7 as well as my suggested one and neither is being announced when the numbers input gets into focus. I gotta do some more research if that is maybe a shortcoming in core in general. I'll set the issue back to NW.

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.