Bubble Websites and Accessibility

Is it possible to create a Bubble website that conforms to accessibility standards? Has anyone had that as a requirement for any of their projects?

My sense is that Bubble is seen primarily as a tool for entrepreneurs and start-ups, but as it grows in popularity, its appeal will broaden, and its potential applications [and website audiences] will become more diverse; and accessibility might become more of an issue.

Generating semantic mark-up is not currently one of Bubble’s strongest suits, although I have noticed that for some elements, the HTML tag can be specified in the property editor; but that’s actually identified as an SEO feature.

Anyway, just curious if others have given this any thought, and I’d be interested to know if it’s even on @Bubble’s radar.


That’s a good question. I’m really curious about this too, especially as it pertains to inputs (and labels and ESPECIALLY tabbing index). I haven’t seen anything about it and don’t necessarily see how it could work necessarily given the way pages are assembled, but +1 from me.

It is on our list of things to investigate and improve on, but not for the near future, unfortunately.

We’ll keep you guys updated on this thread.


Great to know it’s on the radar, @emmanuel. I’d be more proactive in approaching local gov’t orgs and businesses if accessibility wasn’t an issue. (Gotta fund my own entrepreneurial endeavors somehow. :wink:)

Thanks for letting us know!

1 Like

I have to agree with you on the inputs and definitely the tabbing index. I’ve read through all the threads regarding the tab index and while testing different options people tried, I actually found two bugs which I reported. The tab index is a very important issue to resolve and a manual override is needed.

1 Like

You can use Javascript to update the tab order. Just FYI in case it’s worth the complexity.


@sridharan.s - Yeah, I’ve definitely thought about that, but it’s a pretty sloppy process currently to make that work on a page that has complex forms or dynamic forms. Ultimately, it doesn’t actually address the accessibility/screen-readability of the page, but it can work. For simpler forms I’ve found that by curating how forms and their parent groups are themselves grouped can produce decent results for tab-index, but definitely not a long-term solution.

Just circling back on this as I’m curious where this is on priority list now that we’re 10 months further down the road.

Being able to conform to accessibility standards – even just being able to label inputs – would be very helpful.

1 Like

:+1: Me as well! Are we in the near future from March of 2019 yet?

Accessibility could be as easy as setting an attribute on the inputs to note the label, then the HTML that gets generated includes a tag.

I’m a Product Manager and Developer, so I know nothing is “as easy as” - but this one’s a big enough deal to prioritize regardless of the complexity. From my seat, it looks like it could hopefully be on the less complex side since the framework is there. Can you sneak it onto the top of the backlog? :slightly_smiling_face:


I have a fix that works today, but could be improved with what I suspect will be a small development effort. Check out the free accessibility widget from https://userway.org/.

UserWay have committed to the widget always being free. They make money of white label versions of the widget and accessibility audits. UserWay already have implementations for many platforms like Wordpress, Wix, Weebly, Joomla etc. See https://userway.org/platforms. I’m presuming they offer an API or dev kit and the platform owner does the work to implement support. Once that is done, adding their widget is trivially easy for a site owner.

However, they also have a vanilla HTML/CSS implementation which will work with your Bubble site today.

I just implemented it on mine. Simply complete a configuration survey at UserWay.org and add the code snippet they give you to the of your page. The easiest way to do this in Bubble is to just add it to all of your pages by using the “Script in the body” option under Settings -> SEO/Meta Tags.

You try my implementation at revid.xmarklabs.com. You’ll see an accessibility icon in the lower right hand corner. Click it and try the various options to see how it works.

Please note: Not all of the text on my site fully behaves with all of the accessibility options, but most of it does.


Hi Emmanuel, is there an update on this at all? It would be amazing if this was coming soon.

Lack of accessibility features will be a deal-breaker for a lot of people. Having a website/software that discriminates against people with disabilities is a pretty big problem.

In the US there is even precedent for lawsuits against websites that don’t conform to accessibility standards.

1 Like

this is a really cool plugin Nick! Would you still recommend this for sites that need to be accessible?

It’s been working well for me. I have it on two sites, one is a Bubble site, the other is a WordPress site I maintain. Both have worked without any issues as far as I can tell.

1 Like

I’m a Bubble newbie and really love the platform. However, I’ve been also thinking about how to make Bubble apps more accessible at ideally WCAG 2.0 AA accessibility level. One of the major stumbling blocks are form field text inputs, given that there is no out of the box option to include an input paired with an html form label nor is there an actual html based form label element. As someone pointed out in another comment, it’s possible to add an id to elements. So…

From there, you can add an id to a text field.

Then, using the html element, you add an html based label. In this case, for=“fav-color”.

That now targets the id of the input.

As you can see, the styling doesn’t match the look of the app now. In order to match it you need to go into the Settings /SEO and inject some css into the page to match the styling. Unfortunately, since there doesn’t appear to be a way to associate preexisting styles to the html element, the styling doesn’t show up in the Editor but will show up in the actual page.

I’ve also added some styling for classes to only show to screen readers. This is important for adding things like a Skip Links ability. You would need to add an anchor id, for example: id=“main-content”, to whatever div or group is your main content. You can where you can inject the div above in the screenshot. It’ll appear right after the scripts in your opening body html tag. I’d apply the .sr-only class reference in the screenshot above. You can also include a focus only version that shows it when tabbed. I’ve taken this from Tailwind css but Bootstrap has their own version. You’ll need to do this for all pages. Yeah, kind of a pain. Although I suppose you could add an item like a div that’s last in a universal header to let screen readers know where the starting point is.

The ability to activate html tags to properly add titles based on Styles is a good idea too.

In the HTML 5 spec, pages can technically have more than one H1 title on a page besides what is int he body tag, if they only appear in a header, section, nav or article html tag. That isn’t possible though given that Bubble pretty much uses divs to structure everything, so I’d limit yourself to one H1 tag per page to structure things semantically for screen reader apps and SEO.

After also paying attention to page and text contrast and colors, as well as font sizing, we actually managed to get a score of 96 on Chrome’s Lighthouse Accessibility checker!

As others have pointed out, the way the tab indexes are applied detracts from the score and there may be a JS fix but I’m leery of JS band aids after researching them years ago. I know some of the best accessibility experts in the country and they don’t have a high opinion of the “auto accessibility” approach. Something is of course better than nothing though. It’s always better to do what you can directly in the app itself, use proper html structuring and, where needed, wai aria-roles (which we can’t really do in Bubble natively).

That said, I haven’t really delved into the other input elements yet like check boxes (which seem to have proper labels), radio buttons, the date picker etc. but I suspect the html/id technique might help there too.

I’ll try to update this comment/thread as I find out more. :slight_smile:

Mentioning @bonifier since he was curious.


You can also utilize the sr-only class if you want to support accessibility but don’t want the label to show. I’d use this approach instead of choosing to uncheck the “visible on page load” checkbox in the Properties window, since that applies display: none to the elements css. Elements with that applied are often skipped by screen readers since they are attempted to provide an equal experience on a par with sighted users. So if sighted users don’t see it, they assume screen reader users shouldn’t either.


Noted that per Nick12’s recommendation above that in January, the Userway plug in is available in the Plugins store for free (originally posted by Jici)

1 Like

@mrmarionoble with your accessibility chops, could you help us understand if that plugin is good enought or falls into the

cheers !


@lucas.ar Sorry, I haven’t seen this until now. I’ll definitely check it out, and something is generally better than nothing, that’s for sure!

Thanks! This is great

It’s a shame that Bubble.ie doesn’t have better accessibility out of the box, but having proper labels with ‘for’ attributes gets us a good way to having baseline acceptable forms.

So I asked the two dedicated accessibility experts I work with (they’ve worked @11y for eBay, Paypal, etc) and they’ve basically said tools like Userway are not a great alternative. Here are some links they shared on the topic:


1 Like