- From: Florin Malita <notifications@github.com>
- Date: Mon, 14 Jul 2025 12:41:29 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1095/3070746447@github.com>
fmalita left a comment (w3ctag/design-reviews#1095) > > It seems likely to be better overall to finish an accessible replacement for these features (hopefully HTML-in-Canvas) and then implement this new feature on top of that accessible replacement. > > I agree that any accessibility improvements could be driven by HTML-in-Canvas, and those could then be pushed to "regular" canvas text rendering. Guessing about the future, we may end up in a situation where most text in canvas is HTML-in-Canvas and the only text rendered directly in canvas is special in some way. Probably also worth pointing out that the text clusters portion of the proposal is intended to support rich text effects and animations ("text as art", as opposed to "text as information"). I suspect in that particular context authors will need to be explicit/intentional in order to make semantic information accessible. E.g. [something like this](https://skottie.skia.org/9c81972e38c5dca4f5ec02179c1ece12?h=1024&w=1024) could use some high-level annotation to make sense of glyphs flying around the screen, as opposed to feeding the dom to a screen reader. <img width="305" height="299" alt="Image" src="https://github.com/user-attachments/assets/35837f7e-d81a-465c-9979-0d58b75fbdb7" /> -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-3070746447 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1095/3070746447@github.com>
Received on Monday, 14 July 2025 19:41:33 UTC