🇩🇪Germany @rkoller

I was able to fix the stylelint issue but the phpunit ones i feel unable to solve and they look from my none developer perspective unrelated? the errors show in the context of package manager and i've only added an option to a javascript file? if someone else could take a look please who is more familiar with this kind of stuff. thank you.

I've added the drupal cms a11y tag as well as wcag SC2.4.7 applies here as well. sighted keyboard users might get confused if on one tab no focus is visible. will manually test the MR over the weekend, but the proposed solution looks good from my perspective. and i've also set the priority back to normal.

benjifisher → credited rkoller → .

Opened an initial MR. It is setting the option uiDialogTitleHeadingLevel that was newly introduced with jQuery UI 1.4.1 to 1 on dialog.showModal method. That way it is ensured that all dialogs modals have their title properly wrapped in an h1 instead of a span, the previous default. Since Drupal 11.0.0 and the update to jQuery UI 1.14.0 dialog modals got the aria-modal attribute added which ensures that all elements in the background of the dialog modal are removed from the accessibility object model, so the main or sometimes sole heading within a dialog modal is the title, and therefore it is advised to go with the h1 element for the title wrapper. In addition to that i've also set the margin for .ui-dialog .ui-dialog-titlebar .ui-dialog-title to zero, because the change to the h1 added an additional margin to the layout and by setting it to zero it readjusts it to the previous state of the design.

*@rocketeerbkw worked with me on the upstream change (https://github.com/jquery/jquery-ui/issues/2271) as well as on this issue here

Thanks for the comments! The direct links are:

#3481652-11: SortBy filter is conflicting after switching between different tabs →
#3487832-3: Discuss and perhaps improve how source types are integrated into the overall search experience →
#3487970-3: Consider moving "items per page" and perhaps the "sort by" select components next to the grid/list toggles →

also striked the last remaining task about the comments. everything done now.

applied a small change to the link of the transcript. "/files" was missing at the beginning.

I've also tested the latest changes in MR338.. did three rounds of testing. after each round i did a drush sql:drop. and with the latest changes i've ended up on the dashboard three times in a row, no WSOD. per @phenaproximas i'll set the issue to RTBC.

rkoller → created an issue.

thanks! i've manually tested. after checking out the feature branch i've did three rounds of installs (after reaching the dashboard i did a ddev drush sql:drop && ddev launch)... so at the moment i am unable to reproduce the WSOD. so the only thing left to answer is benjis question if we are looking still at another symptom or the actual root cause. the only thing i can say is that at least i am unable to run into the WSOD at the moment.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

thanks for testing @itamair, you are unable to reproduce because you are on safari 18.0... as outlined in #13 🐛 Running the installer leads into a wsod Active , @benjifisher was on a version <18.2 as well unable to reproduce, but as soon as he updated to 18.2 he was able to reproduce.

@debrup i guess you are seeing a different kind of error. is it happening to you with the zip for RC2? there seems to be a regression of the issue in 🐛 The "dashboard" parameter was not converted for the path Needs work . i've read a discussion yesterday where @stasadev ran into the same problem you've encountered.

The WSOD persists in RC2 for Safari, just "successfully" tested. Only difference the line shifted further to 295

The website encountered an unexpected error. Try again later.

Error: Call to a member function getPath() on null in drupal_cms_installer_theme_registry_alter() (line 295 of profiles/drupal_cms_installer/drupal_cms_installer.profile).
Drupal\Core\Extension\ModuleHandler->alter() (Line: 434)
Drupal\Core\Theme\Registry->build() (Line: 276)
Drupal\Core\Theme\Registry->get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry->initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry->__construct() (Line: 314)
Drupal\Core\Theme\Registry->getRuntime() (Line: 141)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 176)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->makeSubrequest() (Line: 132)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->on404() (Line: 109)
Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Did some more digging with Xdebug. I got the following output for Safari in the last step right before the WSOD turns up with a breakpoint added on line 286 of the drupal_cms_installer.profile .

The entire call stack contains calls on functions to files that belong to core or symfony, at least as far as i can see. drupal_cms_installer_theme_registry_alter() is getting called in the previous step in the ModuleHandler.php.

I've then tried the same with Firefox. But the breakpoint was not triggered right at the end like in Safari, you directly go into Dashboard instead. So it looks like drupal_cms_installer_theme_registry_alter() isn't called with Firefox. I've now tried to debug the previous steps, finding out at which point of the call stack you get to the Dashboard instead (but unfortunately i have to press proceed for too many times and i am not getting anywhere not even past the first section of the installer cuz i had set the last four breakpoints from the call stack shown for Safari - even with just the breakpoint for modulehandler.php only there are too many clicks)

i wouldn't add anything to the scope for this issue. but i've summarized the additional points raised during the aforementioned drupal dojo austin in: 🌱 Discuss and perhaps improve how source types are integrated into the overall search experience Active

jurgenhaas → credited rkoller → .

jurgenhaas → credited rkoller → .

grienauer → credited rkoller → .

phenaproxima → credited rkoller → .

Initially filed it as a task because of the need of updating jquery but the remaining step about changing the wrapping element of the title i would consider a bugfix.

I'Ve updated the title and rescoped the issue proposed resolution since jquery ui 1.14.1 got updated 📌 Update all JavaScript dependencies which cause no changes Active . My initial proposed resolution by adding uiDialogTitleHeadingLevel: 1 after line 40 is wrong (tested it manually altering 11.x locally) . i was under the impression it would be a similar one liner like for adding the aria-modal functionality added for 11.0.0, but it seems not. reason is the _createWrapper method was already available in the dialog.jquery-ui.js but the _createTitlebar method is not available there yet.

i am on a mbp m1pro 32gb with sonoma 14.7.2 and safari 18.2... and i am on lima 1.0.2 and on the HEAD version for DDEV.

and the steps are correct, plus the steps i've applied in the installer "In the installer choose all the available pre configured types of content (blog, case studies, events, news, person profiles and projects), use the default site name, and finally add an email address and password"

but as we have discussed on slack the issue got committed meanwhile, so those additional steps are not necessary anymore, it is simply downloading the zip file from either https://www.drupal.org/project/drupal_cms → or https://new.drupal.org/drupal-cms/release-candidate and then follow the aformentioned settings in the installed. but as i have noted with the zip file from one of those links i was unable to reproduce the WSOD so far. but i will try a few more times tonight if i am able to.

phenaproxima → credited rkoller → .

and i forgot to change the status, needs some more work and discussion

benjifisher → credited rkoller → .

thanks for working on the changes @vidorado! i've taken a look at the latest state of the MR, in the following my personal opinion, not the opinion from the group that has discussed the issue last friday (even though i have shared my thoughts and the demo video in the thread for last weeks meeting on the drupal slack: https://drupal.slack.com/archives/C1AFW2ZPD/p1733493024401899).

point 1 and 2 i consider fixed and also the from my perspective the right approach to recommend. looks good me hiding the save and reset to alphabetical button as well as following the pattern used on admin/content which is hiding the reset button while no filter is entered yet.

point 3 and 4 probably need some more work. i've created a short video illustrating the recent changes including the aural interface with voiceover - vo.mp4.:

1) If you press the filter button after entering a filter string the focus is getting lost. So if you are keyboard user the focus isnt around the filter section in the DOM but at the beginning of the tabindex,.you notice after pressing the filter button the first element to focus is the skip to main content skip link instead for example the reset button.

2) I am completely uncertain what the best approach for communicating the filter matches is. i still am inline with our review that just adding a background color to the rows with matches has for one accessibility issues but also the problem that people associate those rows with a background color as "errors" because the color is the same or at least close to the color of the warning message, and the fact that a warning message was shown in the first place. but on the other hand i am also not sure if our suggested idea is the right choice and having just an icon at the beginning of the row is already clear enough. well first of all using a caret at the beginning has at least another problem, that caret a user associates with collapsible and expandible lists. i always think i am able to expand those two rows in the video. but i've tried to replace the caret with the bullet and the bulls eye suggestions we've made during the call as well as an arrow, an additional suggestion @simohell made during our followup discussion in the drupal slack, but none of those really clicks for me :/

Problem is, i've also checked the drupal design system and there is neither a perfect fit for an icon nor a defined component how filter matches should be communicated visually. i was hoping maybe i have missed anything the first time i was looking. i still think removing the warning message is the right step but "maybe" adding an icon (which still has to be decided on) AND having a background color might do the trick? or maybe we should ask the claro maintainers for design input?

3) the aural interface for the icon is not necessarily clear to a none sighted users without any visual cues. black pointer is not really clear if someone directly skims through a table not checking the help text upfront. and still if the person knows that help text, there is still a cognitive transfer that you have to transpose the announcement of black pointer equals to a match. i wonder even would it be viable to make the icon decorational while adding a visually hidden span to the name which prepends something like "Match" ? Not sure what others think?

4) about the help text. i think i would move "Reordering is disabled while terms are filtered" up to the help text and make it available all the time. the legend/explanation i would keep there and only show with an active filter. the only thing about that legend, the brackets were only intended as a placeholder to highlight there an icon should be inserted. cuz now the brackets in combination with the caret create the association of a play button for me :D

for the git based approach i completely agree but in case of the shell script it isnt such a rare case anymore but more of a consistent problem, at least for me (and yep very hard to debug - i will ask randy if he might have an idea how it might be possible to debug that). i think i will try a few more times after 🐛 Remove .ddev directory from composer create-project Active goes in and if the problem persists there and keeps happening that consistent i would consider it more pressing problem tbh cuz launch-drupal-cms.sh might be the way quite a few people interact with drupal cms for the first time in the future? and i guess the odds are high that i am not the only one then.

and i am completely puzzled meanwhile. yesterday (or better this morning right before bed) i'Ve tried it one last time with the shell install and documented everything in a gist https://gist.github.com/rpkoller/297ba345281def46cf8f302147bd68c5 (@rfay suggested to set export DEBUG=true and document every detail in that gist). but after ten plus consistent WSODs attempts over the night it worked in that last attempt for the first time as documented in the gist. all other attempts with the same setup failed repeatedly consistently. i said in #4 git clone git@git.drupal.org:project/drupal_cms.git . && ddev launch worked yesterday. well this morning right after waking up i'Ve retried things, cuz it puzzled me that it worked for the shell approach in my last attempt before bed, and i am back to the WSOD and had another two failed attempts (thought maybe it was a lima problem, but that could be ironed out because after the computer was shut down over night it was a fresh start today). i then tried the git clone git@git.drupal.org:project/drupal_cms.git . && ddev launch which worked fine the few times i tested yesterday. BUT one out of the three attempts this morning failed now. so the WSOD happened there as well but not that consistent. NO idea what could be causing this. might be some sort of race condition that might happen more likely with the shell approach compared to the git clone one?!

nope, just tested, on 1.x HEAD, it does not happen there. git cloned the repo into a new empty directory, ran simply ddev launch and after the initial setup was done and the installer was popped up in the browser i've entered the same settings as in steps to reproduce

my first submission errored out. created a new, second, issue, but on submit that created two identical issues. closing this one as duplicate. apologies.

rkoller → created an issue.

rkoller → created an issue.

and i will quickly test another round based on the updated new instructions.

can confirm the install works now. i end up in the drupal cms installer when executing the shell script, which is the intended outcome.

Following the steps provided in the issue summary i've first cloned the drupal_cms repo, applied the MR, and then copied the project_template directory into ~/Sites... I left the folder name as is and simply ran ./launch-drupal-cms.sh. the initial project start worked but on the composer create step i ran into an error because of the README.md file and the project folder not being clean

Failed to create project: '/Users/rkoller/Sites/project_template/README.md' is not allowed to be present. composer create needs to be run on a clean/empty project with only the following paths: [web web/sites web/sites/default web/sites/default/.gitignore web/sites/default/files web/sites/default/files/sync web/sites/default/settings.ddev.php web/sites/default/settings.php] - please clean up the project before using 'ddev composer create'

re #31 📌 Change UI for the install queue to match bulk operations Active thank you! left a few comments on gitlab that added variables to the install button states as well plus to the border of the select button states to make things more consistent. but aside that things look good. everything else should be moved to follow ups as utkarsh_33 suggested.

re #30 📌 Change UI for the install queue to match bulk operations Active i still think it is important to be explicit about the terminology used on source type and i wouldnt consider the problem outdated but having an issue just about a single source type might be the wrong approach and there probably needs to be an issue for all source types in general. but there are a few need that need to be discussed how the bulk action bar should behave (out of the scope for this issue) if entities are selected for a source type and the person is switching source types. on admin/content the bulk action bar disappears on the new tab and if you return the previous selection is not restored. with svelte the selection is remembered, if you switch the source type after selecting entities on source type 1, there is no bar and no selection on source type 2 but if you switch back to source type 1 the selection is being restored (i m even able to switch to pages outside of project browser and if i return the filter string, filter settings and my selections are being restored?!). and within the same source type you are also able to add modules across several pages (something not possible on admin/content):

• if you have selected several entities across several pages of a source type it is difficult to remember (in particular people with a small working memory) on which pages you have selected which entity, there is currently no way to at least reset a selection. i suppose having an interface were you get an overview of your selection and where you are able to remove individual selections would overcomplicate the UI, but having at least some kind of reset option might be helpful or even necessary?
• about the selection being persistent. i wonder if it would be a good idea if a person is deliberately moving away from the context of project browser based pages to reset the persons selection and maybe even the string someone searched for? i imagine it might be a source for confusion and even a potential source for other problems (person unaware that a selection is still active, adding more to that, and in the end it becomes an unexpected number of installs for the person) or even be simply annoying if a selection is being persistent if someone leaves project browser pages and returns.
• in the context of an unexpected number of modules installs, would it be reasonable to add an option to the project browser settings to enable a confirmation step for the bulk install option? that the site builder gets an overview of the things being installed and has to confirm that first? that the person has the situational awareness what is happening next (also the case that an accidental selection of the wrong module was made?)
• in the context of the related issue it might be important to clarify that the "streams shouldnt be crossed" (i helped myself with ghostbusters). i imagine it potentially confusing if it would be possible down the line to have a "global" bulk action list for all available source types. solely terminology wise that would create tricky problems probably.

yeah on one hand you are right, but our thought was even though the tour module is currently not included in drupal cms anymore, but since it is planned to be reincluded in the future, so it shouldnt prevent us from already loosely working on the an initial outline for a draft without any deadlines nor time constraints. so from my point of view it would be ok either way, keeping it postponed or making it active again, we could simply start collecting points in the google sheet.

rkoller → created an issue.

Finally managed to write up a comment: #3323354-36: Review all pop-up messages shown by the Svelte UI installer for user friendliness →

We discussed this issue another time at 📌 Drupal Usability Meeting 2024-11-29 Active . The recording of the meeting can be found at https://youtu.be/l1rxLBree2c. For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, and @simohell.

Apologies I haven't managed to write up a summary earlier. I've only provided the brief gist of the discussion on a thread during the meeting for project browser on the drupal slack last wednesday.

We've started to compare the current state of the MR with the artifact, the google doc (https://docs.google.com/document/d/1SEjq-UkbCQglh7DTIJw1_rk2ckDo8qk8tV7m...), from our last discussion of that issue. it has to be noted that we've only managed to cover the first string during that one hour. the noun “project” pulled us into a rabbit hole (i would recommend watching the video for the broader outlook). but the scope for this summary is limited solely to the details directly relevant to the popup messages.

When we've discussed the first popup message the last time, we've ended up with Another module is being added. Try again in a few minutes., the current MR only changes the term module to project for that string. We understood the point, that for probably technical reason a specific term like module was avoid within the popup messages to circumvent any complexities by using a more general and neutral term that is able to cover and describe not just a single source type.
But there was a clear consensus in our group that going with the term project in this case is sort of problematic. Project is a term that is used in the context of drupal.org, but in the context of drupal core the concept of a project is not really used in the micro copy of the admin UI, even the user has no real touch point with the module name of "project browser" (except the persons who have access to /admin/modules). You encounter the term project only in the popup messages this MR introduces and the prominent h1 Browse projects on admin/modules, in drupal core people are more familiar with the concept of extensions instead (also reflected in the the top level menu item Extend).
In summary project is a term used in the context of drupal.org but not anywhere in drupal core, which might lead to potential confusion and a higher cognitive load, which is in particular relevant if you run into the concept of a project in the context of a stress case like an error. So if you wanna go with a more general term, we we would recommend going with the term extension instead of project in the installer messages, as well as to consider changing the h1 on /admin/modules from Browse projects to Browse extensions.

And it would be good if @chrisfromredfin could maybe join the next usability meeting or one after, then we could revisit the issue and go through the rest of the strings. it is always better to have someone joining the discussion who knows the underlaying technical ins and outs. that way we might hopefully finish the rest of the strings and finally commit this.

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

thanks for the changes. over all things look better and more consistent moving the dequeue button to the secondary button style as well.thanks for that. the color for the normal and hover are correct now. the only thing missing is setting the active state when the button is pressed as well. that is still at #003ECC same as the normal state. and on a sidenote wouldnt it be the better choice to use the color variable instead of hardcoding the hex value? normal would be --color-blue-600, hover --color-blue-650, and active --color-blue-700... and the other points could be moved to follow up issues i agree.

i had already commented over on slack a few days ago, but add my comment for reference here as well now as well. the only two problems i see with the current state is for one that the button style for the queue button moved from a primary button style over to a secondary button style. per se a reasonable and good move since the primary action on this page is the install button on the bulk action bar now. but it feels not correct that the dequeue button is still styled as a primary button. semantically i think it would be the right choice to style the dequeue button as a secondary button as well? that could be done within the scope of this issue. the other styling with the stylized checkboxes we've discussed might be moved to a follow up to provide visual cues aside the plain button label helping the user to distinguish the queue and dequeue buttons more easily.

the color of the hover state has a too low color contrast against the background color of the bulk action bar, but that is an issue that core itself has with claro as well. on the thread i've suggested moving that to a follow up issue , opening an issue for claro and project browser. i'Ve also asked @mgifford about that detail, but havent had a feedback yet.

and another problem that core has on for example admin/content as well is the fact if you have not selected anything (an entity on admin/content or a a module on admin/modules/browse) you are able to click/press the apply to selected items / install selected project button anyway and you get a no project selected error. that error should be avoided in the first place. again that could be moved to a follow up issue.

so in summary the only thing i think from my perspecitve that would definitley make sense within the scope of this issue is changing the styling of the dequeue buttons to secondary buttons as well. what do others think?

ps: oh and i just noticed the secondary button is missing the state style changes (hover and active). the blue remains the same here? https://www.figma.com/design/OqWgzAluHtsOd5uwm1lubFeH/%F0%9F%92%A7-Drupa...

thanks for the changes... the dialog modal getting the initial focus looks good... but i've noticed several more problems in the context of the a11y within the dialog modal. so far i have only tested it with modules that havent had an image carousel, plus i havent taken a closer look with voiceover active neither (see and hear dialog.mp4 and voiceover.mp4).

• with the dialog modal being the first element in focus it feels sort of odd to have the close button as the second in the tabindex? would it be possible and be better if the close button would become the last in the tabindex in the dialog modal?
• the back and forth buttons of the image carousel in the dialog modal are missing a visible focus outline (SC2.4.7).
• The labels for the next button with "slide right" is not clear (why not use something like "next image" and "previous image") in particular due to the fact that all the images in the carousel are labeled as decorational. with only two images you only have a single button cuz the other is disabled. with more than two images you then have a slide left and slide right buttons but no content you the user are sliding inbetween.
• the disabled button is not reflected in the aural interface and that way things might become confusing for screenreader users. using aria-disabled="true" instead of disabled would make the disabled button tabable and labeled as dimmed/disabled in for example voicover
• the tab order is odd. as demonstrated in voiceover.mp4, if the focus is on the slide right button, you press return and the button turns disabled and you press shift-tab to get back to the slide left button you get to the learn more button instead?!
• in dialog.mp4 and voiceover.mp4 i manage each time to get with the focus outside the dialog modal into the background of the modal which should not happen.

i set the issue back to needs work. the other option might be to move some of those points to follow up issues to keep the scope for this issue, but due to the fact that this issue is about the a11y of the dialog modal i set it back to needs work for now

Left a comment at #2975863-71: Taxonomy overview list with exposed filter →

We discussed this issue at 📌 Drupal Usability Meeting 2024-11-29 Active . That issue will have a link to a recording of the meeting. For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, and @simohell.

First a few potential stumbling blocks we’ve identified during our initial testing:

• At the moment you have a Filter and a Reset button visible all the time. That pattern is sort of inconsistent with other places in Drupal Core. For example on admin/content you only see a Filter button, the Reset button is only shown while a filter is being active. The other pattern available is for example on admin/modules, where you have no Filter button at all, the module list is directly narrowed down and reflowed as soon as the first character is being entered in the filter field (which is not meeting SC3.2.2 -https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). Instead of having a Reset button the filter field is using the browser’s Clear button. Unfortunately the support for the Clear button pattern is not that good across browsers, as outlined in the issue summary of ✨ Add a clear button to the fields ui Active . And we wanted to note that there is also an issue about the unification of the filter functionality across Core in general in the following issue ✨ Create Javascript library for searching rendered lists on the client. Needs work .
• We considered the micro copy for the warning message (Term reordering has been disabled because terms are being filtered. To enable term reordering, reset the filter.) a bit too verbose. And warning messages in general are more about highlighting certain one time events, not about explaining a persistent inherent behavior a user is facing each and every time.
• The way terms are labeled as matches have several a11y related problems. For one the background color that is labeling a match has a too low color contrast with 1.1:1 which is #FDF8ED against #FFFFF (SC 1.4.11). We’ve also quickly tested in VoiceOver (voiceover.mp4) and there is no indication in the aural interface to label that a row is a match. So the color is the sole way that communicates a match, which is not meeting SC1.4.1 (https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html). The width of the table header is also broader than the width of the rows when a filter is active (probably because the drag handles got hidden). That way the header and the rows are not aligned compared to if no filter is applied. And out of the scope for this issue, but I realized while recording the video for this summary, that not only the match state is not reflected in the aural interface, but also the level a term is within the term hierarchy is not reflected there either (voiceover.mp4).
• It was also considered confusing to have a Reset button in the filter section and another Reset to alphabetical button at the bottom of the list next to the Save button. With a filter active, and you the user pressing the Reset to alphabetical button, you get presented the following help text Resetting a vocabulary will discard all custom ordering and sort items alphabetically. on the confirmation page. Based on that help text the expectation and assumption would be that only the filtered results would be displayed in an alphabetical order. But not only the list gets switched back to an alphabetic order but also the filter gets reset - a detail that is not reflected in the help text. But in general it is sort of confusing in the first place to have to differently labeled Reset buttons with slightly different behavior within the same page.

The group concluded on the following points:

1. We would recommend to hide the Save and Reset to alphabetical buttons at the bottom, anytime the filter is active. That avoids any ambiguities in regards of the Reset buttons plus the Save button is sort of without any purpose while the user is unable to alter the term order. Strictly speaking you are currently having three reset buttons, Reset and Save simply reset the filter, while Reset to alphabetical resets the filter and resets the order to alphabetical.
2. We had the clear consensus recommend trying to be more consistent with existing UI patterns in Core, and follow one of the aforementioned approaches used on either admin/content or admin/modules. While writing this comment and looking again at both approaches i’ve realized following the approach on admin/modules might not be the best choice due to the fact that it is not meeting SC3.2.2 plus it is relying on the browser’s clear button which has additional issues - after a brief followup discussion we've agreed on going with the pattern used on admin/content as our recommendation.
3. We would drop the highlighting of matching terms by color. Instead an icon could be added, which could be for example either a bullseye or a bullet in the position currently the drag handles are in when the filter functionality is inactive. The icon could have an alt text or aria-label communicating that the term in this row is a filter match and by using such a bullseye or bullet in the position of the drag handle when the filter is active the table header and the table underneath would stay seamlessly aligned without the shift it currently has (voiceover.mp4). And if such an icon solution is chosen it is recommended to add the following line, right before, on top of the table header: [Icon] indicates matching terms. Parents of matching terms are also shown.
4. In regards of the message currently communicated with a warning message the group agreed on shortening the string and making it more concise by changing it to: Reordering is disabled while terms are filtered.. The only detail we had not consensus on was how and where to present that message. From our perspective there are two viable options. Either keep the string in an admin message. If that is the case change the type from a warning to an info message, since nothing is broken or going wrong, it is simply an informal message about the inherent behavior of the interface on that page. But as a downside that message draws a lot of attention and uses a lot of screen real estate every time a filter is applied. The other option we’ve considered was to remove the admin message entirely and append the string to the help text ([vocabulary] contains terms grouped under parent terms. You can reorganize the terms in Taxo using their drag-and-drop handles.). Downside with that approach, due to the fact that the primary button, the filter section and the table have a way higher affordance, drawing all the attention, the odds are high that this text is potentially glossed over and even missed entirely.

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

in regards of the highlighting one question. in the screenshot in the issue summary https://www.drupal.org/files/issues/2024-10-09/2975863-warning-about-reo... → you have both matches and none matches with the matches visually highlighted. with the MR applied i only see the matches (still visually highlighted) but no none matches shown? is that intended?

@gto1 have you run the command (ddev mutagen st drupal-cms -1) that was recommended in the screenshot you've provided? and if you did, could you provide the output? and if not could you run the command if you run into the problem the next time?

but i am unable to reproduce the problem. i've went through the steps to reproduce and everything worked as expected. i've tested with ddev HEAD which is one or two commits ahead of the latest version of ddev (1.24.0) on macos with lima. and one detail i've noticed, you've tested with ddev 1.23.3... so it might be worth a try to update to the latest version of ddev first and retry with that?

thank you! added the direct link to the success criterion to the issue summary.

added breadcrumbs to the list of of examples for links i forgot.

added a note i forgot in the initial posting, that i'Ve discussed the matter several times with @mgifford before posting on here

rkoller → created an issue.

not sure if that detail was already raised (at least i havent found anything in this thread), but the drop containing images in the hero isn't resizing proportionally in safari 18.1.1 (on macOS 14.7.1) ... in the latest firefox and edge the drop is getting resized proportionally.

and in the context of #106 🐛 Feedback on Modern Drupal.org Design Active would it make sense to set #3265866: Optimise images on drupal.org → active again?

@smustgrave raised ✨ Taxonomy overview list with exposed filter Active

jurgenhaas → credited rkoller → .

jurgenhaas → credited rkoller → .

a brief note about color contrast, the apply button has a too low color contrast. I would go with the same color suggested on the bulk action issue, --color-blue-400 which is already used on the bulk action bar on admin/content. the general behavior in the context of keyboard navigation i'll retest later today.

adding a tabindex to non-interactive is not adviced (see for example https://www.a11yproject.com/posts/how-to-use-the-tabindex-attribute/). https://html.spec.whatwg.org/dev/interactive-elements.html#the-dialog-el... suggests

As such, authors should use the autofocus attribute on the descendant element of the dialog that the user is expected to immediately interact with after the dialog opens. If there is no such element, then authors should use the autofocus attribute on the dialog element itself.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog suggests:

The autofocus attribute should be added to the element the user is expected to interact with immediately upon opening a modal dialog. If no other element involves more immediate interaction, it is recommended to add autofocus to the close button inside the dialog, or the dialog itself if the user is expected to click/activate it to dismiss.

i would rather lean toward the smallest commone denominator between the two aka focus on the dialog element itself instead of focusing on the close button cuz the intend of the dialog modal is that some browsing of the content and interaction with the elements in the modal happens. but i guess it would make sense to also start thinking and opening a follow up issue about the general structure of the dialog modal content (implementing the things we'Ve learned from the survey and which got aggregated into the quality indicators.png)

Two additional observations to the points @narendrar made in #18 📌 Change UI for the install queue to match bulk operations Active :

the dark blue of the "install selected projects" button is too dark and has a too low color contrast (#003ECC/#232429 => 1.9:1). admin/content uses --color-blue-400 for the "apply to selected items" button, that way you have 3:1 meeting SC1.4.11

if you first select a module and then deselect (not sure if the bar was already shown without a selection), the styling of the "install selected projects" button becomes broken. grey background and greyish typography (SC 1.4.3&1.4.11). strictly speaking i wonder if it would make sense to hide the bulk action bar again as soon as no module is selected anymore. admin/content is showing the bulk bar all the time, but not sure if this is a desirable pattern since the bulk bar is sort of a visual distraction if someone has not checked a checkbox for any node why then show the bulk action bar on top of the content? the bulk action bar should only be shown if it is needed and in actual use imho. in particular on the project browser page you have already an information overload and having a bulk action bar shown all the time adds to that overload imho.

Left the comment: #3169876-33: Better handling of timezones for relative default date + times →

Due to the additional research and discussion, and the complexity of the topic the write up of the comment took a little bit longer. But I agree with the point @alexpott meanwhile made in #31 → , it is not only necessary to add the timezone to the default value on the field settings page, but also sort of required to add the point of reference aka the timezone to the node edit form as well. Otherwise the entry the user makes on the node edit form is just based on an assumption. That is also sort of in line with an article i’ve stumbled across a few days ago: https://simonwillison.net/2024/Nov/27/storing-times-for-human-events/. In the recommendation section the authors suggests to store the user’s intent time and the location/timezone. I suppose that suggestion is out of the scope for this issue but I consider it a more than reasonable one and would suggestion to open up a followup for it?

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-11-15 Active . The direct link to the recording of the meeting is https://www.youtube.com/watch?v=Yy18FL7GuvE. For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, and @simohell.

First we went through the tests outlined in #29 → , comparing the behavior of the relative default value field with and without the MR applied. We asked ourselves if the root cause for the odd behavior is the default value or how the field is getting interpreted, so we went ahead and did a few more experiments. First we tried adding a timezone to the relative default value field (which is not directly apparent) and noticed a few problems along the way:

Entering +2 Saturday 13:00 America/New York lead to the following error: The relative date value entered is invalid. Although the error message explains what went wrong, but at the moment it does not provide any solution how to resolve the invalid date value error - we have tried different variants of lower and upper case lettering for “New York” but no luck. In our explorations following up after the meeting we’ve realized that the timezone does not allow any spaces, you have to use an underscore, like +2 Saturday 13:00 America/New York, to be recognized as a valid date value.

We’ve noticed another detail about the capitalization of timezones. +2 Saturday 13:00 GMT+5, +2 Saturday 13:00 gmt+5, +2 Saturday 13:00 Gmt+5, +2 Saturday 13:00 UTC+5, +2 Saturday 13:00 utc+5, or +2 Saturday 13:00 Utc+5 are all recognized as valid when then field settings are saved. Problem is if you go to the corresponding node edit forms that are using the field with those timezones on the relative default values, the set default times are only shown for the upper case variants UTC and GMT, all other cases like gmt+5, Gmt+5, utc+5,and Utc+5, lead to empty fields only showing a placeholder value instead:

We then followed the strtotime-link in the description for the Relative default value field which lead to the documentation page https://www.php.net/manual/en/function.strtotime.php for that PHP-function. The page contains an explicit warning that the timestamp that this function returns does not contain any information about timezones.

Now that time zones are implicitly and explicitly used in the Relative default value field, we wondered how date and time is actually stored in the database. Turns out the default relative date and time value is stored as a string (for example +1 Saturday 23:00 or +2 Saturday 13:00 UTC+1), and on the particular node it is also stored as a string (for example 2024-11-16T23:00:00). So for the field settings the timezone is being stored if added by the user, while the string stored on the node is not containing any information about the timezone.

Due to subsequent discussions to the meeting in the #ux channel on the Drupal Slack, I’ve further expanded the test setup from #29 → to better understand the actual behavior: https://gist.github.com/rpkoller/9b4c93c28d1d97ccec404194e277f404. The first markdown file is the scenario from #29 → , for the second markdown file an explicit timezone (America/Los_Angeles) dissimilar to the site's and the user's was used, and the last three scenarios explicitly applied UTC and the timezones of the two users to the default relative date.
It turns out that if no timezone is explicitly set for the default relative date, Drupal is using an implicit timezone. Without the MR applied, UTC is used, while with the MR applied, the timezone of the current user is used. So the relative default value is using a timezone all the time, either implicit and not shown to the user or explicit if set and therefore changed by the user.

After getting an overview of the entire problem space, we came to the following initial conclusions:

• The currently implicit timezone for the relative default value should be made explicit and actually shown (*we haven't discussed the details about how the field should behave and be presented yet, but one thought that came to my mind during finalizing this comment- if the user isn't entering and altering the default timezone the default timezone should be added to the relative default value on safe). The site builder needs to be aware of the point of reference, no matter if the MR will use in the end the site’s timezone or the user’s timezone - each of the two options has a reasonable use case. The user simply has to be aware THAT a timezone is used and which it actually is.
• In the context of the timezone the problems listed above in regard of case and syntax should be tackled, to avoid those form errors as well as empty date fields on node edit forms that are missing the set relative default date and time.
• The description for the relative default value field should also be extended, perhaps providing an example based on the timezone for the relative default value and providing one or two example about the actual values shown on the node edit form to illustrate the implications.

In addition to that @benjifisher tried to get some advice from @mandlcu, as the maintainer of the smart date module, at Nedcamp → and will add the outcome in a comment on this issue.

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

benjifisher → credited rkoller → .