🇩🇪Germany @rkoller

one immediate reaction/thought, when i went to admin/config/development/project_browser, it feels sort of wrong to have a form element, the clear storage fieldset, right after a save configuration button (a form sort of ends with the save configuration button - the appearance page also sort of breaks with that paradigm in a different but similar way). one thing we tried to mind during ux meetings was a page shouldnt cover too many different topics and tasks. at the moment you are able to enable the experimental setting, then you have the setting for enabling and disabling the source types which the save configuration button refers to, and then the newly introduced clear storage button wrapped in a fieldset. i would rather tend to suggest to have at least two local tasks, one for the checkbox and the table and the other for the clearing the storage fieldset?

rkoller → created an issue.

rkoller → created an issue.

Sorry for the late reply, your comment slipped through. i haven’t heard of the accesskey concept before. but i have taken a look now at the issue summary as well as the corresponding MDN page. the browser support looks also good: https://caniuse.com/?search=accesskey. from my understanding the accesskeys look like some sort of unification and an at least easier way to add a hotkey functionality to a page/site?
I only see two (and a half) problems with that approach. I’ve tried the example provided on https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/acce... (https://codepen.io/ermarus/full/YzmbxPg) and it has literally no effect at all on macOS (I’ve tried Safari and Firefox). And one problem that struck my eye for macOS, accesskeys uses the same modifier keys (control option) voiceover uses, so your admin toolbar example collides with the hotkey to start announcing the entire page with voiceover active. :/ (Dequeue University provides cheatsheets for the most common screenreaders: https://dequeuniversity.com/screenreaders/). And finally, even though you have given fixed hotkey, the modifier keys differ between operating systems and browsers. If someone has more than one computer and browser they are regularly using the cognitive load is high figuring out the correct set of modifier key for the current context (browser and operating system).

Another point to consider, for admin_toolbar you went with the accesskey approach, while the tour module went with adding an eventlistener ✨ Add a hotkey to start a tour Fixed . For one you might end up with two or three different approaches across contrib adding hotkeys to the drupal admin UI, plus it is not sure that the choices contrib modules make for their hotkey don’t collide with of the choices the other modules?

So I wonder if, as a long term plan, the following approach would make sense. In the explorations during the competitive analysis for the a11y track for Drupal CMS, we’ve learned about the approach Joomla takes for hotkeys. You have a keyboard shortcut to open a dialog modal with a cheat sheet that contains the list of available shortcuts for the admin interface.

So our idea (nothing fully fledged out nor planneed) was to have a set of core shortcuts as well as to provide the opportunity for contrib modules to register their own hotkey or even the user to assign custom ones. that way you would have a central place/api for managing hotkeys for the admin ui. That way you would avoid hotkey collissions, you could have/define a consistent modifier key across browsers and operating systems, plus the list of registered hotkeys would be available via a cheatsheet. That would be my preferred long term solution.

For the short term, i would rather lean towards the approach the coffee and the tour modules have taken in regards of the modifier key - coffee uses alt d and tour alt t, aka a consistent single modifier key. cuz implementation wise the addition of the hotkey for the tour module was quick and easy for example via the eventlistener approach: https://git.drupalcode.org/project/tour/-/merge_requests/67.diff or would it be possible to change the modifier keys for the accesskey approach to a consistent one? cuz implementation wise accesskeys are even faster to add it looks like: https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/38.diff

rkoller → created an issue.

sounds reasonable, then i'll open a followup issue and postpone it until this one is in.

i think that would be a reasonable addition to make sure that this problem isnt reintroduced and slips in at one point in the future by accident.

nice you were able to dig up the issue that was causing the problem! I can confirm the focus outline is not obscured anymore in the first row neither. thank you!
i went ahead and manually commented out the four lines listed in the corresponding core commit https://git.drupalcode.org/project/drupal/-/commit/a11036104f from the issue you've reference ✨ Add vertical-align: top as default for table cells Active . Just wanted to test if it has any negative effect if those changes get temporarily rolled back. The focus outline is still not getting obscured again for the first row. So i think this MR looks good to go.

oh and the link size was bigger? it looked bigger but the last time i've checked the font sizes i'Ve found for the different columns were consistent (no idea why and where i've looked lol). but looks good after your last changes. with the typography slightly bigger it would be also easier to read for everyone. it would be ok from my end to keep it and lets see what maintainers think about it.

In regards of the overlap, i've recorded a short video, on the left is the latest safari 18.1 in the middle the latest version of firefox and on the right the latest version of edge, happens in each of the three browsers for me. and i am on macos sonoma 14.7.1. you are on another operating system perhaps (which might explain the different display)?

awesome thank you! only minor details. i've tested on an instance that has the composer install deactivated. in that context i would have two questions. would it make sense to make the dialog modal opened by the view commands button the same width like for the detail page? or will that dialog modal be removed anyway? and the other detail for the view commands button, i would still add the aria-haspopup attribute there as well not sure if it makes sense to open a new issue for a single line and if it wouldnt be the better choice to add it within this issue as well. .

i've then retested another time and opened and closed a details dialog modal several times in a row, by the close button as well as by pressing the esc key. all fine. and the max-width of 80rem is also good. also tested narrowing down the browser window to a mobile viewport and enlarging it again afterwards, all behaving well and as expected (tested in safari, firefox and edge) .

there is only one detail i wanted to note and one issue i ran into but am unable to reproduce. by default the first focusable element of the dialogue modals main content is getting into focus. problem is some projects dont have any links in their description so the first element in focus is the view commands/queue/add to batch button. so screenreader users without the visual context "might" miss the description, plus the first focusable element would be the install or the install instructions. usualy that should be the last step after a user has informed themeselves and got convinced the module is the one they wanted to test or have - but from my perspective this is not necessarily about moving the details page into a dialogue modal but more about how the details page is structured so i would vote for taggling that detail in a dedicated followup issue cuz the details page needs some work anyway imho.

the other detail was related to the problem i'Ve outlined before and i went ahead and simply tried VO-a for announcing the entire pagesequentially. problem was, voiceover after finishing the content for the first time jumped right outside of the dialogue modal and announced, i "think" it was the categories from three different modules, and then jumped right back into the dialog modal again. not reproducible so far so i wouldnt hold back the issue because of that.

so from my point of view the only questions left to answer within this issue are are about the view commands dialogue modal. should those details dealt within this issue or moved to a followup? aside that everything looks good to go from my perspective if there arent any objections on the code end.

one detail i forgot, whichmight be reasonable to add within the scope of this issue, it would be good to add an aria-haspopup="dialog" attribute to the link opening the dialog modal on each of the module cards (see haspopup.mp4 - added that just via the safari web inspector for that single element)

But there is one significant problem to consider in regard the idea of providing some sort of post apply modal as suggested in #3 ✨ Allow a project to suggest other projects, present in UI Active . If you add and install a single module that post apply modal pattern works, but how do you handle the case of 2 to x number of modules installed at once, which is the likely case with the batch functionality being the only way to install modules - having a chain of post apply modals in a row seems suboptimal.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

The main problem in this issue is that there is no component for a toggle button with a pressed and not pressed state yet. in the drupal design system the toggle is only about a visual "switch" (if that is the right term in english). i remembered a discussion we had on the ux channel. in the this comment and the following i've listed a few aspects: https://drupal.slack.com/archives/C1AFW2ZPD/p1704456082112179?thread_ts=... but i guess there need to happen some design work still. and that problem applies to more places in the drupal admin ui not only the list/grid toggle in project browser. one preliminary solution might be to go with a similar design like used in gin, but avoid those extremely rounded corners.

but from my perspective visually it als still not that clear that, in this case grid is the button that is in a pressed state.

hm not sure if this issue is ready for rtbc. i read through the entire issue. the feedback from #6 ✨ Improve iconography usability by adding a legend Needs work in regards of the microcopy for the label by drumm wasnt really addressed , actively maintained is still sort of being used. #29 ✨ Improve iconography usability by adding a legend Needs work i cant recheck right now cuz i am unable to see any search results, but since this issue adds the second icon on the card if it applies i meanwhile think it is not out of the scope for this issue. and #36 ✨ Improve iconography usability by adding a legend Needs work isnt answered yet either about the general question of proximity. and now looking at it i wonder if the labels for those legends should be also hidden from screenreader users? they have the those legends on every card it applies to. in the context of the legend it provides no help in particular because the icons are tagged as decorational?

In the following an incomplete list of components that might potentially need some work. it has to first checked if there is already an existing issue, if that is case case add this issue as the parent, otherwise create a new issue and add this issue as the parent as well. I add the component and the component in the drupal design syste i would suggest project browser should orient to. i first write the component in question project browser and then the suitaable section in the drupal design system it might orient to, sometimes i will add a comment in parenthesis)

Browse page:

Fieldset wrapping search field and filter section - fieldset/details (there is no component that combines local items with a fieldset)
Filter section - fieldset/details (fieldsets are usually with a plain white background - see the filter section on admin/content for example)
Sort
Sort by - Select (selects have a white background and the selected option while the select list is expanded is highlighted in dark blue, the dark border on hover "might" be broader)
module card - card ( in detail not completely applicable but the module card could at least orient in regard of the card border and padding)
Items per page - Select (The select is unstyled at the moment and is not meeting the minimum target size criterion of 24px by 24px)
Pager - Pager (only two questions shouldnt be there a first and previous link as well if the first page is active? at least it is the case in the design system? and the other question does the pattern exist for the period if there are more pages that numbers visible?)

Details page:

not sure if there is a component to add at this point?

I've added the new design system meta as the new parent and changed the old parent to related issue

rkoller → created an issue.

i am adding this issue as related since it is also about makeing the information more compact and condensed. this issue here is about the card view the linked issue about the list view of the browse page.

in regards of aesthetics two details. first, i am unable to test the current state since it is broken or at least the buttons are not showing anymore at the moment, but in my previous tests i'Ve noticed a regression that is illustrated in #15 📌 Consider adding Apply and Clear buttons to Categories dropdown Active . we ve agreed on a previous issue that the user should always see only the half of the last visible option if there are more options than vertical available space. that way the user directly knows the list is scrollable. in the screenshot in #15 you see the last visible option fully visible instead. that way it is not directly apparent that the list is visible.

and i wonder if it would make sense to align the background color of that box/bar that contains those two buttons with the dark of the bulk action bar? to visualize that this is a button bar and not part of the multi select list anymore, to make it visualy distinguished from the actual list?

and in regards of the keyboard navigation. would it make sense to move the details about the keyboard navigation into 📌 Improve keyboard navigation for categories dropdown Active if the rest of this issue is ready?

One other aspect i've completely forgot about testing and mentioning is the support of home and end keys as well as the support of the page up and page down keys. both work when the multi select is expanded and in focus. but the detail that is not working is, that the checkbox focus remains on the access control checkbox. confusing for a keyboard user. in particular if you press the end key after the multi select got expanded and then you press the up key. you dont see any focus outline until the first checkbox is reached. and if you then press arrow down the focus outline moves and follows the keyboard input. the point about home and end buttons was raised by @drupa11y.

thank you! i'Ve just realized right now how many issues when testing stemmed from project browser immediately querying the d.o servers after a second or two of not typing. now requiring the press or click of the return key make things way more controllable and also less overwhelming.

rkoller → created an issue.

hm i am still in doubt about this change. visually it looks ok with the recent changes on the MR. but my problem is the spatial separation. within the filter field set you have the select list fields where you are able to set those two filter criterias in question. the labels used in the filter filed set differ from the wording on the legend (for example "security advisory coverage" against "covered by the drupal security team"). and then you have those icons on the module cards without a label. visually the user has to jump inbetween those three positions the first few times. and in the long run that legend becomes obsolete for people familiar with the information the two icons convey. and the browse page is already packed with information.

rkoller → created an issue.

Two or three weeks ago I've done an impromptu user test, asking attendees of the Drupal Dojo Austin about their first impression about certain parts of Project Browsers browser page. For the reference, that nights attendees were @rocketeerbkw and @cutehair. On the browse page both considered the word "queue" challenging, there was also the uncertainty in one initial reaction what queue actually means and implies. But they've also considered the pattern of using a regular button for adding a module to the queue not that helpful.
After explaining the functionality behind, as well as pointing to the planned bulk action component outlined in 📌 Change UI for the install queue to match bulk operations Active , their feeling was a checkbox would be the more suitable and familiar interface pattern for adding something to the batch. The currently used "toggle" button functionality is not that apparent and it was also noted that both button states only differ by their button labels, there are no other visual queues, so the user has to actually read to distinguish which modules have been added to the batch yet. The cognitive load is sort of high that way.
The suggestion was to add a "stylized" checkbox to the button, so modules not added and installed would have "add to batch" as the button label (picking up the suggestion from #19) with an unticked checkbox, while a pressed button would have the same button label "add to batch" but a ticked checkbox. That way sighted users dont have to distinguish between uniform looking buttons that differ just based on their button label . Same for screenreader users where the aural interface does not really announces the actual button state, there is always the uncertainty for someone without the visual context "am i in the unqueued state and by pressing the button i will move the module into the queued state or is it the other way around?". ( a similar problem is illustrated by leonie watson with the example of the light and dark theme toggle button over here https://youtu.be/OUDV1gqs9GA?t=3220)
if you make the button a switch button with a fixed label of for example "add to batch" in for example voiceover a screenreader user gets the announcement "add to batch" for the not pressed button and "add to batch selected" for the pressed button. that way the state is crystal clear there as well. and for both the rest of the necessary details could be communicated on the bulk action component.

i've added the issue to the shortlist yesterday and maybe we find time already today discussing it. But I did some more testing and the setup i've did yesterday was missing an important aspect - it matters who creates the issue. The matter is still puzzling, well time zones in general, but at least things became a bit more clear now. The revised setup:

admin/config/regional/settings has New York as the default time zone
user/1/edit (rkoller) has Berlin as the time zone in the local settings
user/2/Edit (admin) has New York as the default time in the local settings
+2 Saturday 13:00 is the relative default value set on the date field

No MR applied

Node creator rkoller - berlin

Node edit form:
11/23/2024 02:00:00pm

Node:
Sat, 23 Nov 2024 - 14:00 (rkoller berlin)
Sat, 23 Nov 2024 - 08:00 (admin new york)

Node creator admin - new york

Node edit form:
11/23/2024 08:00:00am

Node:
Sat, 23 Nov 2024 - 14:00 (rkoller berlin)
Sat, 23 Nov 2024 - 08:00 (admin new york)

MR applied

node creator rkoller - berlin

Node edit form:
11/23/2024 01:00:00pm

Node:
Sat, 23 Nov 2024 - 13:00 (rkoller berlin)
Sat, 23 Nov 2024 - 07:00 (admin new york)

node creator admin - new york

Node edit form:
11/23/2024 01:00:00pm

Node:
Sat, 23 Nov 2024 - 19:00 (rkoller berlin)
Sat, 23 Nov 2024 - 13:00 (admin new york)

i've added the issue to the shortlist yesterday and maybe we find time already today discussing it. But I did some more testing and the setup i've did yesterday was missing an important aspect - it matters who creates the issue. The matter is still puzzling, well time zones in general, but at least things became a bit more clear now. The revised setup:

admin/config/regional/settings has New York as the default time zone
user/1/edit (rkoller) has Berlin as the time zone in the local settings
user/2/Edit (admin) has New York as the default time in the local settings
+2 Saturday 13:00 is the relative default value set on the date field

No MR applied

Node creator rkoller - berlin

Node edit form:
11/23/2024 02:00:00pm

Node:
Sat, 23 Nov 2024 - 14:00 (rkoller berlin)
Sat, 23 Nov 2024 - 08:00 (admin new york)

Node creator admin - new york

Node edit form:
11/23/2024 08:00:00am

Node:
Sat, 23 Nov 2024 - 14:00 (rkoller berlin)
Sat, 23 Nov 2024 - 08:00 (admin new york)

MR applied

node creator rkoller - berlin

Node edit form:
11/23/2024 01:00:00pm

Node:
Sat, 23 Nov 2024 - 13:00 (rkoller berlin)
Sat, 23 Nov 2024 - 07:00 (admin new york)

node creator admin - new york

Node edit form:
11/23/2024 01:00:00pm

Node:
Sat, 23 Nov 2024 - 19:00 (rkoller berlin)
Sat, 23 Nov 2024 - 13:00 (admin new york)

I've stumbled across 🐛 Better handling of timezones for relative default date + times Active and the issue could definitely need some discussion - the current state is highly confusing. @alexpott agreed on the issue that the issue could need some discussion in a group context at this point.

@chrisfromredfin made a good point in a discussion on slack:

In this way, "queue" is really quite a misnomer, you're really "adding to batch") but queue/batch are not user-friendly words anyway

I agree that queue/batch are both challenging and abstract terms, but for me batch is less abstract as a none native english speaker (it would be easier to explain to someone else), plus i always prefer to use precise denomination. so why not instead of going with Add to queue go with Add to batch instead?

In regard of #18 📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed - there is a child issue to this one ( 📌 Change UI for the install queue to match bulk operations Active } that is about adding a bulk action bar at the bottom of the page like you have on /admin/content. that bar will always be in the visible viewport (if it behaves like the one on the content page) and within the action select list the default action is shown. there you could basically use the button labels that were used before the queue button was introduced and that way it would be clear what will actually happen ( my suggested actions on the issue are "add and install" and "add"). there might be only the person who is using project browser for the first time or someone who only wants to install a single module (like the case you've described in #18 @tonypaulbarker), for those there might be "friction" with the current plan until the first module is added. definitely a valid concern.

i've raised my concern i had with the current direction of first removing the drop button, moving to an add and install button solution and now moving even one step further and queuing several module to add and install. definitely convenient and streamlined for a big group of people. but that approach has one downside. from my personal perspective i have always a really really hard time figuring out after a module is installed where i am able to find configuration pages for that very module. the more module install at once it multiplies the struggle and cognitive load exponentially for me. that is the reason and rule of thumb, i also add several contrib modules but i never ever install more than one module at once. that is also the reason i am not a fan of a prebuild setup like drupal_cms where you not only have to figure out where all the configuration pages for all the installed modules are but also how they are configured. intimidating. and i suppose there are more people similar like me with similar concerns. but i think i might have an idea to to tackle the problem, without the need of re introducing drop buttons and complicate the entire flow further. i would suggest to have more actions in the bulk action list:

at the moment there is only the "add and install" action i suppose, but i would also an "add" action .with the add action people are able to select a set of modules upfront and then only composer require them . afterwards it is completely up to their preference how to proceed. and that way you would also have the flexibility. for example if you already know a certain set of module and you are familiar with their configuration you could also still choose the default "add and install".

Yes thank you removing the disabled attribute made the installed button keyboard accessible. the only thing i would still add is the not-allowed cursor so for keyboard users it is signified it is not clickable in case they try. cuz with aria-disabled one can click but it has no effect.

In regards of the styling of the button. the styling of the button in your first screenshot looks not in line with the drupal design system. the styling in the second link goes in the direction of the action link i've suggested. problem, the label (installed) has a too low color contrast. the grey has a color conrast of ~2.5:1, but bold typography should have at least 3:1. and the checkmark also looks not in line with the drupal design system. i guess if the button label would use the color used on the example here: https://www.figma.com/design/OqWgzAluHtsOd5uwm1lubFeH/💧-Drupal-Design-system?node-id=5315-242&node-type=frame&t=gS098wgWgrUhycl8-0 (stylguide -> action link -> lists and spacing ) as well as the checkmark it might look more consistent with claro? (but not sure where the svg for that checkmark is located)

might be also a more than suitable issue to discuss on fridays ux meetings imho. shall i add it to the shortlist?

From a users perspective this is super confusing. i've tested after reading #25 🐛 Better handling of timezones for relative default date + times Active . My setup:

admin/config/regional/settings has New York as the default time zone
user/1/edit has Berlin as the time zone in the local settings
user/2/Edit has New York as the default time in the local settings
+1 Saturday 13:00 is the relative default value set on the date field

Without the MR on the node edit form (creator user 1) :
11/16/2024 2pm (user 1 with berlin)
11/16/2024 8am (user 2 with new york)

with the MR on the node edit form (creator user 1)
11/16/2024 1pm (user 1 with berlin)
11/16/2024 7am (user 2 with new york)

I receive the same set of dates and times if i create the node with user 2 same as if i create the field and set the relative date with user 2. that leaves me as the user puzzled and completely in lack of situational awareness about what the actual point of reference is when i am setting the relative default value on the field? my main assumption would have been that the point of reference date and time would be new york, the sites timezone. but with +1 saturday 13:00 against new york i wouldnt expected to get 11/16/2024 7am (with MR) 11/16/2024 8am (without MR); for user 2 i would have expected those time and for user 1 i would have expected 7pm (with MR) and 8pm (without MR) but not the other way around?

I think one of the most important things here is providing the actual point of reference for the calculations on the description of the "relative default value" field on the field settings to provide some situational awareness to the user. at the moment the description only provides

Describe a time by reference to the current day, like '+90 days' (90 days from the day the field is created) or '+1 Saturday' (the next Saturday). See strtotime for more details.

there is no clue about the point of reference the calculations are based on? personally, as a user, i am completely lost here and feel highly confused.

well i think i know what we've both missed. i suppose you are testing with either firefox, chrome, edge or something alike, aren't you? ;) the videos i've done in #20 📌 Improve keyboard navigation for categories dropdown Active were created in safari (which is the default browser i use on macos). i've created a comparison video (comparison.mp4) with safari 18.1 on the left, firefox 132.0.2 in the middle and edge 130.0.2849.80 on the right on macos 14.7.1

so based on the points in #20 📌 Improve keyboard navigation for categories dropdown Active i went through everything again,and tagged the given points either "working" (either fixed or a none issue) or NW (needs work).

voiceover switched off
1. safari: working firefox: working edge: working
2. safari: working firefox: working edge: working
3. safari: NW firefox: NW edge: NW

voiceover switched on
1&2. safari: working firefox: working edge: working
3. safari: working firefox: working edge: working
4. safari: NW firefox: working edge: working
5. safari: NW firefox: NW edge: NW

Thank you for the MR! the target sizes look good. i've just checked with the bookmarklet by steven falkner that is linked in the issue summary. the only "minor" nitpick, the upper border of focus outline for the first two elements is hidden in part underneath the table header:

In regards of the font size. i am not sure if it would be ok for the maintainers to extend the scope. from my perspective it would be ok. i agree that the current font size is definitely smallish. but question is if that kind of styling falls into the changes going in version 2.x? i am not the person to decide.
and one interesting tidbit even though the typography in all three columns has the same font size (16px) it seems like the actual tokens in the second column have somehow a bigger font size :D

i'll set the issue back to needs work because of the focus outline which ideally should not be covered/obscured by anything. hope that is technically possible?

At first thanks to @kasey_mk for all the work on the issue and @the_g_bomb for moving the patch in #11 📌 Expose coordinates as fields for accessibility Needs review into merge request. I've tested MR42, a few thoughts and observations:

In general some work might be needed stylingwise. I've tested on 11.x and focal_point 2.x using Safari 18.1. On a desktop viewport the image fieldset looks like that:

While on a mobile viewport there is no linewrapping and the entire description is getting crammed into a single line:

In general I love the idea of progressive disclosure showing Click and drag the indicator to set the focus of this image, or double-click the indicator for a text field to change the focal point offsets. only when javascript is available. but i wonder when no javascript is available and the description is hidden why the white cross of the focal point is still shown? wouldnt it make sense to hide it as well?

in regard of the behavior for screenreader users. first i consider it confusing that the focal point field is placed in different positions depending on if javascript is available or not. Without Javascript it is at the end of the fieldset

While with javascript available it is at the first position in the fieldset:

It feels also rather odd and confusing that the focal point field is first hidden and only shown when it gets into keyboard focus. In that case it is not a progressive disclosure that first a criterion has to be met but the user just has to tab until they reach the focal point field. if you have a sighted keyboard user who is reading "Click and drag the indicator to set the focus of this image, or double-click the indicator for a text field to change the focal point offsets." there is no indication that the feature is keyboard accessible nor that the focal field will get unhidden when it gets into focus. the description is only about mouse interaction. So i wonder if it wouldnt be the better choice to make the focal point field visible all the time for everyone in every context?

In regards of the syntax used on the focal point field, having something like 50,50 along with instructions like "Specify the focus of this image in the form "leftoffset,topoffset" where offsets are in percents. Ex: 25,75 " is sort of challenging. would it be an idea, instead of having one input text field, having two input number fields. that way the keyboard user would be able to either type in the number or use the up and down arrow key changing the value, plus a failsafe could be added only allowing integer values with a minimum value of 1 and a maximum value of 100?

ah yep can confirm that, just spun up an instance of drupal 10.3.8 and the preview button works as expected there as well. should the issue set back to RTBC?

I agree with @chrisfromredfin the currently vertically stacked legend takes way too much space. about the idea in #28 ✨ Improve iconography usability by adding a legend Needs work , moving them underneath the select list fields might be an improvement, at least they are taking up only one single row instead of four like in the current state of the MR. but i wonder if it would be possible to somehow integrate them more directly with the select list field or its label so no additional line would be necessary?

one detail about the icons on the module cards (probably out of the scope for this issue), but at the moment all those icons are active buttons (at least they are labeled like that). in addition to that they are redundantly labeled in lack of a context. you only have many "security note button" and "well maintained button" announcements. in regards of the button, to signify that they are not usable in the aural interface the aria-disabled attribute might be added. and a context aka module could be added to each particular icon string.

@richarddavies on which version of drupal have you tested? because on my 11.x test instance i am able to open the images preview dialog modal and close several times in a row with MR36 checked out.

I've went through the points you've listed and tested with the latest state of MR566.

VoiceOver switched off:

1. ✅ i can confirm, i am unable to expand the multi select dialog by pressing the return key, only by space. works as expected now, excellent!
2. ✅ i can confirm, tried to hit tab while the multi select dialog was expanded and the dialog remained expanded and wasnt collapsed anymore. fab!
3. i just kept the arrow down key or arrow up key pressed, that way you saw several focus outlines at once while scrolling (arrow_down.mp4)

VoiceOver turned on:

1. & 2 when the multiselect was in focus i pressed VO-space to expand the multi select dialog. that way you see the first option got auto selected and the entire list of categories announced. i then noticed something else. i pressed esc to close the dialog. when i pressed VO-space again the previously ticked checkbox got unticked and all categories announced. again esc and again VO-space the first option got reticked. (see On_Off-Wall-Of-Text.mp4). the dialog should be expanded but the state of the first checkbox not changed.
3. ✅ i am unable to reproduce. I "guess" that was due to an accidental misconfiguration of voiceover that i just figured out a few days ago
4. if you move up and down the multi select list you notice the checkbox label is not announced as well as the current checkbox state same as if you change the checkbox state the new state is also not announced (checkboxes.mp4)
5. and one additional detail i got reminded to. if you expand the select list field you get the announcement of a summary which does not happen/exist for the multiselect fields (summary.mp4). in the example you see and hear that select list fields are labeled as pop up buttons while the multi select is just a button. and when expanded the select list field announces that it is a menu with 2 items for the multi select that does not exist in the aural interface.

+1 for making the buttons visible all the time. but there is one potentially tricky problem to consider, the user is navigation the multiselect by the up and down arrow key. how should the transition between the options in the select list and the apply and clear button be accomplished? at the moment if you navigate down to the end of the list the apply button gets into focus but you are unable to reach the clear button by the arrow keys. and if you press the tab key the security advisory coverage select gets into focus. on shift focus you get onto the filter button that was unreachable before. but how to handle things for keyboard users with the position fixed of that apply and clear button i consider tricky.

I've tested the latest state of the MR. There are several issues to note. At first a video illustrating the aural interface (current.mp4). As you can see and hear the button is excluded from the tabindex. reason is aside the newly added aria-disabled="true" attribute there is still the disabled attribute on the element which overrides the aria-disabled attribute behavior. i've manually removed the disabled attribute in the web inspector and recorded a second video (disabled_removed.mp4). as you can see and hear the button is now included in the tabindex and the "dimmed" label is being added and announced. in addition to that the mouse cursor should use the cursor not-allowed on hover or click as used for example on the tour module as an example for pages that have no tour available:

Removing the disabled attribute solved also color contrast issues for the button (SC1.4.11) and its label (SC1.4.3). So contrast wise it looks fine the only thing to note, the button style feels quite unusual having a grey to white gradient it looks like? styling wise wouldnt it better to have a button styled as an action link where you only have the checkmark and button label visible?

took me a while to refresh my memory about the scope of the issue. i've first only skimmed through the title and the problem statement section, based on that i would have said the issue could be closed as outdated after the issue @utkarsh_33 linked fixed the leakage of filter selections across source types.

buuut reading through the proposed resolution more closely another time i think the more fundamental conceptual problem is still left to tackle that is not in the title and problem section but the proposed resolution only. At the moment, if you illustrate the components on the pages as priority guides, you get:

1. secondary tabs
2. search field
3. filter
4. results

Would the search scope only be the active source type, the visually hierarchy would be crystal clear except for the redundant search count. the user first decides the search context by selecting the active source type (1), then decides on the search term (2), then is able to refine and narrow down the results by filtering (3) and then is able to browse the final results (4). everything would be in a clear hierarchy and order top to bottom.

Instead on every change of the search string and/or interaction with the filter settings a new query is sent against each available and enabled source type. the individual number of results for each source type is reflected in each secondary tab (1). The count on the active secondary tab/source type (1) is redundant to the result count in the results section (4). That way the users attention is drawn between the secondary tabs (1) and the results (4) - while being in search field (2) which is part of the filter section (3). There is not that clear visual hierarchy and order and clear separation of concern of all the steps involved in the search experience. the relationships are not clear but intertwined. overall the interface still has a mixed messaging that lacks clarity.

there is also the question what is the benefit and or the actual need to search across all available source types? instead it might become rather a performance hog. at the moment you only have the contributed modules source type that queries the endpoint on drupal.org but sooner or later the recipes source type will do that as well, and themes might be added there as well. that way you would get three requests on every change of the search string or adjustment of the filter settings. and there is still the possibility that sites and agencies add their own private source types on top of that.

In the following the two approaches including including the proposed resolutions for each variant:

variant A - query all source types:

• move the search field between the primary tabs and the secondary tabs.
• remove the result count from the secondary tabs
• keep the search scope to all known and enabled source type

variant B - query only the active source type:

• remove the result count from the secondary tabs
• limit the search scope to the active source type

I regard of clarity and a separation of concern, my personal preference would be clearly variant B...

ps. in the drupal dojo austin where i'Ve presented the current state of project browser i got a few ideas/suggestions in regards of source types and filters that might apply here as well. but i havent had the time to summarize the findings. will catch up on this in the next few days.

thanks for your changes! The focus outline quirks on the cookie notice dialog modal seem fixed. There is only one detail to note, is it possible that the none modal dialog is slightly more narrow compared to its modal counterpart? On the none modal dialog the close button is slightly overlapping "following", plus "following" is comma separated, another indication of a more narrow element width:

when the close button is in focus the word "following" gets overlapped even more:

aside that minor detail, the close button on the cookie notice modal dialog and the consent dialog modal are still missing a focus outline.

And I like your idea adding a description to the first section and moving the legal note there. Only a thought about the wording. I've taken a look at the legislative text in https://www.garanteprivacy.it/faq/cookie (i've only used a translation service), but from my perspective the text is not about modals, but the cookie banner in general in which ever way it is displayed. but based on the description a user might assume the necessity to add the close button only if the "require user action" or the "show notice as modal" is checked. but as i understand the link text if none of the two checkboxes is checked and no close button added it would be in violation of the law in italy then. So maybe slightly reword the description and also front load the reason (the thing people will perhaps scan for) and leave the way how to solve things afterwards. How about something like:

Some national regulations require a close button for the consent. It can be enabled by the "Add close button to the modal dialog" option.

That resurfaces again the point i've made in #3484938-7: Add support for a less intrusive user experience mode → , it is tricky how to name each of ui component "flavors" as well as all of them at once. In my suggestion i went with the neutral "consent" without the addition of anything like banner, widget, component, or alike. but i've intentionally avoided using the term "modal form", since modal wouldnt entail the case where none of the two checkboxes under "require consent" is checked.

In regard of the section title "require consent" it feels and reads like an order, plus the other two sections are single worded nouns while this one contains a verb and a noun. Maybe it would make sense to drop require and label it just "consent"?

But in both cases i wonder if it would make sense to leave the title and description as is and making potential further changes within the scope of ✨ Add support for a less intrusive user experience mode Active where the labels of the different modes are being discussed as well. that way it might be easier to stay consistent?

jurgenhaas → credited rkoller → .

jurgenhaas → credited rkoller → .

just a brief note in regards of the problem in #19 🐛 Can't install latest version with composer Active where the install in drupal 11 failed. the composer.json of the calendar module is missing version 11 in line 24:

https://git.drupalcode.org/project/calendar/-/blob/8.x-1.x/composer.json...

rkoller → created an issue.

Added the issue to the a11y meta and added the the wcag211 tag for now (might need more wcag tags)

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

I really like the direction this one takes. Moving the Show Toggle Button checkbox underneath the Klaro! Dialog Mode section feels semantically and functionally closer. I also like, by switching over to radio buttons, it makes the different kind of available dialog modes more prominent - pre-MR, those two checkboxes were highly confusing. And finally a few additional observations and thoughts:

• When the MR is applied the radiobuttons are missing a default choice, none was selected for me? .
• Should the section, the klaro dialog mode radio button group and the show toggle button checkbox is in, also have section title like services and buttons have?
• In regards of the microcopy of the radio button labels. I would drop the verb "Show" which is redundant. About the naming of the "silent" option. Based on the info in the parenthesis and the help text underneath, i would assume that on my site no cookies or any external services are used and klaro remains unobtrusive - and as a naive none technical new user i would ask is klaro automatically testing that fact for me and otherwise the "silent" option wouldnt be available? And it is not clear if everything is blocked or if klaro stays just "silent" as the labels implies. i assume the former. i've also tried to test opening a node that contains a remote media item, there the klaro block and opt in functionality is active. so klaro is blocking the mandatory defaults and everything else requires an opt in? The radio button label "Silent" might trigger some misleading associations? In regards of the other three radio button labels, just based on their names, it is also not clear what the difference between a notice and a consent manager is function wise. Stylistically one of the options uses parenthesis, the other "as" and the other doesnt have anything related to modals. in case of the latter option it might make sense to use "none-modal" to illustrate the difference to the two modal options explicitly instead of implied?
• the online documentation and the menu link link point to the very same documentation page which only covers the part about menu links. i would rephrase the menu link documentation page. Instead of "can be used" i would use "has to be used". I would even move the detail, that this task requires the installation of the link attributes module, to the beginning of the page. Because i've just taken a look at the first one or two paragraphs and the screenshot and wondered where the attributes fieldset came from in the screenshot and how to get to being able to enter the rel attribute -> people only skim most of the time instead of thoroughly reading and my own example and experience is testament to that.

Yes, you are right. But the user has the requirement to place the markup elsewhere in the DOM. The advantages are not clear to me personally either. Maybe it's about the semantic order in the DOM.

maybe @schwankde can shed some light what the accessibility requirement mentioned in the issue summary is, why the klaro element has to be placed in a particular region?

Our aim is to ensure that Klaro can be used with as few settings as possible. The block function is just an additional function for repositioning in the DOM. We have written this again explicitly in the help text.

yes i understood that step. but it still feels odd if you have no block added to have a certain behavior and then after adding a block one close to identical behavior is still in place. from a clarity perspective it might be the better choice to have in any way a block placed on the block layout page. per default in a way that mimics the current behavior of no block being added and the user then can adjust the position and the block settings and/or add another block. but i would still need to understand the need of placing the block in a certain region in the first placec. at the moment the entire feature feels overcomplicating things from a ux perspective without a clear benefit from an accessibility perspective.

Could not reproduce. Maybe a caching problem?

Here with a block regularly added with all the default settings set:

Here the scenario described where i've deactivated the settings within the block but left the block title ticked, that way the behavior is identical to when no block is placed but the title gets hidden even though it is set. (definitely an edgecase no one would really run into but still the outcome differs to what is actually set therefore i've noted it):

And the micro copy of the choose klaro elements for this block is sort of unclear and redundant.

See new version please.

Definitely an improvement. I think that goes into the right direction. A few more thoughts after seeing everything with a fresh pair of eyes. For one the checkbox labels both start with the word Klaro which is still redundant. I wonder if it would make sense to move the term Klaro also into the title. And strictly speaking those elements referred to in the title are not "placed" but rather "moved" from their default positions into the block, in case one or both checkboxes are ticked. So how about something like:

Which Klaro components should be moved into the block

then on the checkbox labels the name Klaro could be dropped. and one nitpicky detail. depending on the dialog setting one could have either a consent modal, or a cookie notice, being either a dialog or a dialog modal. The Klaro consent dialog setting sounds like "Require user action" is checked. So would something like "Dialog element" or "Dialog modal" instead work, which would be more neutral and potentially clearer? Because i have to admit it is really challenging to know how each of the three ways to display the dialog are addressed (same as grasping to what form it is referred to). By making that microcopy a bit less ambiguous and more clear i am trying to avoid the need for the user to read the long description (which most users rarely do and if they do only skim over it).

And in this context one other thought, would it make sense and be possible to add a progressive disclosure to the "Klaro toggle button" checkbox? Meaning showing this checkbox only if the "Show button to toggle the consent modal" is checked? that would also make the description "The Toggle Button must be enabled for this option." obsolete.

You can open an issue here or we can do this - as you like: https://github.com/klaro-org/klaro-js/issues

Will open an issue upstream in the next days when i've worked through my backlog of comments i have to write up.

ok figured it out, the placement of the repo reference in the repositories section was the problem, had to move it past the composer entry few days ago to fix an odd behavior and that broke the ability to symlink now (i just havent noticed because i had already installed and linked all necessary contrib modules i was regularly testing - anyway the exact details i have to figure out still but at least i am able to test again). about the MR:

cookie notice (none modal dialog):
The focus outline if the dialog modal is in focus has a bulge:

while if the close button is in focus the focus outline is no proper square

the target size is large enough to meet the minimum requirement of SC 2.5.8.

cookie notice (modal dialog):
the close button is missing a focus outline (see dialog.mp4)

Consent dialog modal:
The close button is missing a focus outline (see consent_dialog.mp4)

Settings page:
You may enable the option Show close button X to modal form to meet national regulations. which is added to the descriptions of the first two checkboxes feels sort of redundant and unnecessary. Cuz technically that detail is provided in the description of the Show close button X to modal form checkbox in a rephrased manner already. it is only an indication that the proximity between the checkbox related to the dialog modals and the buttons sections is too large and that there is sort of a disconnect?

The first part of the first sentence of the description for the Show close button X to modal form checkbox is also redundant. The beginning of the description (Adds a close button X to modal dialog) is close to identical. I wonder if it would make sense to simply drop it and change things to:

checkbox label
Add close button to the modal dialog

checkbox description:
Closes the modal dialog and declines all consents. Mandatory in some countries for modal dialogs.

Thanks for the confirmation and the help with ideation finding the root cause. i've figured it out now (at least i know what broke but not the why, yet). the reason why i dont see the changes applied is the following:
i am using https://github.com/joachim-n/drupal-core-development-project which is based on a symlink approach, you have one repos folder with a folder for drupal core and you are able to add (git clone) additional contrib modules. afterwards you have to add the added repo folder to the repositories section in the composer.json. after that you also have to composer require the module you've just git cloned (and instead of added it gets symlinked). that approach worked fine for me for months. that way i am able to add and checkout MRs, which i did for klaro here as well. and when i'Ve checked before in the directory in the repos folder all the changes of the different MRs are applied properly. the problem is the changes arent reflected in web/modules/conrib/klaro and that is what the site i am testing on is based on. goota have4 to figure out why that sync isnt taking place anymore.

sorry for the delayed response but the last few days were a bit busy. i've tried to test your latest changes as well getting up to speed again before i reply to your comment. but somehow even with MR16 checked out i am unable to find a klaro block on the block layout page when i try to place a block? first thought something broke in my local test instance so i wiped everything, but the same situation after i've set up a new instance?!

@jan kellermann, you have mentioned that it is necessary to enable the close button in the settings, but somehow i am unable to find that button. I've applied MR32, code changes are in place, and i went through the different settings pages but no luck finding anything in regard of this setting? semantically i would have expected the checkbox under settings -> general within the buttons section, but i only find "accept all", "decline all", "learn more", "display learn more as a button" and "show button to toggle the consent modal"?

Commented on #2983456-166: Expose triggering update of media metadata + thumbnail to end users → . benji commented on the other two issues already, recording and transcript are also already in place. so this issue can be set to fixed.

I've commented on the refresh media items issue: #2983456-166: Expose triggering update of media metadata + thumbnail to end users → . Video and transcript are available and in place. But i've checked for comments to the other two issues for this meeting. benji commented on #3221259-28: Add permissions for optional modules to content editor role as they become enabled → but 📌 Improve links on /admin/people/roles Active which is also listed in the issue summary doesnt have a comment yet. i'll recheck the recording after dinner (cuz i cant remember your conclusion from back then).

Commented on the issue: #2983456-166: Expose triggering update of media metadata + thumbnail to end users → . Since the commenting on the issue was the last remaining task, I am setting the issue to fixed.

Usability review

We first discussed this issue at 📌 Drupal Usability Meeting 2024-09-27 Active . The link to the recording is https://youtu.be/cWtwA63z-IE. For the record, the attendees at the usability meeting were @amazingrando, @anmolgoyal74, @benjifisher, @rkoller, @simohell, and @zetagraph.
We revisited this issue at 📌 Drupal Usability Meeting 2024-10-04 Active . The link to the second recording is https://youtu.be/JPxvcpNXY0Q. For the record, the attendees at the second usability meeting were @AaronMcHale, @avani.bhut, @benjifisher, @rkoller, @shaal, @simohell, and @zetagraph.
Yesterday we revisited this issue for a third time at 📌 Drupal Usability Meeting 2024-11-15 Active . The link to the recording is https://www.youtube.com/watch?v=8DqSpKVK768. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.

After taking a look at the current state of the MR, we’ve mainly focused on the points raised in #138 → , since those cover most of the remaining open questions from an UX perspective, and we’ve assessed their validity and relevance.

1. First, we went through the different scenarios that might happen aside a successful update:

Scenario A (No changes and therefore nothing to update):
It was considered as a nice to have but optional, not a blocker at this point, since it is a difficult task to determine if a media item is changed or not. So we leave it up to the people working on this issue if they want to cover scenario A already within the scope of this issue or if they would prefer to move it to a followup issue. Our consensus for the status message was:

Nothing to update. Media item [x] remains unchanged.

In contrast, the other two scenarios should definitely be covered within the scope of this issue, since in both cases content might be removed and/or lost. As Laura Klein stated in her book “Build Better Products” -

Good design doesn’t lose data or state just because a user has performed an action in a surprising way.

. To prevent any potential data loss, like missing thumbnails in the frontend, the group agreed on adding a confirmation step to each of the two scenarios. So that the user becomes aware, that something is off and that they might experience a potential subsequent data loss, when the metadata of a media item is updated from the source. In the case of remote media items, the source might simply be temporarily unavailable due to an outage, just as, for example, source files where the file folder is being mounted from a file system and that file system is unavailable - without a confirmation step, the data would get removed when the metadata is getting updated. Our recommendation for those two cases are as follows:

Scenario B (The local source of the media item is missing):

Description:
The source file for media item [x] is missing, unable to refresh.

Buttons:
Remove thumbnail
Cancel

Status message after...
…the Remove thumbnailbutton is clicked: Thumbnail removed for media item [x].
…the Cancel-button is clicked: Canceled. Media item [x] remains unchanged.

Scenario C (The remote media item the source is unavailable):

Description:
The remote source for media item [x] is unavailable.

Buttons:
Retry
Cancel

Status message after...
…the Retry button is clicked and the refresh was successful: Updated metadata on media item [x], while if the refresh fails, the confirmation form is shown again.
…the Cancel-button is clicked: Canceled. Media item [x] remains unchanged.

It has to be noted that we had a clear consensus about the importance of having a status message after a button on a confirmation form was pressed. There is always the possibility that someone is clicking a button on a confirmation form, either absent-minded or by a stray mouse click. The subsequent status message keeps the user in the loop and informed about the made choice.

Aside from the refresh of a single source, there is also the case of refreshing more than one source at once via bulk actions. Question is, how to handle things with more than one case of scenario B, more than one case of scenario C, or even a mix of both? You can’t run someone through a chain of tens of single confirmation pages. One option is that the confirmation pages for scenario B might be combined into a single page, the same as the confirmation pages for scenario C, or all confirmation pages for scenario B and C might be combined into a single confirmation page. But due to the fact that there is no existing UI pattern in Drupal Core yet, we don’t want to hold back the current issue, and we would recommend moving the bulk refresh of media items into a follow-up issue.

2. In regard to the microcopy, we considered the term Refresh as suggested in #10 → to be the more clear and accurate choice. Update is a loaded term, in combination with the fact that all the other options (edit, delete, translate) on the Operations drop-down point to forms on other pages. That way, the user’s assumption might be that Update also points to a dedicated page or dialogue that entails an active manual interaction. In addition to that, all the other options in the Operations drop-down are single-worded verbs. Therefore, we would recommend the following change to the Operations drop-down option:

Update metadata -> Refresh

The term metadata is also sort of an abstract and ambiguous term in regard to its scope in this context. It is not clear what kind of data is getting refreshed by the option Update metadata. Is it only the associated fields or also something like the thumbnail, as already mentioned in the issue summary. To make things more explicit we would recommend the following change to the bulk action option label in the follow-up issue (again in line with the suggestion in #10 → ):

Update metadata -> Refresh from source

3. We also checked if there were already help topics for the other options available on the media page, but we were unable to find any. So we had the consensus that it wouldn’t be necessary to add any instructions about the Refresh option to the help topics at this point.

4. One additional detail we’ve noticed during our testing. If you are manually replacing an image in the file system, then hit the Update metadata option, the thumbnail is properly updated on admin/content/media. But if you now click the Edit-button for the media item and then click the link to the source file, the old replaced image is still shown. Could that be a caching issue? We haven’t had the time to investigate in more detail.

I am setting the issue back to Needs work and remove the Needs usability review tag. If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

carried over from previous weeks:
✨ Use data-* to check modules dependencies before submit Active
🐛 New User Logout confirm Form is misleading Needs work

nod_ → credited rkoller → .

forgot the ui in jquery ui , updated title and issue summary

larowlan → credited rkoller → .

rkoller → created an issue. See original summary → .

benjifisher → credited rkoller → .

I don't have the time today to evaluate the entire micro copy, because my fridays are blocked with appointments, but i wanted to add one observation and concern that struck my eye earlier in regards of the consistency of the terminology. on the klaro config pages the term app(s) is being used while front facing on the consent dialog modal the term service(s) is being used in the Enable or disable all services label. the only other place service is being used is while editing an app in the description for the callback code field in the advanced tab. to me app and service feels and reads synonymous or do they differ from a technical perspective having different capabilities and scope?

oh i havent looked at the microcopy of the vertical tab in your screenshot in #12. then yeah for me it looks different, it looks like that:

but after seeing your screenshot i've rechecked the other content types. turns out the content type i'Ve created and you are seeing the screenshot for is showing that old description. but the article and basic page content type have updated that description in line to your screenshot in #12 and i've created another content type now which is also showing the description shown in #12.... NO idea how that could have happened to the content type i'Ve first looked at and tested. sorry :/

One detail to note, the description for the Display settings vertical tab only represents the already existing checkbox, so i suppose the description in the vertical tab would have to be adjusted to cover both checkboxes?

rkoller → created an issue.