Before i knew what accessibility is, I loved playing with and making interfaces that were just not possible with “normal” web. Flash was the tool. By the time when I finally understood what accessibility is and what kind of barriers people face when we do not make things accessible Flash was a dead end. Thanks to iPhone.
I migrated to semantic web and did not look back, besides from some proofs of concepts with canvas, the standard that gradually replaced flash. But they were just for fun and some visualizations that had alternative formats (like graphs with tables).
Then I noticed how canvas got visually amazing and accessibility nightmare at the same time. People ignored semantics, and all other accessibility guidelines and made whole new visual only experiences that won awards but left groups of people before closed gates.
We already have some solutions, but they are often neglected or forgotten
It’s strange actually, as canvas has always supported (and demanded) fallback content that could serve both user agents not supporting canvas and assistive technologies at the same time.
When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the canvas’s bitmap. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.
HTML standard on use of fallback for canvas (opens in new window).
This possibility is still not used a lot or at all when I check practically any webpage that has (often 3D) rich experiences. I speculate there are multiple reasons for this, but mostly I think it drills down to:
- People don’t know they can actually make (accessible) alternative with help of fallback.
- People don’t care or have the time/budget to make accessible fallback.
- People try to bolt on accessibility at the end and give up or do it only partially.
I just guess here, but I’ve been in some discussions and I think my guesstimate is quite close to the reality.
There are also some experiences that are extremely difficult to make accessible for all people, but we really should try more, it seems that people do not even try. A good thing here is that gaming accessibility leads with innovation and we should learn more from the Game Accessibility Guidelines (opens in new window) when making ultra innovative interfaces on the web.
When doing some proofs of concepts I tested the plan first – code later concept and it was indeed way more effective than the other way around. So I guess that people designing the concept – before it even hits the wireframes and code – should investigate way more to make the concept universally designed in the first place. Then the wireframing and implementation would already be way more accessible than they are if we want to bolt on accessibility later.
The most time consuming thing with current solution for canvas fallback was the synchronization between visual parts and semantic fallback. Color contrasts, zooming, reflow, text alternatives, keyboard support, skipping things and so on was not very hard when planned for from the beginning, but I did use more time for figuring out the semantics behind advanced user interface – how to translate the interactions and the names, roles, states from visuals to code when they were very innovative.
HTML-in-canvas has the potential, but we still need to plan for accessibility
The proposal for using 2D and 3D canvas to customize the rendering of HTML content, shortly HTML-in-canvas (opens in new window) seems to be an important new tool to make innovative interfaces more accessible in the future (I hope it will be a part of the standard in the close future).
With current solution – the before-mentioned fallback – we do not have any guarantee that fallback is “one to one” with the visuals. And it costs quite a lot to make the synchronization between the visuals and the semantics in the fallback.
HTML-in-canvas helps with exactly that – it guarantees that elements drawn into the canvas (visuals) will always match their (semantic) fallback. It makes our jobs with the fallback way easier and out-of-the-box – or as it is not finalized yet – it promises to do this. We do not need to draw a button and then bolt on semantics. We can use the semantic button and just make it look amazing. Considering semantics is still essential and will remain to be in the future.
But this makes me excited. It will be way easier to have the fallback there, and we will need less time to make innovative experiences more accessible (we still have a lot of things to fix manually, but at least one of the most difficult ones will be simplified for us).
It is also amazing that we don’t need to wait for the standard. By being just a bit technical we can already now test it out. HTML-in-canvas is currently behind browser “feature flag”, so some technical hands-on is required, but it is quite easy if you can install Chrome Canary (opens in new window) or Brave Stable.
Then all you need to do is to paste the flag (chrome://flags/#canvas-draw-element) into the browser and Enable the drawElement API for Canvas and relaunch the browser.
If you can try this – I invite you to try some demos (opens in new window). I’ve tested a couple with some screen readers and they really seem to work well – depending on the proper use of semantics, of course.
I hope we can also have more people that are currently focused mainly on the visuals to consider the universal design and accessibility parts, plan for them already in ideation and before they even touch wireframes and prototypes and with some time (I hope soon) we will make the innovative experiences more accessible to more people.
