@N6REJ Please fix css coding style:
https://github.com/joomla/joomla-cms/actions/runs/33954530021/job/101275559328?pr=48378

Is it for this issue #48376?

there is no need to add useless css

Before this PR

With this PR

I have tested this item 🔴 unsuccessfully on 1a03bca

I have tested this item 🔴 unsuccessfully on 1a03bca

Is it for this issue #48376?

yes

Before this PR

## With this PR

thanks for that.. I've reverted the .css changes
But wouldn't it be better if all icons were centered?

@brianteeman thanks for that.. I've reverted the .css changes
But wouldn't it be better if all icons were centered?

Before this PR

## With this PR

thanks for that.. I've reverted the .css changes

Before this PR

## With this PR

thanks for that.. I've reverted the .css changes
But wouldn't it be better if both icons were centered?

@chmst is there anything else I need to change?

I have tested this item ✅ successfully on 9f999af

While this PR in a very strict sense meets accessibility requirements as the link has been changed to a button and the toggle functionality is intact, from a usability perspective it's pretty confusing. This isn't a result of your work directly, @N6REJ, although I am getting interesting visual display in Firefox which I'll share in the next comment.

The name of this control is "Toggle Menu" and it may leave a user wondering what exactly they're toggling, since the menu is expanded in the default state however the icon beside it indicates that it isn't toggled. When the toggle is used, the functionality of the menu doesn't change and the menu collapses, but the graphic changes to the toggled state. This seems backwards to me. Not sure what exactly a user is "toggling", basically, apart from the text labels of the menu.

Hence, the name of the control itself could use a change to better describe the effect of the toggle. For example, "Collapse Menu" is a better name, as the screen reader output would be "Collapse menu, toggle button, not pressed" in the default state, as opposed to the current "Toggle menu, toggle button, not pressed" which causes some confusion, as it may leave users believing that the menu won't be reachable unless it is toggled...but it already is.

Again, these suggestions of mine aren't strictly required to meet accessibility requirements, but I believe that users, both sighted and not, will benefit from a clearer label for the control. If the name changes, to something like "Collapse menu", the icons don't need to change either, since in their current states they'll make more sense.

Again, not my decision to make, but putting it out there for maintainers and contributors to think about. From my perspective, the accessibility changes in this PR strictly meet accessibility requirements (although visual presentation is askew in Firefox).

I have tested this item ✅ successfully on 9f999af

While this PR in a very strict sense meets accessibility requirements as the link has been changed to a button and the toggle functionality is intact, from a usability perspective it's pretty confusing. This isn't a result of your work directly, @N6REJ, although I am getting interesting visual display in Firefox which I'll share in the next comment.

The name of this control is "Toggle Menu" and it may leave a user wondering what exactly they're toggling, since the menu is expanded in the default state however the icon beside it indicates that it isn't toggled. When the toggle is used, the functionality of the menu doesn't change and the menu collapses, but the graphic changes to the toggled state. This seems backwards to me. Not sure what exactly a user is "toggling", basically, apart from the text labels of the menu.

Hence, the name of the control itself could use a change to better describe the effect of the toggle. For example, "Collapse Menu" is a better name, as the screen reader output would be "Collapse menu, toggle button, not pressed" in the default state, as opposed to the current "Toggle menu, toggle button, not pressed" which causes some confusion, as it may leave users believing that the menu won't be reachable unless it is toggled...but it already is.

Again, these suggestions of mine aren't strictly required to meet accessibility requirements, but I believe that users, both sighted and not, will benefit from a clearer label for the control. If the name changes, to something like "Collapse menu", the icons don't need to change either, since in their current states they'll make more sense.

Again, not my decision to make, but putting it out there for maintainers and contributors to think about. From my perspective, the accessibility changes in this PR strictly meet accessibility requirements (although visual presentation is askew in Firefox).

This is the visual presentation I get in Firefox after applying this PR: the "Toggle Menu" button is half the width of other controls in the menu. Maybe a one-off, but input from other testers would be welcome to verify this:

The expected behaviour is that it's the same in all browsers so you should not be recording a successful test

why is this suddenly failing unit tests?

The expected behaviour is that it's the same in all browsers so you should not be recording a successful test

Since I'm not touching css now this shouldn't be an issue with my "fix"

The expected behaviour is that it's the same in all browsers so you should not be recording a successful test

Since I'm not touching css now this shouldn't be an issue with my "fix"

yes it is as you jave changed from an a to a button so different css is applied

and i get the same problem in chrome

The expected behaviour is that it's the same in all browsers so you should not be recording a successful test

Since I'm not touching css now this shouldn't be an issue with my "fix"

yes it is as you have changed from an a to a button so different css is applied

and i get the same problem in chrome

before

after

I have tested this item 🔴 unsuccessfully on 9f999af

I have tested this item 🔴 unsuccessfully on 9f999af

Good points above, @brianteeman and thanks for confirming presentation on Chrome. Is there any CSS styling that can be applied to unify the visual presentation?

Also, is it helpful to neutralize my previous successful test with an unsuccessful one? Net zero, and so on.

Good points above, @brianteeman and thanks for confirming presentation on Chrome. Is there any CSS styling that can be applied to unify the visual presentation?

Also, is it helpful to neutralize my previous successful test with an unsuccessful one? Net zero, and so on.

Same presentation failure in Edge as depicted below:

@mbeganyi-a11y yes - you clearly did not have a successful test so you should at least remove the success or makr it as a fail. makes me wonder why you thought it was a success in the first place. you cant test joomla just by looking at code

Everthing should be resolved now.
Firefox

Chrome

please fix css code style issues https://github.com/joomla/joomla-cms/actions/runs/35988412671/job/107597084403?pr=48378

@N6REJ Thanks for updating your commits, however I don't get a visible indication of focus on the new button when focusing it with keyboard. Do you? Focus indicators exist in Firefox for all other menu items, though. Did focus styling disappear somewhere in the process? The visual presentation looks good, though!

I have not tested this item.

I have not tested this item.

@brianteeman completed
@mbeganyi-a11y tabbing now shows focus

@N6REJ Thanks again for your work. I'm noting that the focus indicator is blue while the others in the menu receive a white focus indication. I checked in Chrome and Firefox. The two images below show the blue focus indicator on the Toggle Menu and the white on other items in the menu. These images show the menu in Chrome.

@N6REJ Thanks again for your work. I'm noting that the focus indicator is blue while the others in the menu receive a white focus indication. I checked in Chrome and Firefox. The two images below show the blue focus indicator on the Toggle Menu and the white on other items in the menu. These images show the menu in Chrome. Sometimes these things can be finicky, so don't get discouraged!

@brianteeman completed @mbeganyi-a11y tabbing now shows focus

no it doesnt - you obv didnt check https://github.com/joomla/joomla-cms/pull/48378/changes#r4103994117

@N6REJ I'm taking a look at this and from what I can piece together, the fix requires including the new toggle button in the existing CSS rules for the sidebar items instead of creating new rules and focus styling.

Since the toggle is now a native , please try extending the existing Atum sidebar-item selector to cover the button rather than adding a separate button style. This will preserve the old link presentation while retaining correct button semantics. Again, from what I can detect, it's easiest to update the SCSS source instead of creating new rules.

@N6REJ I'm taking a look at this and from what I can piece together, the fix requires including the new toggle button in the existing CSS rules for the sidebar items instead of creating new rules and focus styling.

Since the toggle is now a native < button >, please try extending the existing Atum sidebar-item selector to cover the button rather than adding a separate button style. This will preserve the old link presentation while retaining correct button semantics. Again, from what I can detect, it's easiest to update the SCSS source instead of creating new rules.

@mbeganyi-a11y IF you can help with this it would be greatly appreciated

When i go to the 3 dots i can go to 'Explain Error' - i cannot know if your account can do the same.
The problem is:
Error from the log:

At line 94, column 7:
Expected "text-align" to come before "border" (order/properties-order)
So the CI lint step exited with code 2 because SCSS property ordering doesn’t match the project’s lint rules.

Suggested fix
In _sidebar.scss, move the text-align declaration above border in that rule block (or run stylelint with --fix locally if your setup supports it), then push the updated commit.

When i go to the 3 dots to the right of the error - more actions - i can go to 'Explain Error' - i cannot know if your account can do the same.
The problem is:
Error from the log:

At line 94, column 7:
Expected "text-align" to come before "border" (order/properties-order)
So the CI lint step exited with code 2 because SCSS property ordering doesn’t match the project’s lint rules.

Suggested fix
In _sidebar.scss, move the text-align declaration above border in that rule block (or run stylelint with --fix locally if your setup supports it), then push the updated commit.

@N6REJ Happy to try to lend a hand here, and I've spent some time trying to get the focus indicator to match the rest of the sidebar, but I can't seem to get it exactly the same. I am not a CSS guru, admittedly, so if anyone could help us here please, that would be wonderful.

The only thing I can get to work consistently is creating a # focus-visible subclass and specifying details there. I have gotten a focus indicator for the toggle that matches the colour of the sidebar links, but is visible on all four sides due to the subclass outline-offset of -2px.

Now I would argue that this (or any) focus indicator is better than having none at all (as is what I see in Joomla 6.2) but I'd value input from the community to help decide on the best path forward. This may not be optimal for a couple of reasons:

1. This introduces new CSS as opposed to extending CSS from the sidebar links to buttons in the sidebar (as going this method for me didn't yield any really usable result).
2. It is inconsistent with the focus styling elsewhere in the sidebar, but not elsewhere in the interface. For example, the "Take a Tour" button has a 4-bordered focus indicator. Given that this is now a button also, is this an acceptable implementation?

Below are the focus indicators I've made versus the standard ones in the sidebar:

Focus 1: The new indicator on the Toggle button (button replaces anchor and adds aria-pressed):

Focus 2: The standard sidebar focus indicator

Focus 3: New collapsed menu state focus indicator

Focus 4: Standard collapsed menu state focus indicator

All input is welcome.

alternative PR #48696

This pull request has been automatically rebased to 6.2-dev. Joomla! 6.1 is now EOL.

This pull request has conflicts, please resolve those before we can evaluate the pull request.