I was looking at feathers UI demo when it hit me: the DOM has support for accessibility features such as talk back and tabbing through menus, general content and descriptions for images.
When developing in each platform’s native engines, support for a11y is also there.
What is the state of a11y in openfl for the multiple targets it supports? how does the community handle this matter? I know that for games, this is not generally a concern, but for other types of apps it definitely should be.
I started thinking about possible implementations to tackle this problem and am willing to start learning how to integrate openfl display list with the a11y features of each platform, in the case openfl/lime is lacking it (I really don’t know, couldn’t find relevant sources, but I admit I didn’t spend too much time searching).
Hope this is an interesting discussion for the community!
Screen reader + tabbing capability is def enough. I’m trying to think of the scenario of for example a blind user.
yep, webgl is not suited for this kind of stuff, but when it comes to openfl, having a layer of accessibility makes sense, since openfl has the potential to build general-use apps, not only games.
Because see, when we use the default SDKs, we get those features (for example, using swift to make iOS apps). such features are important for multi-purpose multiplatform frameworks.
I’m not complaining, I just wanted to understand the current state of a11y in openfl for the various platforms it can export to so I can decide what I want to do about it.
TLDR: I want to use Openfl (specially with feathers arriving) as an alternative to, let’s say, flutter or react native. a11y is a big deal, and I want to invest in the openfl platform so I can even ultimately try to develop libraries to add at least screen reader and tabbing to openfl created content.
I’m pretty sure that activating a screen reader (such as the three finger swipe on iOS after activating it in accessibility) would read DOM-based text content on a page
I’m also interested in this, both from an accessibility POV and for search engine optimization when deep-linking a web application. I also found that link that @loudo provided to be interesting for its good examples of aria-label and role attributes.
The HTML standard has this recommendation: https://html.spec.whatwg.org/multipage/canvas.html#best-practices
FeathersUI is making good use of keyboard-accessible navigation I noticed. I’d like to see it support good SEO also. It does seem that the OpenFL DOM target could be a possibility but I am guessing it would have limitations. For me, I would like to see a nice way of generating alternate content in the HTML5 target that appears within the <canvas> tags.
Somebody just asked about Feathers UI accessibility on Discord recently. I might as well share my response here too, since it’s relevant:
OpenFL doesn’t implement Flash’s accessibility APIs yet. On most targets, everything is drawn on the GPU, so there’s not even a limited experience for screen readers to fall back to. For html5, you can use -Ddom to have OpenFL render using the HTML DOM instead of canvas/webgl, so screen readers could read the text at least. However, it basically just dumps everything into a single container, with no hierarchy, so it wouldn’t be a great experience. It would read the text, but possibly out of order and with missing context.
I tried an experiment a while back where I generated a custom HTML DOM tree inside the canvas element (which is basically what is recommended when using canvas/WebGL), and I added ARIA roles to the elements for their corresponding components. I’m not an experienced screen reader user, though, so I’m not sure that it was resulting in a good experience. It felt a bit off to me. I’d like to revisit in the future, though.
Thanks—I’m likely going to do some in-canvas output for the sake of SEO. It will likely be basic server-generated stuff instead of runtime-generated. Thought I should re-poke this discussion to make sure I wasn’t missing out on anything.
