In the pre-purchase sandbox, I created a page featuring a tab and an accordion component. I tested the completed page with Axe DevTools, which failed to recognize both components as either a tab or an accordion.
The Bricks marketing site headlines ‘unparalleled accessibility.’ This suggests to me that the Bricks engineers have incorporated accessibility into their modules. However, from what I observe in the code, this doesn’t seem to be the case at all. The accordion and tab widgets – representative of other complex widgets in the product – lack any aria tags, or at the very least, a role that defines what they are.
The claim of ‘unparalleled accessibility’ is far from truthful, or honest. While it may be an excellent, cutting-edge page builder, promoting a feature that it evidently fails to deliver on not only misleads customers but also potentially exposes them to serious risk of ADA lawsuits.
I will add, as someone who’s only kicked the tires on the product, if I’m misled and the production version does indeed check all of the WCAG guidelines and best practices I will apologize and purchase the perpetual license as penance.
I don’t doubt that the level of control and customization available for widgets makes it easy to manage accessibility.
I imagined this product to be comparable to Streamline, a popular CMS for local governments which produces near 100% accessible content out of the box, and doesn’t defer to the customer the responsibility to understand WCAG guidelines and aria principles to ensure the end-product is compliant.
I think you are talking about Global Components when that feature comes yes you will be able to do that easily.
you can make your components 100% compliant for the site and people can use those components and not worry about any accessibility problems just drag drop and fill content…
lets hope that feature comes soon not like WPML it took a year to develop
I read it and didn’t understand it. What exactly is the complaint against the developers?
Is it that you were not given ready-filled aria tags? It’s stupid in my opinion. Take it and fill it out the way you need it. And if you are not familiar with such nuances of website development, then why do you create them at all?
Everyone will use similar tags in different ways depending on their task. Some people need them, some don’t. It is impossible to solve for all at once.
Bricks developers are making a fundamental product, not fast food.
we have same views. ofcourse areas or titles shouldn’t be filled default. but global components will give us advantage when it is here. you missed my point. mike said gov websites and stuff global components comes very handy at those level of websites. anyway…
you are raging so easily you should go out and touch the grass
Not raging, just had high expectations for this FSE platform to have baked that degree of accessibility into the modules without leaving it up to us.
And trust me, unless you have years of experience or formal training in accessibility remediation, you do not know what you are doing, judging by your comment about peppering in aria tags at whim.
Yes the testing can be ridiculously complex, that goes into checking for accessibility compliance. I’ve been doing it for close to 5 years now, certified by DHS for Section 508 compliance, and still have to lean on experts in the Axe slack channel from time to time
The tone of your reply suggests you do not consider accessibility important, nor taken time to consider whether it might be important objectively.
The complaint is that ARIA controls for a number of well-known patterns (accordions, tabs, shopping carts…) exist and are not implemented.
Everyone will use similar tags in different ways depending on their task. Some people need them, some don’t. It is impossible to solve for all at once.
That’s true with a div, but not with accordions or tabs.
Take it and fill it out the way you need it
There’s more to it than that, and the interface is insufficient, too.
The demographic of my site’s visitors is mainly elderly so accessibility is important. I’ve tried to make my site as accessible as possible but fall down on tabs and accordions.
Bricks accordions and tabs should be accessible out of the box, I’ve raised this before (but Bricks have never answered) - not everyone is a developer. Other things are accessible out of the box so this is a standardisation issue. By default every element that Bricks produces should be accessible (if appropriate) from the moment of release. Frames (by Kevin Geary) has accessible tabs and accordions but I don’t see why I should subscribe to this just for this functionality.
It would be nice if for once the site visitor was considered and not the site developer.
most of the other builders doesn’t even have this much attribute/dom control
I never faced a time that I couldn’t make the accessibility scores 100 with bricks. I can easily make 100 every time with my builds.
I think that’s what is important.
I don’t want builder to make decisions for me. opinionated builders/doms always creates mess on html. that’s for wix or squarespace not for bricks.
Bricks is a versatile page builder. It is not an accessible page builder, should not be marketed as an accessible page builder, and certainly not with such hyperbole that it is unrivaled as an accessible page builder.
Why does it matter, you might ask. Look up Bashin vs Conduent, a case involving a blind camping enthusiast who successfully sued the California Dept of Parks and Rec for over $2 million dollars over an inaccessible website. What’s interesting her is both the state AND the web developers were found culpable. Why? Because the web developers made false and misleading claims that the product they were delivering to the state was fully accessible, when in fact it was just the opposite.
Accessibility isn’t a feel-good thing, it’s the law. Companies who work for the government are required by law to procure accessible products and services. A web contractor stumbles onto Bricks, is sold on the accessibility pitch and builds a government site, all along believing that Bricks builder is producing conformant code. Then, this shiny-new federal website is hit with one or more ADA Title 3, Unruh or other claim from a disabled user - or a predatory law firm that searches for inaccessible websites - and then ask yourself if the web developer will escape liability. Bricks will probably skate, since most software is provided AS-IS, hence probably why they’ve elected to keep the accessibility marketing above the fold.
What I want is for users who have vision impairments to be able to use the keyboard to navigate from tab to tab, accordion level to level and also to links and buttons within the tab/accordion content. I don’t think custom attributes are going to help with that.
