4 ms·

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

• BinaryIdiot 9y 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.
  • EdSharkey 9y ago
    I guess what is a hack and what is not depends 1) on how much you expect the browser vendors to do for you, and 2) on how tortured your code looks after you get the effect you want from the browser. I'll be first in line to call DOM, HTML, and CSS a hot mess and a frequent head-scratcher. But, the WAI-ARIA architecture turned out very nicely. I don't know about you, but I think the ability of the content creator to add metadata to markup to explain aurally, and in context, what that markup means is brilliant and inspired. Equally inspired is the Web Content Accessibility Guidelines (WCAG)[1]. The WCAG gives you the right way to think as a web developer about content and how to be respectful of your users with disabilities and make a simulateously navigable and content rich page for all users. It teaches you not only to think about and cater to screen-reader (blind) users, but also low-vision users, color blind users, mouse-only users, keyboard-only users, and cognitively impaired users. Here's what WCAG says about how to 'show' images to screen reader users, for instance: > 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A) In the how to understand 1.1.1 section, it talks about canvas content like yours and how it should be 'read' by screen readers: > Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, additional descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information. What that basically says is that the user needs to be able to see to experience the content, so just slap alt text on your canvas tag. As unsatisfactory as that sounds to you and me, to a screen reader user, having that alt text shows respect because without it the page doesn't make any sense when it is read out to them by the screen reader - there's literally a big blank spot conceptually where the canvas sits without the alt text. No, they can't reasonably play your canvas game, but at least they understand that something is there when they visit your page. Now, what I was describing earlier was a canvas that is painted with text and graphics that could conceivably be narrated to the screen reader user. (Maybe a turn-based rogue-like, for instance.) In that case, I'd use WAI-ARIA attributes to cause a visibly hidden div to be read by the screen reader whenever I update its textual content. All your concerns about my div causing the page to reflow and repaint are not valid because my content does not affect flow or paints. Use something ninja like HTML5 Boilerplate's visuallyhidden CSS class to make content 'appear' to screen reader software but be completely hidden on the displayed page: .visuallyhidden { border: 0; clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute; width: 1px; white-space: nowrap; /* 1 */ } Have you ever played with a screen reader? It's kindof a trip to 'listen' to your page read to you. Often, just with some simple markup ordering tweaks, you can get a confusing page to read sensibly. The one I use for my testing is open source and free, NVDA [2]. [1] https://www.w3.org/TR/WCAG20/ https://www.w3.org/TR/WCAG20/ [2] https://www.nvaccess.org/ https://www.nvaccess.org/