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. 
Mentioning @bonifier since he was curious.
)
Me as well! Are we in the near future from March of 2019 yet?
