4 ms·

HTML5 Canvas is the least accessible thing to be put on the Web since Flash. If you render text inside a canvas element, you end up with a picture of text. You

by rspeer 10y ago

HTML5 Canvas is the least accessible thing to be put on the Web since Flash. If you render text inside a canvas element, you end up with a picture of text. You can't screen-read it, you can't re-flow it, you can't even select it!

euroclydon 10y ago
It's easy enough to overlay text in HTML though.
- m_fayer 10y ago
  That your solution to the problem is a truly hideous hack, speaks volumes.
  - euroclydon 10y ago
    Hideous hack? Use abs positioning, and overlay. Let's see, you have a scripting language host in the presentation layer and built-in first class methods to draw HTML elements and to canvas. The horror!
    - BinaryIdiot 10y ago
      Sorry but I'm also going to consider that a pretty awful hack. If you're going through the trouble of setting up an animation loop for rendering graphics you need to have your text in the same space. If you don't now you have to bridge this gap of two different rendering worlds. There are abstractions and techniques to overlay html elements over the canvas and sorta meld them together, sure. But they're rendered and updated in astonishingly different fashions that don't really go well together. This is sorta like writing a game using a rendering technology like OpenGL but then sticking, say, a win32 label control on top of the rendered OpenGL screen. They both have very different patterns of control.
      - euroclydon 10y ago
        Then just write the text in canvas, if it's a game. The original poster said that canvas text was not accessible and didn't wrap. I don't think screen readers and tightly synced game loops go together well. And is wrapping text some big problem in the game world?
        rspeer 10y ago
        Ever played a game with a chat box? I've played one implemented on top of Canvas and it was horrible.
EdSharkey 10y ago
That is taking quite a dim view of what you can achieve with browsers and screen readers to make pages accessible. The key is to decide whether your canvas is being used as a dynamic pixel buffer or as a static image after it has been painted (akin to an img tag.) If it's static, just supply alt text and you're accessible. If you have a dynamic canvas, you can maintain a visually hidden div alongside the canvas that you set to role="alert" aria-live="assertive". Add text to the div as things happen in the canvas that describe the situation. Any screen reader watching the page will read out the text live as you make updates. There is always a way to do right by your users if you care, some things just take more work than others.
- BinaryIdiot 10y ago
  The problem is your proposal is that it's a bit of a hack. So when you render with the canvas it's pretty raw, much like if you were rendering a scene using native painting with a native language (SDL, OpenGL, DirectX, etc). The typical pattern here is you setup an animation and, sometimes, an update loop (though update loop is a little awkward with canvas but I digress). These loops fire constantly to update the scene and repaint everything. When you bring the DOM into it the DOM doesn't work like that. The DOM is a completely different way to render everything. So when do you move your DOM overlays onto the canvas? In the update loop? Then control their display via the render loop? Now you have some trouble. Depending on what you're doing to the DOM object may repaint the entire window, not just your canvas. So now you have more overhead and you're losing performance. But wait it gets even more fun. While your canvas animations progress with every `requestAnimationFrame` the DOM is different. The DOM won't get updated until the next next tick if you're making changes in your render loop (so once the current `requestAnimationFrame` ends then the DOM gets updated). Since the DOM isn't updated in the same time you have to compensate for that. Also, if you're updating positions in an update loop (pretty common) and you update DOM properties here, now the DOM will be updated after the update loop is run and before the next render loop. Either way if you run into performance slowdowns this can become very noticeable. Ultimately you're taking two very different ways of handling drawing and you're trying to force them together to support accessibility. The better solution would be to build more of these capabilities into the canvas and its APIs itself.
etimberg 10y ago
To add on to the text note, it's actually even more annoying with Canvas to draw it correctly. None of the major browsers implement a TextMetrics object (the return of ctx.measureText) that has anything more than the width of the text. https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics How anyone thought it was OK not to ship that is beyond me, but it means that when laying out content on the canvas you have to write a hack for the font height and hope it's good enough for most cases. I think there is a polyfill available but I believe it works by rendering the text in SVG and measuring it there which seems to defeat the purpose of doing it on canvas.

by rspeer 10y ago

euroclydon 10y ago

It's easy enough to overlay text in HTML though.

m_fayer 10y ago
That your solution to the problem is a truly hideous hack, speaks volumes.
- euroclydon 10y ago
  Hideous hack? Use abs positioning, and overlay. Let's see, you have a scripting language host in the presentation layer and built-in first class methods to draw HTML elements and to canvas. The horror!
  - BinaryIdiot 10y ago
    Sorry but I'm also going to consider that a pretty awful hack. If you're going through the trouble of setting up an animation loop for rendering graphics you need to have your text in the same space. If you don't now you have to bridge this gap of two different rendering worlds. There are abstractions and techniques to overlay html elements over the canvas and sorta meld them together, sure. But they're rendered and updated in astonishingly different fashions that don't really go well together. This is sorta like writing a game using a rendering technology like OpenGL but then sticking, say, a win32 label control on top of the rendered OpenGL screen. They both have very different patterns of control.
    - euroclydon 10y ago
      Then just write the text in canvas, if it's a game. The original poster said that canvas text was not accessible and didn't wrap. I don't think screen readers and tightly synced game loops go together well. And is wrapping text some big problem in the game world?
      - rspeer 10y ago
        Ever played a game with a chat box? I've played one implemented on top of Canvas and it was horrible.

EdSharkey 10y ago

That is taking quite a dim view of what you can achieve with browsers and screen readers to make pages accessible. The key is to decide whether your canvas is being used as a dynamic pixel buffer or as a static image after it has been painted (akin to an img tag.) If it's static, just supply alt text and you're accessible. If you have a dynamic canvas, you can maintain a visually hidden div alongside the canvas that you set to role="alert" aria-live="assertive". Add text to the div as things happen in the canvas that describe the situation. Any screen reader watching the page will read out the text live as you make updates. There is always a way to do right by your users if you care, some things just take more work than others.

BinaryIdiot 10y ago
The problem is your proposal is that it's a bit of a hack. So when you render with the canvas it's pretty raw, much like if you were rendering a scene using native painting with a native language (SDL, OpenGL, DirectX, etc). The typical pattern here is you setup an animation and, sometimes, an update loop (though update loop is a little awkward with canvas but I digress). These loops fire constantly to update the scene and repaint everything. When you bring the DOM into it the DOM doesn't work like that. The DOM is a completely different way to render everything. So when do you move your DOM overlays onto the canvas? In the update loop? Then control their display via the render loop? Now you have some trouble. Depending on what you're doing to the DOM object may repaint the entire window, not just your canvas. So now you have more overhead and you're losing performance. But wait it gets even more fun. While your canvas animations progress with every `requestAnimationFrame` the DOM is different. The DOM won't get updated until the next next tick if you're making changes in your render loop (so once the current `requestAnimationFrame` ends then the DOM gets updated). Since the DOM isn't updated in the same time you have to compensate for that. Also, if you're updating positions in an update loop (pretty common) and you update DOM properties here, now the DOM will be updated after the update loop is run and before the next render loop. Either way if you run into performance slowdowns this can become very noticeable. Ultimately you're taking two very different ways of handling drawing and you're trying to force them together to support accessibility. The better solution would be to build more of these capabilities into the canvas and its APIs itself.

etimberg 10y ago

To add on to the text note, it's actually even more annoying with Canvas to draw it correctly. None of the major browsers implement a TextMetrics object (the return of ctx.measureText) that has anything more than the width of the text. https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics How anyone thought it was OK not to ship that is beyond me, but it means that when laying out content on the canvas you have to write a hack for the font height and hope it's good enough for most cases. I think there is a polyfill available but I believe it works by rendering the text in SVG and measuring it there which seems to defeat the purpose of doing it on canvas.