🇩🇪Germany @rkoller

have you tested the state shown in the screenshot? based on the concern about the use of term varchar it looks like. but those strings in the screenshot are the old pre-MR strings. the description about the link field type for example is currently A URL or internal path, with optional link text not using the concept of varchar?

the other comment is at #3529464-40: Make menu trail behaviour in SystemMenuBlock optional →

left a comment: #3370326-78: Refine labels and descriptions for field types →

Usability review

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

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

We've agreed to the concern raised by @berdir in #72 → . Aside the concepts covered in the commerce module there are also the ones used in the physical fields module → added by @benjifisher in #73 📌 [PP1] Refine field descriptions Active . That narrowed down the potential candidates to use as examples further. In the end we've came up with the suggestion: radio frequency:

@berdir what do you think about that idea? would the new suggestion work for you or have you come up with another viable alternative? or does someone else has any thoughts or ideas in that regard? otherwise i would push the change up.

the other detail we've discussed is the overall consistency of the microcopy. while evaluating the raised concern in the commerce module it turned out that the difference between field types in core using the MR and field types in contrib module are significant.

none core related descriptions use periods at the end and or uses the term field or field type within the description, all things we've avoid.

the descriptions are missing bullet points and field groups could use help text on the second step which might be unapparent to maintainers. and in general we've tried to be educational and informative in the descriptions on the second step, and if appropriate providing examples and when best to use the particular field type.

over all we've agreed it would be a good thing to have at the very least a change record for this issue or ideally in addition to that create a follow up issue to work on a "style guide" for field types. so maintainers of contrib modules have coherent easy to find guidelines.

thank you! since you have ddev installed, do you also happen to have ngrok set up on your computer? (if not just ping me) then the easiest would simply be running the following single line in the terminal in your Sites folder. during the install process you will have to confirm one or two times with y :

mkdir drupal11 && cd drupal11 && ddev config --project-type=drupal11 --docroot=web --database=mariadb:11.8 && ddev composer create-project joachim-n/drupal-core-development-project -y && ddev composer require drush/drush && cd repos/drupal && git remote add drupal-3370326 git@git.drupal.org:issue/drupal-3370326.git && git fetch drupal-3370326 && git checkout -b '3370326-refine-field-descriptions' --track drupal-3370326/'3370326-refine-field-descriptions' && cd .. && cd .. && ddev drush si --account-name=admin --account-pass=admin -y && ddev drush pmu toolbar && ddev drush en navigation datetime_range telephone media media_library -y && ddev share

copy the address you'll see in the ngrok share dialogue, should be something like https://4056a05eb8a3.ngrok-free.app. go to the login page of that address, i'll use the example address in the following, you'll have to replace with teh current:

https://4056a05eb8a3.ngrok-free.app/user/login

enter admin/admin and then go to

https://4056a05eb8a3.ngrok-free.app/admin/structure/types/manage/article

and let the tester press the Create a new field button.

and added units to the description for the font size. an important detail, so far i've only added a numeric number and wondered why the font size got smaller even though a value of > 50 was entered. the number needs a unit like pixel or em then everything is working as expected.

Fixed the problem. It couldnt have worked to simply adding the value of the radio button to the $config_export array. instead you have to check if the radio button has selected the option for within the main element and then append main-only to the headings object and the default radio button setting was also missing from the settings.yaml in the install folder. now everything is functional. but i'll postpone the issue on the micro copy issue [#3516073 . that one changes that much in the code that also the changes within this issue become tricky to rebase i suppose. and also the radio button microcopy needs some more refinement. but the microcopy issue should be solved first.

ok MR9 is ready to review. had to hide MR6 cuz turned out previous changes prevented a rebase and fixing it locally was above my skill level so i did a fresh start and created MR9. Changes I did:

• changed the label for the setting page from skipto which might be too abstract for someone who has not installed the module nor has access to the extend page. instead of using the module name i went with Skip links, the thing the module is about.
• i've then dropped the dedicated color theme, labels and restore settings pages so there is only a single settings page left. for the color themes i'Ve dropped the option to override the hex values and moved the select to the single skipto settings page. the option to override the labels i've dropped for now. it does not make any sense to provide that level of granularity. only downside i am not sure how translations should be handled with strings not available as form elements? and the option to restore the default settings is sort of unnecessary as soon as the option for altering the labels was removed. there is no danger that the user ends up with a broken setup.
• and i've updated the help page as well.

rkoller → changed the visibility of the branch 3516073-improve-the-microcopy to hidden.

rkoller → created an issue.

thank you for the fast fix @majmunbog! i've checked out your changes and the cart is now in line with the rest of the icons, so output wise this looks good:

and one note, there is currently work happening to improve the microcopy of the "add field" dialog modal (see 📌 [PP1] Refine field descriptions Active - comment #72 📌 [PP1] Refine field descriptions Active there lead me to install commerce and noticing the icon color issue as an aside). i'll open up follow up issues in the address and commerce queues as soon as there is a consensus and issue close to being fixed. cuz it would be good to adjust the micro copy for address and commerce field types to the patterns proposed for core as well (perhaps a style guide is needed after all as an artifact of 📌 [PP1] Refine field descriptions Active )

rkoller → created an issue.

testing MR12843, the shift of the footer region is being fixed, but the problem @finnsky highlighted in #37 🐛 Admin toolbar height is not 100% since upgrading to Drupal 11.2 Active still persists and the expanded workspaces popup making the workspaces menu item button and the shortcuts menu items inaccessible while the popup is expanded. do i understand #39 🐛 Admin toolbar height is not 100% since upgrading to Drupal 11.2 Active correctly and workspaces popup covering parts of the navigation sidebar is impossible to fix at this point?

Left a comment: #3370326-71: Refine labels and descriptions for field types →

Left a comment: #3370326-71: Refine labels and descriptions for field types →

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-08-01 Active and 📌 Drupal Usability Meeting 2025-08-08 Active . Those issues will have a link to a recording of the meetings.

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

We’ve discussed the changes proposed in #70 →

Reference other content

we went with the suggestion even though referring to just content is a bit imprecise, because in the field settings you are able to select content but also configuration entities for referencing. going with something like “entity” or “component” would also be too abstract, jargony, and/or expressionless. but we moved the detail about content and configuration to the second step. we added a second bullet point to the “other” option Any content or configuration entity could be referenced - that way things are communicated. out of the scope for this issue, we also came up with one or two potential followup issues:

1. if one of the reference presets, content, taxonomy term, or user is selected, disable the Type of item to reference select.
2. Add a description for every selected Type of item to reference option, to provide some context to the user

Numeric value

we’ve kept “numeric value like quantity or price” for now. reducing it to just “numeric value” felt redundant, but with the examples it aligns with the pattern used on plain text and formatted text that provided examples as well.

Upload any type of file

we didn’t know how we ended up on Create media type with the ability to upload assets, it was sort of building on the help text on the second step of the media field type and the file upload group. So we reverted it back to the initial variant: Upload any type of files, which is using the plural of the noun file.

Store a URL, with an output text option

we’ve considered store a url(we used that on our own suggestion as well) and output text option imprecise. our new suggestion would be A URL or internal path, with optional link text that way it communicates you can either enter external or internal link and it is also communicated that you also have the option to add a link text.

made the following changes to the issue summary

• striked point 4 as outdated and added a note
• rescoped point 6, making it about the missing bottom border on the desktop view port
• added point 10, about the invisible icon @kentr raised in #22 🐛 High contrast mode needs some more refinement Active

and there is one more potential detail that could be added to the issue summary, the background color for the workspace is not displayed in forced color mode. in "regular" mode you have a green background for the workspace that is live while all the other none live workspaces have an orange background (SC1.4.1 might apply here?). in addition to that the yellow font color used on the live workspace implies that it would lead to a page but strictly speaking just an area on top of the current page is displayed.

thanks for getting some momentum back into this issue @kentr!

re #21 🐛 High contrast mode needs some more refinement Active yep in regard to point 4 i agree, good catch. just retested without the automatic dark mode and the hover looks totally fine and clearly visible to me. on the other hand the active menu item for the current site is close to invisible, but that has already an issue for the none forced color mode ( 📌 Make the active menu item visually stand out more Needs work ). so i wonder about two things, should the forced color mode with the active menu item be fixed in the aforementioned issue or within the scope of this issue? and in regard to updating the issue summary, instead of removing point 4 i wonder would it be the better choice to strike it through and leave a note. that way the references of the others points after the current point 4 wouldnt have to be updated throughout the comments?

in regard to point 6 in the issue summary. i have to admit writing up that issue was a while ago and the issue summary also got updated by other people. not sure i did point 8 back then, that was probably added afterwards by someone else? in regard to point 6, that screenshot was taken with the automatic dark mode checkbox ticked and as outlined it was about the barely visible hamburger icon AND the missing top bar border. you were unable to distinguish what is the page and what is the top bar. but looking at the site without the automatic forced color mode active the issue about distinguishing the top bar due to a not visible border is not an issue without the automatic forced color mode. or wait i was too hasty. the missing top bar border is still an issue for desktop viewports! there it is missing while it is visible for the mobile view port. maybe point 6 should be rescoped to the not visible bottom border in desktop view port and point 8 should be solely about the hamburger. that way the two images used are more appropriate? if you agree i can update both points in a follow up comment.

re #22 🐛 High contrast mode needs some more refinement Active yep i've noticed that as well now. in your example you are referring to the icon in the top bar on a user profile page but the invisible icon also applies to node edit forms. they are using the same image there as well. and the gap i am also still experiencing for the mobile view port in edge.

swirt → credited rkoller → .

rkoller → created an issue.

benjifisher → credited rkoller → .

i agree the naming of the two landmarks can be moved to a followup. uhhh and sorry there is another detail i've just noticed. if you go to admin/config/user-interface/navigation-block and enable the edit mode (and for example move one nav block there), in the rotor you see the landmark for the administrative sidebar navigation twice:

and strictly speaking it is not the actual administrative sidebar navigation but a dummy you are unable to navigate with. should that maybe moved to a follow up? cuz the contextual link buttons are also not keyboard accessible, you have to hover and access them by the mouse?

finally left a comment on the issue as well: #3266964-26: Design a UI to allow various kinds of alterations to referenced Media entities in a modal →

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-07-18 Active . The recording with a timestamp to the part addressing this issue can be found here: https://www.youtube.com/watch?v=pgAuZ781Vdg&t=2900s. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell. This meeting was the second part of our walkthrough of the user tasks entailed in the issues listed in the issue summary as well as the media module in Drupal core in general. The first part of the walkthrough was covered in 📌 Drupal Usability Meeting 2025-07-11 Active and the link to the recording is https://youtu.be/FPYyputdZzQ.

The group is in line with the proposed solution to use the contextual link pattern. Users are already familiar with them from the frontend as well as Layout Builder, so being consistent using the same icon and behavior in the context of media items is a good idea.

The only detail that might have room for improvement from our perspective is the icon choice. The pencil icon has a rather specific affordance - people are used to that kind of icon solely in the context of actually editing something. But already the options used in the image in the issue summary (detach, override, and translate) have no close affinity to the concept of “editing” - the suggestion of a download option raised #25 → is blurring the line further. So we’ve wondered if it wouldn’t be the better choice to go with a more generic icon, something like the three vertical dots icon used on the navigation top bar or a downward facing caret icon? If the decision to use a different icon for the contextual link button should be taken, the icon should be changed for media items, the frontend and Layout Builder consistently - but that choice could probably be moved to a followup.

I'll remove the needs usability review tag and set the status back to needs work (but was not completely sure what the right pick should be, active or needs work)

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

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