Yeah, so from the look and analysis of Bubble’s own marketplace app, the accessibility is at 60%. This affects Google’s ranking. We all want to rank higher in the Google search algorithm and besides that comply with WCAG standards or risk a lawsuit. In this thread, I’ll highlight how my Bubble App achieves a near-perfect score on accessibility. I’ve some contrast issues so once resolved I’m looking at 100% accessibility.
NB: This thread is for developers developing products that require WCAG compliance.
1 Like
UserWay and Accessibe Plugins Fail
So I installed these plugins on separate occassions and thought to myself okay. My site is now accessible and WCAG compliant. I was wrong.
I’ll agree the above technologies utilizing AI for image alt-text will get you all your images labelled. I still use the technology for that actually. However a report you get from them will indicate issues auto-resolved by their AI/plugin but will also highlight issues requiring manual editing of the code.
Bubble doesn’t allow us to edit the code of particular button and doesn’t allow us to even add aria-label or aria-descriptions. The screen-readers will just indicate “Button”.
Affects Google’s ranking? says who!? Yeah I know Google says that but the effect is so minimal it barely registers. Google is getting way smarter every month and actually ranking by real user interest. All the other metrics like SEO and accessibility, and the creative workarounds they inspire webmasters and marketers to come up with, are seeing their impact decrease on a weekly basis. If Bubble upped its 60 to 90 what impact would it have on page ranking? none.
“besides that comply with WCAG standards or risk a lawsuit.” Huh? You work for the federal government!?
Introduction of Property Parameters in Reusable Elements
I’ll make a note that I extensively use ARIA properties in my CSS. And all discussion will be based entirely on ARIA - Accessible Rich Internet Applications suite of web standards…
Using custom element properties I did create various elements that I did have issues getting them compliant. I used an HTML element inside a reusable element and then using the element properties created the various parts of the HTML. This allowed me to easily pass aria properties and use the reusable element like any other Bubble native element. The WCAG editable element now had aria-label field, font-size, color fields etc.
I did find this method much easier and scalable as compared to using javascript to select element and edits its style properties.
I didn’t see any speed issues related to WCAG or increase in WU consumption since no workflow was used to add the addition info required by assistive technologies
Without explaining a pressing need, you created a multi-layered workaround that reduces one of Bubbles best features. Dare I ask why?
It’s clear to me WCAG compliance is not a pressing need for you. If you have a better way of doing it share or correct. We are here to help each other. You can use the parameters to pass data , I can decide to use it to create elements. That’s shouldn’t pain you unnecessarily. If using this feature to build elements is a reduction, how about some agency using DB to store basic frontend info🤣 like page Title i.e Contact US and Subtexts.
Hi There,
Thanks for being vocal about the lack of accessibility features built into bubble. It would be so easy for them to just allow us to set the aria tag for any element. That small step would make a huge difference.
I have a project for an org that has multiple employees with screen readers and other assistive technologies and have been searching for ways to build my Bubble app with ADA and WCAG compliance built in, rather than paying third party services to magically add AI compliance (which is inherently and evidently unreliable).
Hopefully we get some good accessibility tools in Bubble soon…