Feature: Add checkbox buttons (NcCheckboxRadioSwitch buttons that look like NcButtons)

[susnux]

☑️ Resolves

• Resolves [BITV] 9.4.1.2/3.12 - The "Details" section contains a favorite button, but its status is only available to visual users. A possible solution would be to provide the status of the button through an accessible name or to use toggle buttons. (2) nextcloud/server#37109

This allows to create checkbox buttons -> Make NcCheckboxRadioSwitch with button variant look like NcButton.
Checkbox buttons are required when you use buttons to toggle a state, e.g. the favorite "star" button on the app sidebar is a button but only shows its state visually. For a11y the button should be implemented as a checkbox instead.

🖼️ Screenshots

Checkbox buttons

vokoscreenNG-2023-06-27_13-29-40.mp4

AppSidebar favorite button

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable

[jancborchardt]

Looks good! But should we show so many possible options, like Primary, Secondary, Tertiary, Tertiary without background?

Only secondary and tertiary are really used, are they? @szaimen @marcoambrosini

[susnux]

Looks good!

Thank you :)

But should we show so many possible options, like Primary, Secondary, Tertiary, Tertiary without background?

I just took all button styles we provide for NcButton to keep is consistent (and to allow checkbox buttons to replace all kinds of plain buttons).

[juliushaertl]

If we expose the button with text only as a checkbox button shouldn't it then have a visually clear indicator that it is in a checked state?

[marcoambrosini]

Instead of adding a new pattern just for this, can't we do the same as we decided for the text tool bar and switch the favourite items from secondary to primary? This seems to me like an analogue use case?

[susnux]

@juliushaertl

If we expose the button with text only as a checkbox button shouldn't it then have a visually clear indicator that it is in a checked state?

Good point, but how would this look like? Adding a border?
(I think different background does not work because we only of the hover state with defined values)

BTW: We could also make the font bold if checked, but I think the button will then resize on click.

[susnux]

@marcoambrosini

Instead of adding a new pattern just for this, can't we do the same as we decided for the text tool bar and switch the favourite items from secondary to primary? This seems to me like an analogue use case?

What do you mean with a new pattern? For the first change the idea was that we already have button styles of the checkboxes, but they do not look like buttons, so for consistency they should look like NcButton.
The second change (favorite button) is an a11y fix, it was also a secondary button previously, but I am fine with changing it to primary.

[marcoambrosini]

What do you mean with a new pattern?

By "pattern" I mean a new way to solve this problem. Since we decided to switch to primary for "selected" or "activated" looking buttons elsewhere, I would stick to that everywhere else too.

we already have button styles of the checkboxes

Could you point me to places where we have this?

@nextcloud/designers what do you think?

[susnux]

By "pattern" I mean a new way to solve this problem. Since we decided to switch to primary for "selected" or "activated" looking buttons elsewhere, I would stick to that everywhere else too.

Sound good, is there a styleguide for this somewhere? Because I like the idea but have this questions:
The default is secondary and enabled is primary? Would be tertiary be possible? Is the enabled state for tertiary secondary or primary?

Could you point me to places where we have this?

You can already use <NcCheckboxRadioSwitch :button-variant="true" type="checkbox">Some button</NcCheckboxRadioSwitch>

[marcoambrosini]

This is not documented yet as we took this decision rather recently. The activated state is always primary as it needs to meet certain contrast requirements that the secondary button doesn't meet. And yes it's possible to have a tertiary and activating it by making it primary, that's exactly what we're doing in the text toolbar :)

[raimund-schluessler]

This is not documented yet as we took this decision rather recently. The activated state is always primary as it needs to meet certain contrast requirements that the secondary button doesn't meet. And yes it's possible to have a tertiary and activating it by making it primary, that's exactly what we're doing in the text toolbar :)

If we implement this behaviour in this PR here, I think that would be the ideal solution (meaning not allowing all kinds of button types, only primary for on and tertiary for off). Then we would have a dedicated component that behaves the way we want without the dev having to implement it manually. Also, it would be syntactically the correct element (a checkbox), that looks like a button. A button behaving as a checkbox, does not seem right to me.

[susnux]

@marcoambrosini Ok I now changed it to not allow primary and only use it for the enabled state, what do you think?

vokoscreenNG-2023-07-04_21-23-56.mp4

[marcoambrosini]

I don't think this should be within the checkboxradioswitch component. This component already has a lot of use cases and many different styles associated to it. And more importantly, these are not checkboxes, they're still buttons. @raimund-schluessler sorry, I misread your comment before: these will not be used inside a form and will not require any further action to make the changes effective. This is just 1 action that just gets performed immediately. Just like in the action menu we add to favourites with an action button, I think we should use plain buttons here.
I think that the best way to go is to just add a prop to the button component to "activate" it and force primary when we do so.

[susnux]

I think that the best way to go is to just add a prop to the button component to "activate" it and force primary when we do so.

Well the primary issue why I created this PR is that a normal button is not the correct element to use for having a state. Because changing it to primary only changes the visible state, ideally you use native elements like the checkbox which already has this state for accessibility.

[marcoambrosini]

We can add the aria-pressed=true to the button. This adds a state to it and seems to be how this problem is usually solved.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-pressed

This is also how google does it in their docs toolbars and I think it makes a lot of sense for the text toolbar and the favourite button too. Maybe we can call the button prop pressed to directly reference the attribute.

Screen.Recording.2023-07-05.at.18.46.55.mov

[jancborchardt]

Do we have an update on this? :) Since accessibility issues are quite important to fix, it’s often good to go with the most pragmatic solution first and refine in iterations.

[marcoambrosini]

@jancborchardt I can add the pressed state to the button component myself if that's ok. This would flip the colors to primary and be fully accessible. It seems to be the more widespread solution to this problem.

[susnux]

If we use the "pressed" option on the NcButton, we maybe want to disable the button styling on NcCheckboxRadioSwitch (meaning only allow it for any grouped checkboxes like the sidebar tabs). Or what do you think?
Because otherwise we have two components doing the same but looking completely different.

[susnux]

Superseded by #4344

[marcoambrosini]

If we use the "pressed" option on the NcButton, we maybe want to disable the button styling on NcCheckboxRadioSwitch (meaning only allow it for any grouped checkboxes like the sidebar tabs). Or what do you think?

Could you please point me to some examples of where that's used @susnux?