Nürnberg, Germany
Account created on 7 May 2015, almost 9 years ago
#

Merge Requests

Recent comments

🇩🇪Germany rkoller Nürnberg, Germany

For the records, @charles-belov (Thanks to him for taking the time) tested the navigation module to validate if there are any concerns with animations in the context of vestibular disorder. His conclusion was: I'm not seeing any animation concerns in either mobile or desktop.

.

🇩🇪Germany rkoller Nürnberg, Germany

@charles-belov tested the navigation against vestibular disorder for 🌱 [PLAN] Accessibility review Active . In addition he also left a few additional notes in the context of usability in general:

  • Mobile now triggers at a narrower width. The same width that was triggering mobile layout and behavior yesterday now displays desktop. I now have to set the browser to about 2/3 width to trigger mobile layout and behavior. (Note:For context, when he first tested the day before, from some reason his browser had a too narrow width triggering the nav pattern for mobile, making him think, and worry, that pattern would be the sole way to interact by mouse).
  • I'm not seeing any animation concerns in either mobile or desktop.
  • I'm noticing the behavioral differences between mobile and desktop. Specifically mobile requires a click to go to the next menu level. Desktop displays the first level on hover and the second level on click. I believe your usability team already identified the hover/click inconsistency.
  • I agree with your usability team that would be better to give the user the option as to whether to expand on hover or on click when in desktop layout.
  • There does seem to be a delay on the hover expansion in desktop. However, I think it's too brief, as the expansion of happens if I move the mouse at a moderate speed. I have to move the cursor quickly to avoid the flickering of submenus appearing and disappearing, and that's not necessarily something I would do.
🇩🇪Germany rkoller Nürnberg, Germany

The day before the UX meeting the attendees of the Drupal Dojo Austin tested the navigation module. For the record the attendees were: Buster Neece, @cutehair, @rocketeerbkw. I think adding a comment about the results to this issue is the better choice, that way all the relevant points are collected in a single place instead of splitting everything into separate issue, plus one point is confirming a problem raised in the UX meeting (see the note in the issue summary):

  • The title within the drawer wasn't considered click-able. It looked like a header with no affordance being a clickable link.
  • If you are on a desktop and the viewport width is narrow enough that the sidebar switches to the navigation pattern for mobile it is impossible to move with the cursor within the sidebar. The drawer is immediately triggered on hover and the drawer is overlaying the sidebar.
  • Moving the mouse cursor horizontally in the navigation pattern for desktop is more cumbersome, challenging, and taxing than moving vertically for some attendees.
  • Having just a single submenu expanded, in particular in the context of the configuration top level menu item, was considered challenging for new users and people with a small working memory. To know and remember which sub menu item contains which sub-sub menu items.
  • If only the user navigation block is available and the submenu for the username is expanded on larger screens, the button at the bottom and on top submenu inside the drawer are in no in close proximity and challenging to reach with the straw test.

Overall @rocketeerbkw summed it up nicely. If you compare the navigation menu with the current toolbar in Core it is a no brainer. He would switch immediately without a thought. But if you compare the navigation to the admin_toolbar, from a his perspective the hover functionality in the horizontal admin_toolbar was perfect for him. He was able to easily reach every part of the admin ui with ease quickly. With the navigation that experience in the context of hover isn't that flawless yet.

🇩🇪Germany rkoller Nürnberg, Germany

After a bit of a back and forth I'll add two more UX related feedbacks to this issue. I'll change the title again to reflect that and to make this issue a collection of those results. The issue summary i keep reserved to the outcomes of the usability meeting I only add notes in case other results are confirming points made in the meeting.

🇩🇪Germany rkoller Nürnberg, Germany

forgot to add the video. apologies :/

🇩🇪Germany rkoller Nürnberg, Germany

thank you for the update @bronzehedwick. i've applied the latest changes but somehow i am still able to reproduce being stuck. somehow i am able to trigger the behavior faster when i hover and or click a top level menu so a drawer expands and collapses and after that i go on navigating up and down through the top level menu items. for the video i've activated the keyboard viewer so you are able to see my keyboard input. and in addition i see the following type error in the console:

[Error] TypeError: undefined is not an object (evaluating 'focusableElements[focusedIndex-1].focus')
	(anonymous function) (js_Ez2GMQcuGAO5zipRlKWSB0V0jT7lLqDrF3Fi0L4o6dY.js:1970:3557)

hope that helps.

🇩🇪Germany rkoller Nürnberg, Germany

thank you! I've quickly tested against the four points that got fixed in #32 📌 Ensure keyboard navigation works with the drawer Active . in "general" they work but i've found some odd behavior:

1&2) yes in it general it works but the problems are:

  • in safari moving by the arrow keys through the top level items sometimes just stops working and i am unable to move up and down anymore (in edge and firefox i was unable to reproduce that)
  • there is some sort of active trail for the top level menu items (see safari.mp4 - reproducible in edge and firefox)

3) for top level menu items moving by character works for sub menus it does now
4) works - the only odd thing pattern wise, similar to the mix of hover for top level menu items and click for sub menus is the fact that with left and right you are able to collapse and expand the drawer but within a drawer left and right have no effect and you have to press space on a sub menu.

update: oh @skaught already set it to rtbc while i was writing up my comment. due to the active trail shown in the video i would set it back to needs work. if you would move the work on that newly introduce behavior to the follow up as well then put the status back to rtbc.

🇩🇪Germany rkoller Nürnberg, Germany

big +1 for the megaphone. bells are about getting your attention and notifying you about a certain event plus a bell icon is the most common image used in the context of notifications across the web as well as operating systems. while a megaphone you are are using to "tell something to the world" which is happening here, the drupal association is announcing certain details.

🇩🇪Germany rkoller Nürnberg, Germany

I've already commented over in the recent corresponding thread on the drupal slack.

I am not sure if the mockups in #4 📌 Improve the categories filter type in context to the rest of the filter component ui Active are actually solving the problem. To associate the categories sidebar with the horizontal filter bar just by color is probably not enough (and also not in line with WCAG 2.2 SC1.4.1).

One of the key points and my main take aways from a recent webinar by the smashing magazine on search ux was “filters should be above search results”. Reason is when filters appear in the sidebar they cause layout shifts so users have to refocus every time they set a filter, and with the project browser ui there is a a refresh of the search results on every tick and untick. the recommendation was, which i agree to, to show applied filters and other relevant filters above/before the results. One approach, which would change the entire filter section might be the following:
Instead of a button (currently called filter and in the mockup in #4 called advanced) and instead of those chips add only four select fields, (categories, development status, maintenance status and security advisory) each containing a list of checkboxes or radio buttons. one site that is applying that pattern for example is: https://www.nejm.org/search?q=health&isFilterOpen=true (in case of project browser the filter wouldnt have to be hidden like on nejm.org)

the advantage would be you would get a clear separation of concerns for the whole project browser page. first you have the search box where the person enters the search term, second the filter bar with four select fields where it is possible to narrow the scope, then you get your number of results and your sorting options as well as the display style (grid/list) and finally your list of results - no more category sidebar mixed with the search results. clear and and way more easy to comprehend that way. plus all elements you are able to filter by are in the same proximity. in addition you could also drop the expandable drawer where the settings are listed as three radio button sets, also no clear separation of concerns plus on wide screen monitors you have huge gaps between each radio button set.

in regards of the select fields illustrated with the nejm.org example you might even consider adding an apply button to each of the select fields. that way you wouldnt fire a new query and an update of the search results on every tick or untick of for an category. from a sustainability perspective you would save cpu time as well as bandwidth and at th same time you go easy on the cognitive bandwidth of your user and you only provide an update to the list when all the decisions where taken on a select field.

the longer i think about it the more i like that approach. a cleaner untwined interface which is way easier to comprehend imho.

🇩🇪Germany rkoller Nürnberg, Germany

There are only two concerns i have. For the first i've already opened up a follow up issue in the context of keyboard and screenreader accessibility (will add another comment about the needs for sighted keyboard users there as well).
the other detail is about the dot, but that concern shouldnt be a blocker for this issue. overall it is difficult to communicate with just an icon that the user should hover over the icon (when i first saw the dot i thought some icon was missing - like for a missing unicode glyph) . creating another follow up issue wouldnt make much sense since that issue wouldnt be actionable and with the navigation issue queue moving over into the core issue cue soon it would be cruft for the time being. @ckrina made a note about the dot and will continue ideating on it over with the folks in the design team. therefore no followup issue necessary in this case. therefore this issue could be set to rtbc

🇩🇪Germany rkoller Nürnberg, Germany

One idea I've posted over in the #sustainability-team channel on the Drupal Slack, and @catch suggested there to repost it in this issue as well.

There is the following linting tool: https://github.com/ausi/respimagelint which provides recommendations about the used image sizes as well as the syntax of img srcset and the picture element. I wonder for a while now if it wouldn't be possible to adjust the algorithm of respimagelint to enable Drupal Core to auto generate a list of image styles for the installed default theme? For the default theme you know all the breakpoints across viewports and the syntax for img srcset and the picture elements, shouldn't it then be possible, instead of just optimizing image sizes, to auto generate a list of image styles from the ground up? But I am not a developer therefore i am uncertain if that might be a reasonable approach?

🇩🇪Germany rkoller Nürnberg, Germany

So far i haven't noticed it anymore. Only problem is it happened only occasional before, meaning for a while i haven't run into it then a few times in a row, still don't know what actually triggered it. so it "might" be fixed, looks promising, but not definitely sure. Maybe we could keep it open for a few more days and in case i dont run into anymore i close it as outdated.

🇩🇪Germany rkoller Nürnberg, Germany

One problem to note, if you try to tab through the collapsed sidebar, menu block titles are not focusable. with tabbing that structuring element is unavailable to screenreader users. the only cue screenreader users have is that there are four headers by default (in case the display of title is active):

shortcuts
content
administration
rkoller

just based on the announcement it is not clear that those are actual section headers, you would need the visual context. in addition tabbing is the only way to get all the menu block titles as well as menu items in consecutive order. in the voice over rotor the components are scattered, the block titles are headers, top level items with a sub menu are buttons and top level items without a submenu are links.

🇩🇪Germany rkoller Nürnberg, Germany

i have had added this issue to the shortlist for todays usability meeting, but yesterday a request for the review of the navigation module came in. since they try to get it into core as experimental we've discussed the navigation module today. we hopefully find time next week or i might pick the brains of the other regulars during the week.

my main concern about the new group here was twofold. for one the new group Block is created with only a single page Block Content Settings in it and that single page has only a single interface component, a checkbox Standalone Block Content URL on it. on the other hand i think we should be mindful about the number of categories/groups available as well as what types there are. the majority is currently organized by topic/general function, not many are based on an actual entity type/module? media for one but that contains not only pages for the media module but also anything related to images and files.

🇩🇪Germany rkoller Nürnberg, Germany

Moving over the issues from last week:

🇩🇪Germany rkoller Nürnberg, Germany

Created an issue for the feedback: 📌 Drupal Usability Meeting 2024-04-05 Needs work and also created a follow up issue for the problem with the navigation block titles on multilingual: 🐛 The default original strings of a navigation block could get populated by another installed language Active

🇩🇪Germany rkoller Nürnberg, Germany

rkoller created an issue.

🇩🇪Germany rkoller Nürnberg, Germany

no all those three settings were set within ms edge (@mherchel provided the instructions for this handy feature testing high contrast mode a while ago on slack if i remember correctly). you have to add the render tab either to the quick view or move it to the activity bar on top in the ms edge devtools:

and i then only set and adjust those three settings highlighted:

🇩🇪Germany rkoller Nürnberg, Germany

forgot the mobile viewport. made a few additions to the issue summary

🇩🇪Germany rkoller Nürnberg, Germany

thank you! this morning it happened to me in safari without voiceover active. has not really anything to do with voiceover i suppose. but a consistent pattern i was unable to figure out yet. i've applied the MR from your linked issue and will see if i am still able to run into the glitch. but since i never ran into the glitch from this issue in edge which is chrome based i am unsure if both issues are related. i am not sure. will see how the usage over the day will turn out with MR227 applied

🇩🇪Germany rkoller Nürnberg, Germany

With the introduction of the drawer this error doesn't happen anymore. also the shortcuts arent expanding anymore if a bookmarked page is open. I'll close as outdated.

🇩🇪Germany rkoller Nürnberg, Germany

based on #23 📌 Ensure keyboard navigation works with the drawer Active i've updated the issue summary

Menu bar:

space/enter :
behaves correctly

down arrow:
fails - the down arrow jumps not to the next top level menu items instead it jumps to the next top level menu item only that has a submenu and is expandable. if you tab to a top level menu item that has no sub menu item the down button has no effect and is unresponsive
works - if i reach the username at the bottom and press the down key another time the shortcuts top level menu item is in focus next

up arrow:
fails - the up arrow jumps not to the next top level menu items instead it jumps to the next top level menu item only that has a submenu and is expandable. if you tab to a top level menu item that has no sub menu item the up button has no effect and is unresponsive
works - if i reach shortcuts at the top and press the up key another time the username top level menu item is in focus next

right arrow:
fail - the drawer expands but the first sub menu item is not getting into focus

fail in addition try the following. get the reports top level menu item into focus, press space, the drawer for reports expands, press now the up key and configuration gets into focus, press now the right arrow, the configuration drawer opens underneath the still open reports drawer

left arrow
fail(?) - if the top level menu item is collapsed and you press the left arrow nothing happens, while if the drawer is expanded and you press left the drawer closes. but the desired if you press the left arrow and the drawer opens and you get the last sub menu item into focus doesnt happen here.

home
works - ctrl fn left jumps to shortscuts on the mac

end
works - ctrl fn right jumps to the username on the mac

character
fails - i have content in focus and press m as well as M, no reaction. ahhhh just noticed. it has the same problem like the up and down button the character applies only to top level menu items that have a submenu. therefor m had no effect. if i type s i first jump to shortcuts if i press is another time i jumps to structure.

Submenu:

Space/Enter:
fails - if you press space or return und a parent the focus remains on the parent instead move to the first item in the submenu
works - pressing space or return on menu items without a submenu forwards to the linked page

esc
works - closes drawer and moves focus to the parent top level menu item that opened the collapsed drawer

Right arrow:
fails: within the configuration submenu for example when the focus is on system and you press the right button nothing happens
fails: fi you are in the structure submenu and you have the media types menu item in focus and press the right button nothing happens

Left arrow:
works (?): if block types menu item is in focus in structure and you press the left button structure gets into focus

but the focus isnt moving to the previous to level menu item in the menu bar

fail (?) if a sub sub menu item is in focus and you press the left key not the parent sub menu item gets into focus but the parent top level menu item
down arrow:
fail - it only works for the configuration submenu, which is the only that consists of menu items with sub menus. that way i am able to move down and after workflow i get back up to people

up arrow
fail - it only work for the configuration submenu, which is the only that consists of menu items with sub menus. that way i am able to move up and after people i get back down to workflow

home
works - ctrl fn left jumps to shortscuts on the mac

end
works - ctrl fn right jumps to the username on the mac

character
fails - in submenus characters dont work at all not even for sub menu items that contain another submenu

a few more details i've noticed:
the menu item for shorcuts in the drawer is not reachable by keyboard but only by the mouse cursor. same for the username menu item in the username drawer (plus view profile, edit profile, and logout are missing the focus outline). same for the sub sub menu items they are also missing the focus outline.

🇩🇪Germany rkoller Nürnberg, Germany

hm i haven't noticed that the issue got in yesterday. but testing it now with the latest version of 1.x-dev in edge on macos (enable automatic dark mode ticked, forced-colors active and prefers-contrast:more) the icons, the icon within the expand and collapse button, the carrets as well as the right border of the drawer are barely visibly or invisible (in case of the right border) :/

🇩🇪Germany rkoller Nürnberg, Germany

@ckrina the problem with the focus and VO-cursor still persists. in safari they remain separated as long as no new keyboard input happens while in edge and firefox there is the short delay as described in the conversation on slack by @bronzehedwick. i still have to do some research (asking on the a11y slack and or safari folks on mastodon), should i open up a followup issue as soon as i get news or should i already open up a one outlining the problem in case someone else comes along knowing how to fix this?

🇩🇪Germany rkoller Nürnberg, Germany

One detail in the context of keyboard navigation i wonder if it would make sense to add is the ability to close the drawer by pressing the esc key. at the moment you have to tab through the entire sub menu, the configuration sub menu requires quite a few tabs to get out.

On a side note not directly related to keyboard navigation but i've noticed while testing that several menu items miss focus outlines. without any patches applied to the 1.x-dev branch of the navigation module the logo, sub sub menus (for example the menu items underneath configuration -> system), and the sub menu items (view profile, edit profile and log out) for the logged in user are not visible. the username isnt tab-able at all, only clickable by mouse.

🇩🇪Germany rkoller Nürnberg, Germany

ohhhh thanks for clarification, completely forgot that the navigation might use a different font than the main content area!

🇩🇪Germany rkoller Nürnberg, Germany

@quietone raised 🐛 Fix the label and description of the new "view update notifications" permission Needs review on the #ux channel, it is a followup issue to another issue we've discussed before in #3284204: Drupal Usability Meeting 2022-06-10

🇩🇪Germany rkoller Nürnberg, Germany

I'm afraid this is something we can't solve? I's guess this is a font problem.

but if you take a look into the main content area in https://www.drupal.org/files/issues/2024-04-03/hebrew.jpg you have actual bold typography as well, so it isn't the case that heavier weight isn't available for the font used?

🇩🇪Germany rkoller Nürnberg, Germany

I've tested the issue with Hebrew. One detail i've noticed is that the font weight of the top level menu items is too small compared to for example english

similar for the drawer:

🇩🇪Germany rkoller Nürnberg, Germany

in Bezug auf #7

Wir benötigen aber eine Möglichkeit, Projektbetreuer auf fehlerhafte Quellzeichenfolgen hinzuweisen, wenn das in Zukunft gelöst werden soll. Ein Mechanismus diese bereits beim vor Release einer neuen Modulversion zu erkennen fehlt. Genau wie eine Routine, die vorhandene Pot/PO Dateien auf eben solche Fehler überprüfen kann und eine entsprechende Liste generiert.

Wäre es evtl. nicht die elegantere Variante Übersetzer*innen schon beim Abspeichern des Übersetzungsvorschlags auf unerlaubte Zeichenfolgen hinzuweisen, so daß solche problematischen Zeichenfolgen erst gar nicht erst in der Datenbank abgelegt werden? Das würde auch Maintainer*innen extra Aufwand bzgl etwaigen Korrekturen im Nachgang ersparen.

🇩🇪Germany rkoller Nürnberg, Germany

Adding Add view tab + standard template for block content Needs work to the list, @larowlan tagged it for ux review and carrying over the two remaining issues from last week @smustgrave raised in the #ux channel:

🇩🇪Germany rkoller Nürnberg, Germany

thank you for the quick fix, I've manually tested and and can confirm the behavior is as expected now. i've tested on the configuration menu and only one submenu remains open at a time.
i've only noticed one detail i am unsure if it is possible to be fixed. if you are having voiceover active then the voiceover cursor position remains at the position the submenu item was before it got expanded. so you have the voiceover cursor and the focus outline in two different places.

🇩🇪Germany rkoller Nürnberg, Germany

I've successfully applied MR213 against navigation 1.x-dev, havent run in any issue unable to reproduce the error experienced in #10 📌 Change the wording for the Top Bar checkbox Needs review .

I really like the change to invert the checkbox suggested by @keyboardcowboy in #6 📌 Change the wording for the Top Bar checkbox Needs review . Also adding the term experimental in parenthesis to the checkbox label is good call.
My only nitpick is about the description, in the current suggestion the first half of the first sentence is sort of redundant to the checkbox label. "The Top Bar is an experimental feature" is more or less repeating and only slightly rephrasing "Show Top Bar (experimental)". In regards of the second sentence "This is part of a larger push to simplify and modernize the editorial interface." I am not sure if this is very helpful for the user? I wonder if it would make more sense to articulate that the top bar doesnt provide the full functionality. the term experimental in the checkbox label communicates it is far from being finished but from my perspective the second sentence should also communicate hey the top bar will be placed there but dont be surpised that it doesnt contain the full functionality yet and might not that useful to you at the moment?

A suggestion: Provides relevant administrative information and tasks for the respective page. It is not feature complete nor fully functional.

🇩🇪Germany rkoller Nürnberg, Germany

Just rechecked. Comments were already done and also the the link to the recording as well as the transcript is in place. Setting it to fixed

🇩🇪Germany rkoller Nürnberg, Germany

Left a comment on the issue #2418755-106: Path alias filter by system path . Feel free to add or correct anything I've missed. Was more than tricky than I thought to summarize everything.

🇩🇪Germany rkoller Nürnberg, Germany

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-03-29 Needs work . The recording can be found at: https://www.youtube.com/watch?v=1xmloMqjaw0.

For the record, the attendees at the usability meeting were @AaronMcHale, @BlackBamboo, @benjifisher, @rkoller, and @shaal.

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

There was a general consensus around the group having separate filters on the URL aliases page is a good and useful thing, since there are particular cases where it is useful being able to restrict and target the search for one particular column. So this feature is a definite improvement to the current state. We've found a few noteworthy details:

  • The terminology is inconsistent on the page. h1 and page title use URL aliases, the help text and field set label alias, the place holder path alias, and the table column header again alias. Changing the h1 would entail potentially many changes to the docs. Therefore the idea was simply to adjust the term used for the placeholder (path alias) and change it to alias. That way the usage of the term alias on the page for the help text, field set label, placeholder and column header is consistent and could also be considered as the shorthand of the overall title URL alias used in the h1 and page title.
  • In a similar vein, there is also an inconsistency for the path terminology. A detail we've missed during the meeting and I've noticed while writing up the comment. The help text is using the term URL path while the placeholder and column header is using the term system path. In the subsequent discussion on Slack there was a clear consensus between @benjifisher and me that this should ideally be consistent. But which of the two would be the better choice we were uncertain about - it would have to be further discussed and tested. It also has to be added that both terms URL path and system path are both used more or less equally across Drupal Core. One detail in favor of URL path, URL path and URL alias would be a consistent pattern for both of them and URL provides the overall context. But still the recommendation is to move the discussion to a mandatory follow up issue.
  • The group agreed to the concern raised in #103 . On the instance we've tested and discussed the issue on I've created a few nodes and corresponding path aliases with no multilingual modules installed. After installing a second language aside English the language column showed none for all those already existing URL aliases, and the select field with the default option - Not specified - mentioned by @catch showed up.
    If technically possible the group agreed recommending removing the placeholder text and use labels for the two input fields as well as the select field instead. That way the context would be at least easier to grasp for the default option of the select field.
  • In regards of the options - Not specified - and - Not applicable - the meaning of those options was not clear to the group. At first we thought none applicable would equal to nodes with language none but turned out it resulted in no results at all. Same if you add a string to the url alias field or system path containing strings used on one of the language none nodes. Somehow you get no result at all for - not applicable -. But since the two terms are not only used for the URL aliases filter and that ambiguity also applies to other pages and contexts, we've agreed to create a follow up issue to discuss that micro copy problem more holistically and make those two options more comprehensible in regards of function and meaning.
  • Speaking of the more holistic context, if you compare the filter options on for example admin/content with the options available on the URL aliases page you also notice for one that the filters on the content page also have an - Anything - option and those not specified and not applicable options don't come along with dashes but - Any - is. And on the other hand the content page is using labels for fields and select fields.
    Taking a look at the MR @benjifisher noted that the select field is using a standard form element while the filter on admin/content is a View. So we wondered if it would make sense ensuring a consistent population of the select field alongside other detail on the page if it would be make sense to make the URL aliases page also a View? But completely out of the scope for this issue, but in case others on this issue agree to open up a follow up issue.
  • During the testing we've also noticed one odd misbehavior of the reset button. If you try the following:
    1. Add a term to filter for in the alias field
    2. Press the filter button
    3. Clear the field with the inline clear button
    4. Press the filter button

    problem: all URL aliases are shown but so is the reset button that remains shown, but it should be hidden instead.

🇩🇪Germany rkoller Nürnberg, Germany

This issue was raised as the issue of the day in the #bugsmash channel yesterday. At first thank you for raising the issue @zeroplexer! I've read through the issues summary but a few details are not clear to me. Could you perhaps elaborate what you are exactly referring to and what your point of reference is, meaning in which theme you've noticed those issues? If the issue is just about saving the amount of tab key presses until one reaches the main content as mentioned in the steps to reproduce section then Claro as well as Olivero already provide that kind functionality - on the first tab press the user gets the Skip to main content link. On the other hand you refer to " have the title field in focus" in the proposed resolution section, which might be a more reasonable request. if you take for example node creation pages there is no focus at all after the initial page load and it might be helpful and speed up the interaction if the first field in the form gets into focus which is the title field most of the time (at least in the context of content types). a similar pattern is recommended for dialog modals where it is a good practice in the a11y context to either bring the close or the first input element into focus. If you could clarify your points that would be fantastic. I'll change the status to Postponed (Maintainer needs more information) aka PMNMI for now based on the recommendation of @quiteone on the thread (i am not that familiar with the process). after updating the issue summary, clarifying the points in question, the issue can be set back to active again. thank you!

🇩🇪Germany rkoller Nürnberg, Germany

Carrying over the issues from last week @smustgrave raised in the #ux channel:

🇩🇪Germany rkoller Nürnberg, Germany

i've applied the MR200 to the navigation module with latest changes in including the drawer issue, and in my case sticky is working

🇩🇪Germany rkoller Nürnberg, Germany

one detail i've noticed, if you open up a submenu you then have the label of the top level menu item as the "heading" now. That heading is clickable by the mouse but it has an invisible focus outline when you tab through the menu by keyboard (ref wcag sc 2.4.7 - focus visible).

🇩🇪Germany rkoller Nürnberg, Germany

and @skaught raised Enable/Disable View within View Edit page Needs review on the #ux channel again

🇩🇪Germany rkoller Nürnberg, Germany

And I've added the feature flags api issue also as a related issue

🇩🇪Germany rkoller Nürnberg, Germany

thank you @acabremley!

The good thing about the solution design is that there's nothing we really need to do for the API - it already exists (modules). So mainly we just need to confirm how these things should be formatted. I.e how the module name should be constructed, and how we convey the information about the feature flag - e.g should we use a module description, hook help, or something else.

that sounds way less complex and controversial than i've initially thought. i was slightly worried it might become a rather long going issue before an initial approach could get in. awesome!

It would essentially replace the config check with a moduleExists check. All the current behaviours of upgrades vs new sites would be the same. Instead of setting the config in the upgrade path, we'd enable the module. New sites wouldn't have the module enabled by default so they would default to the new behaviour, etc.

so the module would be the "switch" the equivalent to the current "checkbox" . but then the manual step before enabling the module for existing sites upgrading from 10.2 to 10.3 would still be necessary to make sure that it doesn't comes to an unintended removal of blocks in layout builder like in the example from the issue summary: "For example, if you have Layout Builder enabled on a Node bundle (Content type), and that bundle's display is using field blocks for the User entity (e.g the Author's name), but Layout Builder is not enabled for the User bundle, then that field block would no longer exist after disabling this setting." . but the danger for that case happening would be still imminent isnt it? so it might be necessary and an idea that those "feature flag" modules come along with a confirmation step pointing to potential issues the person installing has to be aware of and has to take care of before proceeding? that information step could be either informational like in the current example (where the preperational step might be too complex) or if possible that confirmation step might contain a configuration option that changes something? so that in some less complex cases the user would be able to alter something in place within the confirmation step preparing the site before going on?

re #7 and a good point @aaronmchale made. i wonder aside the fact to clearly define what the functionality should exactly do maybe also being mindful not to already use the current suggested name as the working label. i haven't paid close attention to the name yet but the example where feature flags is actually used for activating highly experimental features could be definitely misleading and creating wrong expectations. perhaps it should be considered to find a different name which describes the functionality better. maybe having a bulleted list outlining what the feature actually does might be helpful ideating on a suggestion which might be a better less misleading fit?

🇩🇪Germany rkoller Nürnberg, Germany

nice thank you! I've just manually retested with 🐛 Sticky table header is not sticky if --drupal-displace-offset-top is not defined Fixed and only MR200 for this issue applied (tested also with both MRs applied before the Claro issue went in) on a fresh install of 11.x-dev, the sticky headers both on /admin/content and /admin/people/permissions are correctly shown without any offset sticking to the top of the page. I've also tested with MR201, visually the same effect, the sticky table header is shown without any offset.

🇩🇪Germany rkoller Nürnberg, Germany

After some more research and a discussion with @joaopauloc.dev on slack i'll update the four follow up issues listed:

5. remains the same - i will finish a draft soon
10. the scope is slightly different, a follow up issue is need, but the * gets added if the weight is changed by a number field the * is added while if the change happens via a select field the * is not added.
11. i would drop the task entirely, for one it might be confusing for none sighted people if the fields are dynamically reordered right after the value is changed and on the other hand @mgifford said the drag and drop functionality probably would have to be rebuild from the ground up anyway since it isnt scaling well in its current form. according to him the current form was intended as a short term fix in D7.
12. add the prefers reduced motion with no preferences media query already within the scope of this issue. it is an easy fix since the animation related parts have simply to be wrapped within this media query plus moving it to a follow up wouldnt make too much sense since there wont be a single centralized place to fix that animation problem, it has to be solved in each component anyway it looks like.

🇩🇪Germany rkoller Nürnberg, Germany

hm i wanted to take a look how the proposed icon behaves in the interface but after successfully applying the changes (the new svg is in place where it is supposed to be) i am still seeing the old icon for example on /admin/structure/types/manage/article/display

🇩🇪Germany rkoller Nürnberg, Germany

There is a new problem that surfaced in the context of the new navigation module. The following issue illustrates a problem with stick headers 🐛 The sticky header has an offset Needs review . with both MRs applied, the one in the claro queue and the one in the navigation queue the table header is scrolling past the filter field set overlaying it:

🇩🇪Germany rkoller Nürnberg, Germany

updated the remaining task. marked a few as done and removed number 24 which becomes obsolete with the switch button pattern

🇩🇪Germany rkoller Nürnberg, Germany

rkoller created an issue.

🇩🇪Germany rkoller Nürnberg, Germany

thank you for explaining your points! and yes I disagree in this case, but i will try illustrate my arguments with a few screenshots (something i should have already done in my initial issue summary).

First in regards of the primary button. There are several examples across the admin ui that have two primary buttons, one to save the configuration form and one for adding something. Two examples are:


Both have a primary add button adding an object to the draggable area underneath. The suggestion making the button a primary button was mainly due to consistency reasons since more or less all add buttons across the admin ui are blue primary buttons.

And in regards of the draggable area i meant the following. The block layout page is sort of a special case from my perspective. one of the very few cases where it makes "sort of" sense to have some kind of "section headers" within the block list containing each the label for the block region and the place block button, which provides the convenience that the block is directly placed into the block region the button is pressed. but these highlighted block region rows are in contrast to the other rows not draggable (they even miss a drag handle):

Same for the row on the navigation blocks page, that row with just the place navigation block button is also not draggable but in contrast to the block layout page it doesn't contain any sections. That is the reason why i've thought it would make sense to move the place navigation block button out of that table. it just feels out of place there.

One compromise might be to move the button out of the table but instead of making it a blue primary button keep it as a grey regular button? but as i said the suggestion making it a blue primary button was based on consistency reasons.

🇩🇪Germany rkoller Nürnberg, Germany

changed the remaining task section from an unordered to an ordered list to easier address and reference the different points

🇩🇪Germany rkoller Nürnberg, Germany

thanks for the fast turn around! yep i agree technically both variants work and as you said save and activate "slightly" sounds better but in regards of consistency Save and switch is the preferable choice imho. plus i've just noticed back then in the ux review we've also agreed on Save and switch (ref #15 📌 Creating a new workspace should also switch to it Needs work ). So this issue looks good to go from a manual testing perspective, but not sure if i am eligible to rtbc it or if still someone has to take another look at the code?

🇩🇪Germany rkoller Nürnberg, Germany

while writing up a comment to another issue in the workspaces queue i realized one detail that is missing for screenreader users. After a brief search i've rediscovered this one (already forgot it existed and i've already commented on)

One detail that might be considered to be added to the current MR which might help screenreader users tremendously is adding the active workspace to the title tag in the head. Currently the title is:

[h1] | [site name]

that might be change to:

[h1] | [active workspace] workspace | [site name]

so that you get for example when you are on /admin/structure/types

Content types | Stage workspace | My Drupal site

The title might become a bit verbose and lengthy but that way all the necessary information is frontloaded, LTR from the specific to the more general (the screen reader user is able to jump off at any point). that means first you have the h1 then the active workspace and then finally the site name. and since screenreaders get the page title announced when loading a page the overall context would be provided satisfying WCAG 2.2. SC 2.4.2. (i've added also the tag wcag242)

🇩🇪Germany rkoller Nürnberg, Germany

thanks for implementing the suggestions! i've manually tested, overall it looks good, there is only one small detail i've noticed. The newly added button Save and activate is using the verb "activate" while on the workspaces overview page Switch to... is used on the buttons with "switch" as the verb. Technically if you click the Switch to... button on the overview page you get "Activate the ... workspace" on the confirmation page step. For the Save and activate button that confirmation page step is not necessary and the workspace is directly activated which is a good thing. But still that inconsistency of the used verb might be potentially confusing to users and being consistent here might help?

🇩🇪Germany rkoller Nürnberg, Germany

that is an interesting idea @acbramley! i would have two questions in regards of the feature flag api.

  • what is the estimated timeline for getting that api into core? it doesn't look it would be ready for 10.3.0 and with 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review already in core the problems outlined in issue summary for this issue would still apply to users for the time being until feature flags get in?
  • and how would the feature flag work in the context of this feature? sites pre 10.3.0 would behave like the checkbox is ticked while sites after 10.3.0 would behave like the checkbox is unticked? if that assumption is correct, the only problem is see is the transition and upgrade from 10.2.x to 10.3.x. Currently you have the configuration page that sticks to the ticked state after the upgrade and the user/admin has to manually untick and switch the behavior. with a feature flag in place that option wouldn't (?) be available and the behavior would change with the upgrade to 10.3.0? isn't then there the danger of blocks being removed from layouts automatically as outlined in the change record?
🇩🇪Germany rkoller Nürnberg, Germany

sorry for the late reply @omkra.podey but i had to wait before i got word from the others who ideated on the aria-label suggestions with me. i've now manually tested the patch again another time:

It is a good choice that you've readded the hide and show password button in #277 📌 Replace confirm password field with show/hide functionality Needs work . It is definitely useful for the login page in the front end. the only nitpick i've noticed in claro there is the eye icon, that icon is missing in olivero in the front end. but this minor styling issue might moved to a followup issue?

in regards of the aria-label Password invisible it is definitely an improvement over make password visible making the label more clear. I still had some doubt after actually testing it with voiceover because Password invisible from a grammatical perspective sounded slightly off and something like Password invisibility, on would feel more grammatically correct as @Emma Horrell put it. But the term invisibility has the downside that it is too complex and invisible conveys the meaning adequately. So the arial-label seems good to go. And there is always the option to simply change the string of the aria-label at a later point based on user feedback and running some user test like for example a one two punch user test. But that could be done in a follow up issue if necessary and shouldn't hold back this issue.

this issue looks good overall

🇩🇪Germany rkoller Nürnberg, Germany

We reviewed this issue at 📌 Drupal Usability Meeting 2024-03-15 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @blackbamboo, @rkoller, @simohell, @SKAUGHT, and @worldlinemine.

Per @larowlan's suggestion in #142 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review I've created a followup issue summarizing the outcomes of our discussion: 📌 [meta] Improve the "Expose all fields as blocks to Layout Builder" feature Active

🇩🇪Germany rkoller Nürnberg, Germany

Bringing over the issue I've raised for last week : 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review i still consider important to discuss and to do some wordsmith

And @smustgrave brought up a few additional issues over the course of the last few days in the #ux channel:

Production build https://api.contrib.social 0.62.1