This is super interesting, and we’ll be giving a lot of thought to how we would adopt this at Fastr where we’re using Penpot as the design canvas and publishing directly to the web rather than in a developer handoff flow.
I’ve been keeping track in develop for the past few weeks since @diacritica pointed me to your exciting new direction here, but I haven’t been able to figure out exactly how you plan to tackle accessibility in the viewport.
Content accessibility for ADA / WCAG / EN 301 549 web standards is critical, and that’s always a thing I worry about when someone is switching rendering technologies. I know the DOM is awful and browser support for SVG isn’t great. wasm + canvas can be a pixel-perfect black box that’s an exciting new area to explore, but assistive tools are really slow to catch up to new rendering technology. For moral, equitable, and legal reasons we all need to be super respectful of that.
So how are you guys planning to tackle that and keep the viewport accessible to screen readers / assistive tools that a user may require to discover and interact with elements in the viewport? Will you continue rendering DOM text elements floated within the canvas? Will you be able to support tab-index for users navigating without pointing devices, to navigate and position non-text elements?
I think it might be possible to achieve accessibility by layering an invisible DOM over the viewport that is presented to screen readers and provides keyboard interactivity, perhaps call it an accessible_viewport that is designed along a parallel render path to viewport_wasm. Or will viewport be preserved indefinitely with a commitment that there’ll never be functionality in viewport_wasm that users of viewport can’t experience?
That last one seems like kind a bummer because you would have done all this work to get to wasm without really breaking free from the DOM, but that’s the core challenge here! Accessibility concerns make it really hard to be on the web and not use the DOM. 
2 Likes
Hi Ryan, I’ll try to give some clarity on your concerns.
I haven’t been able to figure out exactly how you plan to tackle accessibility in the viewport.
Our goal with the new renderer is to provide the same functionality (and that includes keyboard navigation and shortcuts) as with the current one, but offer better performance.
Accessibility has many aspects, however, and poor performance might leave a Penpot file unusable or very frustrating to work with. The new canvas-based engine is not about being “pixel perfect”, it’s about allowing people to work with complex designs without bad performance getting in the way of common operations like panning, zooming, dragging shapes, etc.
Accessibility in Penpot is an area, however, that we need to improve overall, and it’s not just about the viewport render engine.
I think it might be possible to achieve accessibility by layering an invisible DOM over the viewport that is presented to screen readers and provides keyboard interactivity
While this could work, but given our resources and our small team size, I’m afraid it’s out of our reach. We can’t afford to maintain two viewports at the same time.
1 Like
Our goal with the new renderer is to provide the same functionality (and that includes keyboard navigation and shortcuts) as with the current one, but offer better performance.
I love this goal, but the definition of “same functionality” must specifically include “navigation and access to screen readers.” And unfortunately that requires that you are presenting semantic DOM elements to the browser (at a minimum this includes aria labels, alt text on graphics elements, tab order that matches the visual presentation, and HTML text).
Performance is not a legally mandated requirement for accessibility, thus we can’t defensibly argue we’re improving accessibility by making an app more performant. But we (Kaleidos or anyone else who hosts Penpot) do incur specific legal liability in the US, Canada, and the EU if we offer a web application that can’t be navigated and understood by screen readers. And they only speak DOM.
