Відео

Hah! Yeah, although it wasn't all bad because I got to see what the experience would be like for a logged out user. 😀

If you see the code, then it's not properly wrapped in a code tag. How are you adding it to your website head? Are you using a plugin?

This is completely true. The major problems with Bricks were in their core components - things like accordions, tabs, etc. are (were?) completely non-functional with a keyboard because they lacked semantic HTML. If you don't use those components because you code your own accordions or tabs or use a different add-on with better underlying HTML or you just don't use accordions or tabs at all, then your website may be just fine. This is really true for any builder - it depends a lot on what components you choose.

I'm sorry, I don't understand your tests. When I look at the code quality and semantics of Elementor, for example, I see a desert with lots of subgroups. No matter which components I use. Other builders, such as Bricks, are more elegant here and offer many options for adding attributes directly without activating additional plugins.

These tests relied on manual and automated testing. If you get access to the spreadsheet shared at equalizedigital.com/wordpress-page-builder-accessibility/ it provides exactly what was looked at for each component. For example, here are the items that were looked at for Tabs: - Tab controls container has role="tablist" - Tab controls are buttons - Tab controls have role="tab" and aria-controls - Current tab control button has aria-selected=”true” - Tab panels have role=”tabpanel” - Tab panels have aria-labelledby - Visible focus The native Bricks tab block failed all of these checks. At the time, that component was completely nonfunctional for people who don't use a mouse. (I understand that might be corrected now.) Can you build an accessible website with Bricks? Yes. But the point of this was to look at native components and see which ones got it right out of the box without requiring intervention. On that front, many other page builders did a better job than Bricks.

We appreciate the feedback and are working to make it less complex for content creators while still maintaining a robust solution for developers.

That really is too bad that they have decided to completely ignore a huge population, but I'm glad there are people like you who can help Divi website owners find solutions. I agree, Renee shared a ton of resources with the community! This presentation was above and beyond!

Yes, if you watch the video, Steve demonstrates how the menu sounds using VoiceOver, the screen reader for Mac.

Thanks for the question, @aceinspace671. We're checking with our dev team and will get back to you.

Pause on hover would require additional work because you would need to set it to pause on hover, change the button toggled state and text to reflect that it paused and then remove that action that unpauses the video on mouse off (because otherwise, it unpauses the video whenever you mouse off the video even if you have pressed the pause button).

I'm not sure, to be honest, because I haven't tested those. Do you have example links?

It really is super neat.

There could be a number of reasons. Check that they aren't artifacted, are in the Articles panel (if using that) or anchored, and that the PDF was exported as Interactive.

apparently the issue was that the buttons were in the master pages and the tags didn't export correctly. Is there any way to export buttons with correct tags if using Master pages?@@DesignDomination

@@gumilus Right, so that means they were artifacted. Anything on a master page is artifacted unless unlocked.

@@DesignDomination Ah, I see! So not much point on creating master pages for doing an interactive menu in a document and better to add it manually on every page, I guess?

Did you ever find a solution to this problem? I have the same issue but with a 200 page file and using buttons on the master page so absolutely necessary to keep them on there!@@gumilus

Yes, I think I am going to keep it for a really long time. 😁

Yes! The fewer opportunities you can give content creators to not make mistakes, the better.

No, ignoring things does not change the code on the website. So aria-hidden="true" would still be present on the element. Rather the "ignore" is just a way to mark in the plugin that you have tested the element and determined that it's not actually a problem. If the aria-hidden attribute was causing a problem and needed to be removed, you would need to edit the source code. That would then make the warning go away on the next scan of that page.

@@amber_hinds Thanks for the detailed information, appreciate it.

Hi Sal, what specifically are you hoping to see?

@@AmberHinds Hi Amber, I have installed the free plugin and have been playing around with it. Am considering going for the pro version soon. This is a bit new to me and was wondering if there was a walkthrough video of perhaps showing examples how to fix 2 or 3 pages from start to finish. I am more of a visual learner. 😊. Thanks.

Hi, Yes, there's code for this at gist.github.com/SteveJonesDev/ce8bf0219e4ebe5582454022e429ef07

@@EqualizeDigital Thanks a lot!!!!

Thank you@@EqualizeDigital

Thanks Beth!