Re: [w3ctag/design-reviews] Canvas Text Metrics for Editing, Art and Design (Issue #1095)

schenney-chromium left a comment (w3ctag/design-reviews#1095)

> > I think this represents a serious gap in the platform, and I agree that adding APIs to support more sophisticated use cases for text in canvas does make the need for addressing this gap increasingly pressing. However, I'm not sure what guidance can usefully be given in the context of this API while that gap persists.
> 
> Hi all. Mike here, member of AGWG and APA but my comments are purely my own. New poster here in this thread and just curious about a couple of things:
> 
> 1. [@schenney-chromium](https://github.com/schenney-chromium) Have you discovered anything about that gap that Alice mentioned and if there's any development? It doesn't seem like there's a workaround at the moment, but thought I'd ask anyway; and
> 2. With the ability to customize kerning, skew, orientation, etc., also comes the chance for rendered text in a typically left-to-right language to be presented right-to-left. This is true of the example on the project page that renders the text in a circle, which has upside-down and right-to-left text presentation. I'm unaware of any way to solve for this customized rendering except for having plain text available within a close proximity (reading order) to the rendered text, or relying on canvas fallbacks (which are limited). I'm trying to think about other methods to ensure as accessible an experience as possible. Within the proposal, is there room to have an automatic output that's rendered in real text adjacent to the canvas? Thinking out loud here...

There hasn't been any movement on Alice's proposal yet, and there is not any proposed automated solution for the HTML-in-canvas work yet, although a developer who is actively trying to generate an accessible canvas will have an easier time.

The idea of automating accessible text content for text rendered in canvas is an interesting one. For most cases it would probably work well. It would break down when developers split up their text to achieve certain rendering results. But then this proposal might make it more feasible by reducing those special cases.

As far as the ability of this proposal to render test in non-standard RTL ways, I would expect there to be an intended interpretation of the string, which would still be valuable to accessibility tools. Problems such as text being reversed or upside down already exist due to transforms that may be applied.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-3070136086
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1095/3070136086@github.com>