<span class="aria-hidden"><?php echo Text::_('JALL'); ?></span> <span class="width-20">|</span> <span class="sr-only"><?php echo Text::_('COM_MODULES_GLOBAL_SELECT_ALL'); ?></span>

This results in a screen reader announcing

AllExpand the whole Menu Tree.

etc

Thank you @brianteeman . Seems It was too late yesterday.

Would be nice to get test here, only for step 1:

The button groups and the search input should be announced by the screen reader.

I have tested this item ✅ successfully on ee3e1cc

For step 1

I have tested this item ✅ successfully on ba3f721

I have tested this item ✅ successfully on ba3f721

RTC

Can you please remove RTC until the Accessibility Team have reviewed this. At least one part of it is the same as my previous PR that they rejected

The RTC status is going to remain. @chmst is on the accessibility team and is good with the change.

Thank you all. @brianteeman as I wrote, I continued your work and added the role="group" so that screen readers announce it all. And I made Buttons, because the original links were not accessible for colour blind. Hopefully I can do the next steps soon.

But the accessibility team objected to the use of buttons?

@rdeutz
I think buttons are much better than links.
But I ask myself why not using radio-buttons (switcher)
It is less code with the same effect ?
by Angie

@angieradtke Switchers or radio buttons are input fields and have two states. So suppose the screen is build and there are two or three menuitems selected. The the state of a swither is not defined. It is neither all nor none. So what to show?
These buttons don't show a state but they start an action. For me this is not the same.

So suppose the screen is build and there are two or three menuitems selected. The the state of a swither is not defined.

Makes sense to me.

The same issue we have with the state of the buttons. So if the situation is not clear the switscher is still gray - like it is if it has no selected value

and I forget the radio can look like button ( not like a switcher) .-)

I hesitate to use input fields as buttons. For me it is semantically not correct. After selecting for example all - the swither changes to "all". As soon as the user deselects a menuItem, it is not longer "all" and the switcher must be rest to "undefined". With every select/deselect, the swicher has to be justified. Then it would be ok.

Alternative: Make it simple and remove the buttons "menu assignment" from the screen

When the user comes to this screen, he has already decided that he does not want to assign all or none menu items

I think it is always good to use the HTML elements that are available to us to build accessible websites. The more aria we use, the more confusing and difficult it becomes to test and maintain. If you take the button version with the aria, the user will not know anything about the state of the selection. I think it's always a trade-off.
I built a very simple test-case .

Code / Live:
https://www.der-auftritt.de/kunden/joomla/radio.php
Whenever the user makes a choice, the selectbox can be reset to custom.
My thoughts .-)

I also suggested radio-buttons or switches. I think that would be best. But in the discussion @chmst pointed out to me that the option buttons (input type="radio") define the state. And here we have at least 3 states: all selected, nothing selected, some selected. When a user changes the state of at least one element, the state triggered by the buttons will change. And logically, it should be shown in these buttons". But that doesn't make much sense. Because the user wants to either mark everything, or deselect everything.
I've consulted with my friend the programmer. It was easier for me to explain in Polish. He confirmed @chmst's opinion that using option buttons would not be semantically correct.
That's why the solution proposes button groups. The user of the screen reader will hear the information he needs, but he must understand how this screen works. It's difficult.
If you could use radio-button/switcher, this would be the best solution for reasons of accessibility. But it has to be decided by the programmers.

Thank you all, I think that decisions must be made by disabled / blind users, surely not by programmers. We only can imagine to be blind or I can use a keyboard.

Thank you @angieradtke for the word customer, this is much better word than undefined :).
Now we could do this: If he selects all or none - we have a js which makes all checkboxes readonly. If the user clicks custom, the checkboxes are writable. Then the state always is indicated correct.

Obviously I think it is correct to have a button as that's what I proposed originally. It is a button because it is performing an action. I do not believe it is there to display a state. The consistent way to convey the state would be as we do with tables by using a sr-only text. As the action is performed without a page load then it should also be inside an aria-live block.

The buttons are there because it is helpful to change the whole selection with ohne click (otherwise the buttons are superfluos here as the user has already selected the custom mode). This is calling an action so like @brianteeman I think that buttons are correct.

But it might be a usefull information, also for sighted users, to know which button has been clicked (to know if all or none items are selected). This could be made with my idea of setting the checkboxes writable or not.

I think we must choose the implementation which is better understandable with sreenreaders, and which is better UX.

But it might be a usefull information, also for sighted users, to know which button has been clicked (to know if all or none items are selected).

Then it would not be a button but a display of state. It is not normal (or semantic) to use a button in this way.

The sighted user can see what has changed but if you think they wont notice all the checkboxes then take my comment about an aria-live region and make it visible to all instead of sr-only.

I repeat - these are buttons to perform an action - they are not to display a state

I apologize for the long lecture and the obvious statements.
What's this control for?
User have previously selected one of the options from the list:

• only on the pages selected
• only all except those selected

Now we let him have it, if he wants it:

• Group "Select:"
  • option1: all items selected
  • option2: no item is selected
• Expand group:
  • option1: all expanded items
  • option2: no item is expanded

These options prepare a list for him to continue working. At this moment, it does not matter to the user whether some items are selected or not. It does not matter whether some items are expanded or not.
The user can choose any option.
After the user makes a choice, the script executes the action: selects all items, or the opposite. It expands all items, or the opposite.

The user performs the next steps.

In summary: This control is not intended to record the current status. This control is intended to allow the user to select possible options.

In my opinion, nothing stands in the way of using the radio-buttons (switches). But I'm not a programmer. I listen to what programmers say. And that's why I wrote that it is the programmers who should decide whether to use the radio buttons. Dear Christine, a blind user will not decide that. He can decide if something is accessible to him and not if the coding is correct.

When I use the radio buttons, I don't have to explain anything to you. You know you have two options, and you can choose one. Both the user who sees and the blind user. The screen reader will tell the blind user which option is selected.

When I use typically buttons, the blind user must understand that using the second button changes the setting made with the first button. However, they do not get the message that this state has been changed. Of course, you can complicate the code and add aria-live. But, why?

So if you can use radio buttons or a switch, it's the best solution. But I won't decide that. A blind person won't decide that either. The programmers have to decide.

If I have to evaluate as an accessibility expert the solution that this PR proposes, I can say that this solution ensures accessibility. But another better solution can be used (eg. a solution with radio buttons).

So let me summarise what you are saying. This is perfectly accessible but you dont like it. I repeat what I always say. "It only has to be better than it was yesterday"

I think Stefan explained it perfectly.
Accessibility is always about levels of accessibility. Not for nothing we have A, AA, and AAA. And Stefan's explanation makes that quite clear. Thanks Stefan

My english is obviously failing

This makes things accessible as a first pass - that's better than not accessible :)

Unfortunately this PR was merged without looking at the code and only reading the issue.

that's better than not accessible :)

It is still not accessible

This pr correctly changed some links to buttons but it still has links that should not be links

Does it go somewhere? It's a link.
Does it do something? It's a button.

Secondly for some reason that I really can't understand and can only assume was made in error by @chmst and no one spotted it the header has been changed from h5 to h1 and then styled with css to be 0.8rem

As well as looking odd to have a heading smaller than the items it is a heading for, it is an h1 which I thought should only be present once on a page

Finally there is a z-index problem

cc @wilsonge @carcam tagging you as requested