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

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/