Would it be possible to improve things here?
I had a look at the code and see what the issue is, so I have doubts there is too much space for improvements. Seems like it was designed for dedicated open/close triggers only, not for toggling.
But also not sure to what extent you are able to modify the libraries you are using for Cwicly, so who knows.
Maybe at least a modal trigger click timeout that inherits from modal animation duration? Not the best approach but better than nothing, I guess.
Hi @Marius,
Very good point, a bit like our current Slide Up/Slide Down interactions (but fixed with the accordion block).
I have been planning on moving away from the current libraries we use (for simple things like this) and doing it ourselves.
This is easy stuff to write up and will allow us to provide a lot more control, while also maintaining things a lot better.
Your comment confirms what I’ve been pondering!
These are very good news @Louis.
You mentioned all important points that were buzzing around my head, so nothing to add here.
Highly appreciate the way you plan to handle it in the future 
Just found out about the changes that were made to the modal block.
Is this a temporary solution, if I might ask?
I really appreciate the efforts to improve the animation behaviour, especially switching from keyframe animations to transitions.
The problem now is that the modal is set to display:block, independent of its current state.
So when using the keyboard, users will tab through modal elements which are invisible to them when the modal is not active.
Hi @Marius,
No it isn’t a temporary solution. I’m sorry you find it so.
The tabbing is something we can have a discussion about, but I went through long discussions with someone who is quite well versed in all the accessibility part of things and I was told that it was very important to keep the modal accessible, which means that in no circumstance can it be hidden from the end user.
The problem in the Cwicly specific case is that the markup is loaded inside other blocks, which means that the tabbing will be affected when such situations arise.
We’re looking at the possible solutions for this (moving it once loaded), but I do want to emphasise the fact that the modal cannot be hidden for accessibility reasons (also allowing non-javascript enabled sessions to access them).
Hope that clears thing up a little.
@Louis, I have to apologize here.
In fact, I clearly missed the listing in the patch notes.
I thought changes were made some time ago and I checked a Cwicly version (1.2.1) which I literally downloaded 1.5 hours before these changes were introduced with a new version.
So, I was confused that I thought all these changes were made, and you were still relying on the same library - which obviously isn’t the case.
That’s where my original thought of a temporary solution came from, hope that makes sense.
Thank you for these insights and clear things up - I can follow what you are saying and can see the situation isn’t that easy, as the entire accessibility topic.
I might add some thoughts as soon as I found out how things work in detail.
My previous post relied on false assumptions, so can’t bring valid points on the table yet.
But due to the fact the modal block relies on transitions now makes it so much more flexible.
Excited to find out what’s possible!
@Marius, please don’t apologise!
I really appreciate your feedback (as does the team and I think the community) and always consider your suggestions and remarks as I know they have been thought out by you.
In this particular case, your observations are once again correct and there is space for improvement. 1.2.1.4 should alleviate the issue with tabbing as we’re now moving all block elements near the end of the body tag.
The library (micromodal) we were using has indeed been removed, as we are now working with our own small logic that allows us much more flexibility and a compatible vision with how the builder works.
Accessibility and modals is a tricky combination, so we more than welcome any remarks/suggestions you might have.
Hi @Louis,
I appreciate you fully focussing on accessibility. Other builders have half baked implementations, some ignore it or have invalid implementations just to call them accessible. I’ll check the update log for 1.2.1.4 now.
Thanks for your kind words @Louis, this really means a lot 
This is a smart approach in terms of improvement which pleases both sides, the accessibility and UX side.
Still, I think this should be optional. There are cases which it makes sense and it’s kind of necessary, for instance the navigation. So why not a dedicated block option? Not sure if a general option would be a good solution either.
I also see an issue when placing the modal outside of the wp-site-blocks container, since it’s out of (Cwicly) users’ control then.
Dependent on specific use cases this can lead to limitations or unexpected issues in case one isn’t aware of this behaviour.
I might be wrong here (I’m aware it’s a fixed positioned block), but I have concerns.
Manipulating the page structure when the user has no influence to this behavior, it is not something I’m a fan of.
Could you also clarify when exactly (event) the modal is moved?
I have to agree with you here, I believe that there won’t be a perfect solution, it’s just not possible. Optimizing one aspect will most likely harm another one.
Compromises are required I guess, let’s find out what fits best to Cwicly.
What @dranzer is saying, I can only emphasize as well.
I always had the feeling this important topic is being treated with the necessary and required diligence.
What I can say now, it’s not only a feeling anymore.
@Louis There is also a dialog tag which you might you wanna take a look. Having an open dialog | scottohara.me
After testing things out, here are my points:
Html tag changes will be applied to cc-modaler container.
Instead, I would expect that for the parent cc-mdl container
What @dranzer mentioned. I can’t see any (a11y related) changes on the modal when active/inactive, only the active class gets toggled.
I am aware it’s visible at any time but isn’t there some feedback for the user missing?
The backdrop overlay is an anchor link. Is there a reason?
I’m not sure about that, so a quick explanation will help
Already wrote some lines above in that regard.
Moving the Modal Block should be optional per block option.
And when moved, it should still be targetable via native Cwicly (RS) options, at least with the general sibling selector. Moving it outside the wp-site-blocks makes no sense for me and in general makes no difference but the mentioned limitation.
It was mentioned before, I think this would be useful for advanced creations:
Separate animation durations for entrance and exit animations
Advanced control about the body overflow rule when closing the modal.
Sometimes it is useful to keep the body overflow hidden until the animation has finished
Transition delay for the .cc-mdl .cc-modaler container.
Separated options, entrance and exit
Thanks for your thoughts on this @Marius, much appreciated.
This can be opened to debate and ends up asking the question where the modal “content” really starts. Do you consider that when you modify the tag on the modal block, you are modifying the container itself or more specifically the content wrapper?
I’d love to have your suggestions on a11y enhancements here. Currently, I can’t seem to find official directives on what a “modal” should contain like attributes.
As I see it, a modal is a visual way of showing a section or element. Therefore, should we even notify users who can’t play with this concept that the modal is being toggled on/off?
This is meant to be a fallback in case js is not supported for whatever reason (you can trigger the modal appearance with its ID, no js needed at all). The link default behaviour is disabled when js is supported.
Not so sure about this. The modal should be considered to be outside the main content since its visual role is to be hidden by default.
If you put the modal inside wp-site-blocks, it is possible to interfere with global parts that don’t fall inside wp-site-blocks.
This is not a fixed decision, and I’m happy to revisit where we place the modal markup.
I get your point here and the current behavior seems to make sense.
I’m not completely certain yet, but looking at the HTML (structure), it’s fine as it is.
Don’t want to sound too picky, just noted some general thoughts to explore the general idea behind and I’m glad you picked some of them.
I’m following the a11y topic closely, but I’m far away from making any serious suggestions in that regard.
Maybe at some point, all interactive blocks could be reviewed by an independent and subject-related party?
That’s the only proposal I can make.
Thanks a lot for explaining in detail.
I’ve already seen it inside the CSS, so it makes perfect sense.
Great composition of the block, as already mentioned.
Very interesting point. That was not on my radar at all. You got it totally right here.
To be honest, I wasn’t aware this is even possible.
Seems like there is plenty to explore yet inside Cwicly.
Still, there should be an option to opt-out, but I’m fine with it if that won’t happen.
One last thing:
I see the necessity to make sure that the focus will be restored on the initial modal trigger button after closing the modal, independent of the closing method.
Currently, it remains inside the modal (when interacting with it in its active state), which sits at the very bottom of the document.
Thank you @Louis.