consentbox in region, e. g. aside

I like the implementation using a block.

I fixed a bug where it would append "null" to the block as well (because #klaro is not existent at that moment yet) + i also added the togglebutton to the block as well and added tabindex=1 to it, so it stays one of the firsts elements to be tabbed to even if the block is placed at the bottom.

Further i experienced several "z-index bugs" depending on which region you add the block, because the css was pretty much expecting the klaro block to be at the end of body, so i´m not sure whether this needs work in the module or if its up to the user then to style that region in their layout?

Nice to have: The Klaro-Block should be not reusable/only addable once?!

The Klaro-Block should be not reusable/only addable once?!

While this seems to make sense, there could be use cases where placing that block multiple times: when different conditions need to be applied it is sometimes required to place the same block several times, each of which with different conditions applied. In the end, it should still be placed only once, though.

If the block can be placed more than one time, we need to remove the fixed ID from template and use the class `block-klaro-block` as selector and iterate them.

@sasche: Could you please a new ticket for tabindex? I dont see the connection to this ticket. Did we evaluate the tabindexes? Should we prioritize the tabindex for the links in the notice-dialog at all?

I created a new merge request:

- klaro itself uses id-attributes so we can move only on one place. I added a help-text for this. Maybe the multiple blocks feature is helpful if you have multiple layouts with different regions.
- the block now uses classes.
- new options introduced to place toggle-button and klaro dialog in different blocks.

Please review.

A few questions and comments about the current state of the MR and the issue in general.

What is the accessibility need/requirement that makes it necessary to put the Klaro widget in an aside, footer or alike element, as mentioned in the issue summary?

Without the MR applied the button element is placed as the first child within the body element, therefore the button for expanding the cookie consent dialog modal is the first in the list in, for example the Rotor in VoiceOver - easy to spot for screenreader users. By placing the block in a layout region on the Block Layout page, the button is moved further down the DOM within the body element, making it potentially more challenging to find?

A few observations about the current state of the MR from a usability perspective. I went through a few different scenarios:

No Klaro block added

It feels sort of unintuitive and potentially confusing, no matter if you add a block on the Block Layout page or not, the Klaro toggle button is displayed in the bottom right corner of the page. From a usability point of view that is sort of an implicit behavior where the consent dialog modal is placed in any way. With something like the place block functionality in place, my expectation would be if no block is being added, there wouldn’t be any consent modal visible.

One Klaro block added

I’ve then added a Klaro block to the secondary menu. Left the display title checkbox ticked while i’ve unticked the place klaro consent dialog in this block and place Klaro toggle button in this block. That actually mimics the output in the DOM if no block is added. The button is the first and the div for the consent dialog is the last child of the body element. The unexpected detail the title of the block is not visible anymore, and there is also no empty element for the block in the secondary menu region.
And one question if the Klaro block, like in this case, is added to the secondary menu region, is it correct that the wrapping element for that block is a nav element?

And the micro copy of the choose klaro elements for this block is sort of unclear and redundant. technically the wrapping sentence Place …. in this block is sort of a slight variation of the title Choose … for this block. The title should describe the action and the checkbox label should only contain to what the action is applied to. Also the fact is omitted that if a checkbox is unticked those elements are placed at their default positions. Those consequences and implications are totally unapparent.

It also has to be noted that the block is behaving consistent for most of the regions it is being placed in, the sole exception is the social bar.

I suppose all those details in the context of Olivero and the social bar are out of the scope for this issue and are probably better suited for a follow up issue?

More than one Klaro block added

I’ve checked the aural interface and the Klaro button is only available once so that is a good thing - redundancy should be avoided at any cost. the only question i have to @jurgenhaas, what would be an example for having the need for more than one of those blocks?

So in summary, I am still drawn about this issue, since I am unable to see the pressing need in regards of accessibility voiced in the issue summary. It is nice to add some sort of flexibility in regards of where to place button and consent widget in the DOM. But that is rather making the discovery of those elements more difficult. And then there are the issue outlined in regards of the implicit behaviors as well as those with the micro copy.

From my perspective the benchmark for a good inclusive consent manager experience (out of the scope of this issue overall) is outlined in the following video by leonie watson: https://www.youtube.com/watch?v=Uaqo4FOI_DY so from my point of view the position for the toggle button as the first child of the body element is sort of ideal. I would only recommend adding an aria-haspopup=“dialog” attribute to the button, that way it would be announced to the user, by pressing that button a dialog modal will pop up. Because the button is not really a toggle button nor is the toggle state available in the aural interface (and that information wouldnt be really helpful in that case).
and the other point i would recommend is wrapping the consent dialog into a dialog element instead of a div with the role of dialog. the dialog element would have the advantage if the modal is shown/expanded, all the elements in the background would be excluded from the accessibility object model. that way a screenreader user would only have the element within the consent dialog available when coming to the page for the first time and or when the toggle button is pressed. no more search and a clear scope. i am considering to open an issue upstream in the klaro repo suggesting to introduce the usage of the dialog element.
But that is the reason why i am drawn about the issue and why it was rather complicated to summarize everything in a concise and coherent manner. Was struggling for a few days and still am uncertain if i've managed to summarize everything in a comprehensible manner. :/

wow, thank you @rkoller!

> By placing the block in a layout region on the Block Layout page, the button is moved further down the DOM within the body element, making it potentially more challenging to find?

Yes, you are right. But the user has the requirement to place the markup elsewhere in the DOM. The advantages are not clear to me personally either. Maybe it's about the semantic order in the DOM.

> my expectation would be if no block is being added, there wouldn’t be any consent modal visible.

Our aim is to ensure that Klaro can be used with as few settings as possible. The block function is just an additional function for repositioning in the DOM. We have written this again explicitly in the help text.

> The button is the first and the div for the consent dialog is the last child of the body element. The unexpected detail the title of the block is not visible anymore, and there is also no empty element for the block in the secondary menu region.

Could not reproduce. Maybe a caching problem?

> And one question if the Klaro block, like in this case, is added to the secondary menu region, is it correct that the wrapping element for that block is a nav element?

This is a special feature of this region in Olivero theme.

> And the micro copy of the choose klaro elements for this block is sort of unclear and redundant.

See new version please.

> I suppose all those details in the context of Olivero and the social bar are out of the scope for this issue and are probably better suited for a follow up issue?

Yes, I added a note for adding CSS code.

> I would only recommend adding an aria-haspopup=“dialog” attribute to the button

Thanks for the suggestion and the separate issue. I reviewed an merged already.

> I would recommend wrapping the consent dialog into a dialog element instead of a div with the role of dialog.

I am glad that you are contributing your detailed knowledge! You can open an issue here or we can do this - as you like: https://github.com/klaro-org/klaro-js/issues

Thank you at all for your long feedback. As a result, we agree that automatic placement is the best option and that placement in blocks only makes sense in exceptional cases. I have tried to clarify this again in the help text,

sorry for the delayed response but the last few days were a bit busy. i've tried to test your latest changes as well getting up to speed again before i reply to your comment. but somehow even with MR16 checked out i am unable to find a klaro block on the block layout page when i try to place a block? first thought something broke in my local test instance so i wiped everything, but the same situation after i've set up a new instance?!

Yes, you are right. But the user has the requirement to place the markup elsewhere in the DOM. The advantages are not clear to me personally either. Maybe it's about the semantic order in the DOM.

maybe @schwankde can shed some light what the accessibility requirement mentioned in the issue summary is, why the klaro element has to be placed in a particular region?

Our aim is to ensure that Klaro can be used with as few settings as possible. The block function is just an additional function for repositioning in the DOM. We have written this again explicitly in the help text.

yes i understood that step. but it still feels odd if you have no block added to have a certain behavior and then after adding a block one close to identical behavior is still in place. from a clarity perspective it might be the better choice to have in any way a block placed on the block layout page. per default in a way that mimics the current behavior of no block being added and the user then can adjust the position and the block settings and/or add another block. but i would still need to understand the need of placing the block in a certain region in the first placec. at the moment the entire feature feels overcomplicating things from a ux perspective without a clear benefit from an accessibility perspective.

Could not reproduce. Maybe a caching problem?

Here with a block regularly added with all the default settings set:

Here the scenario described where i've deactivated the settings within the block but left the block title ticked, that way the behavior is identical to when no block is placed but the title gets hidden even though it is set. (definitely an edgecase no one would really run into but still the outcome differs to what is actually set therefore i've noted it):

And the micro copy of the choose klaro elements for this block is sort of unclear and redundant.

See new version please.

Definitely an improvement. I think that goes into the right direction. A few more thoughts after seeing everything with a fresh pair of eyes. For one the checkbox labels both start with the word Klaro which is still redundant. I wonder if it would make sense to move the term Klaro also into the title. And strictly speaking those elements referred to in the title are not "placed" but rather "moved" from their default positions into the block, in case one or both checkboxes are ticked. So how about something like:

Which Klaro components should be moved into the block

then on the checkbox labels the name Klaro could be dropped. and one nitpicky detail. depending on the dialog setting one could have either a consent modal, or a cookie notice, being either a dialog or a dialog modal. The Klaro consent dialog setting sounds like "Require user action" is checked. So would something like "Dialog element" or "Dialog modal" instead work, which would be more neutral and potentially clearer? Because i have to admit it is really challenging to know how each of the three ways to display the dialog are addressed (same as grasping to what form it is referred to). By making that microcopy a bit less ambiguous and more clear i am trying to avoid the need for the user to read the long description (which most users rarely do and if they do only skim over it).

And in this context one other thought, would it make sense and be possible to add a progressive disclosure to the "Klaro toggle button" checkbox? Meaning showing this checkbox only if the "Show button to toggle the consent modal" is checked? that would also make the description "The Toggle Button must be enabled for this option." obsolete.

You can open an issue here or we can do this - as you like: https://github.com/klaro-org/klaro-js/issues

Will open an issue upstream in the next days when i've worked through my backlog of comments i have to write up.