Adam Lowe of Peak Performance Digital recently conducted a test on Menu accessibility across builders in WP.
He comes with deep understanding of accessibility and he always tries to implement best practices in all his projects. He uses Pinegrow Builder which comes with complexity to control the markup and implements the practices manually. I think Cwicly should also participate in this comparison. It will be good for visibility and we will also get feedback if any shortcomings. @Louis
Adam tested Cwicly and it scored poor in the test. @Louis took the feedback and improved the accessibility in one day. That’s some great commitment to the builder. Hats off!!! 126.96.36.199
On the contrary I have similar requests open in Zion & Bricks which are yet to get some attention from ages now. Says the difference!
Thanks for that, much appreciated
Indeed the overview of the menu block by Adam Lowe was not positive, and while a rework was planned, this definitely put it at the top of our list.
The menu block should now tick most accessibility boxes but, as always, if you do pick up on any accessibility issue, I’d be grateful to know so we can get them fixed as soon as possible. Thanks!
Hey there, @Louis.
I’m just exploring the changes that were made and there are some great improvements!
Could you explain why now the
<nav> tag is now the default one?
I was hoping for a more flexible solution, like selecting the tag by myself, where it would be totally fine when the
<nav> tag is the default one.
- The navigation often includes more than the menu (block) itself
- Not every menu is a navigation
While there was the workaround to wrap the menu block inside another div and set the right tag, now it feels even more restrictive.
I missed the option to set a custom tag on the menu block from the beginning and already pointed that out here 1-2 times.
Do I miss something here? Any feedback is appreciated.
Thanks for your post.
Indeed, we chose to force the
<nav> tag by default as what came out from Adam Lowe’s review, for me at least, is that main accessibility points should be defaults.
Of course, Cwicly can’t do everything, and we shouldn’t force a specific use. Accessibility in this case is a joint venture between the web developer and his tools.
This means that with 188.8.131.52.2, you can select your own tag if you don’t want the default
Thanks for bringing this up @Marius.
Cwicly did another update adding tab navigation as pointed out in the new video. It’s the most accessible wp menu out there now. Amazing job @Louis
Thank you @Louis for finally addressing this and give us the opportunity to tweak things more precisely. Much appreciated
I couldn’t agree more and the
<nav> tag is the correct decision in this case.
Maybe this is the right moment to discuss the section block as well.
Accessibility wise, in my opinion, the default
<section> tag is an issue.
It might not be the best approach in general, also when it comes down to the semantics (pointed that out in the section block discussion as well).
Again, this is a great statement which I just can emphasize.
Cwicly is not responsible for everything and it’s simply not possible to cover all potential use cases.
At the same time, it tells me exactly why the section block shouldn’t have the
<section> tag enabled by default.
The developer has everything which is needed inside Cwicly to make appropriate adjustments.
On the other side, users who are not aware of this topic and use the section block without any further tweaking do harm their accessibility - and SEO.
It’s used for the base structure but it’s fully incompatible without further adjustments due to the
<section> tag situation.
There are basic requirements as well which needs to be fulfilled and can’t be expected from the average user.
The majority of users are no developers and/or not accessibility aware.
Cwicly should support them in the most appropriate way out of the box (which is already the case and being cared of in most instances I want to stress).
This is not a professional expertise, it’s a subjective viewpoint.