Rather than trying to change the world to not use canvas, how about screenreaders get fixed to read fonts off canvas?
Probably because the site author isn't taking the window.devicePixelRatio and backingStoreRatio when creating the 2D context.
> this "text" isn't in the DOM, it's not real text
The text is not in the DOM, but that doesn't mean it is not real text. It is text, literally strings, written with `context.fillText()` which could certainly be wrapped by screenreader software.
Doing so would make the world a better place for the bling by providing a more consistent experience - since 100% of people using canvas will never get extra budget to modify their logic, but 100% of canvas fillText() calls could be handled by a screen reader.
Unfortunately a great deal of engineers seem to have invested time and reputation in the unlikely change-the-world scenario, so I suspect blind people will continue to have a poor experience on the internet while a11y engineers who don't actually care for workable solutions continue to dominate the discussion.
As it stands, there's a way of saying 'I put some text on the canvas' but no way of saying when it was removed. The whole canvas could be cleared, or a particular region could be cleared, or over-written, or the canvas could be resized, which would result in it being cleared.
So if you wrote to a buffer every time you wrote text to the screen it would fill up pretty quickly. If you animated anything (as is happening in this example), then you'd have a million copies of the same text as it was re-drawn each frame.
There's also the temporal aspect, of course. With CSS it's possible to say 'this text is relevant, but you'll see it in a few seconds'. If you disabled CSS then the text would be there, static. If you were using a screen reader, you wouldn't know it was there until a certain point in time. That's not particularly compatible with the way people use screen readers.
The answer to which might be to manage on-screen resources and keep track of what is visible on screen and when it's removed.
And how do you represent the page hierarchy? You'd have to emulate some kind of DOM.
All of which comes under the banner of 'replicating the stuff that browsers already do, but with inevitable bugs and overhead and things you hadn't thought of'.
I think the appropriate response is to use canvas for interesting graphics that can't be done without it, and to keep text and markup for textual applications. Of course you can push the envelope of what's possible using new tech to create novelties, but it shouldn't be advocated for 'normal' web applications.
It looks like this page is a promo for a general content authoring system based on rendering in canvas, and that's a bad idea for all the above reasons.
Indeed. That's a solvable problem - you can track pixels and estimate with a degree of certainty - but it certainly does exist.
You'd also have to determine prominence of the text, which again is solvable assuming the size and weight and zoom level of the text has some bearing on the importance.
And you note the temporal aspect too - you'd have to track whether something was visible, ie sufficiently contrasts against the background, not opaque etc.
And indeed, there's no hierarchy asides from prominence.
All of that, plus more, is far more easier than getting the entire world to avoid, or write fallbacks for canvas.
None of the text is in HTML which means:
- it can't be used by assistive technology, e.g. for people with reduced visibility. People with partial sight use the web too.
- it doesn't work in reader mode, which is a common feature of web browsers to use standard CSS to read just the content.
- it has none of the benefits of WAI-ARIA
- I can't use services like Google translate
- that archive.org doesn't work
- search engine X can't index it. Maybe Google could one day with the right investment in technology, but there are more search engines than Google.
None of the styling is in CSS which means
- your animation wastes CPU cycles and isn't optimised
- I can't increase the size of the text if I need to if I have poor eyesight (zoom just makes the whole canvas bigger)
- on my phone screen text is unreadably small and I can't do anything about it.
- you're re-inventing layout stuff that browsers do. I found a layout bug[1].
Reinvents stuff that web browsers, not JS should be handling which means:
- I found a navigation bug in a few seconds[2].
- it doesn't work with older browsers. Some people are still using old versions of IE and can't switch.
- that standard web behaviour doesn't work. How do I open a link in a new window?
- it forces me to use the mouse to click things rather than the keyboard (not everyone uses the web the same way you do)
- it doesn't work at all if JS is disabled.
[1] Layout bug: load window with small window size, then resize. Some circles move, some don't.
[2] Navigation bug: back button doesn't work under certain circumstances.
This is a good technical demo, and shows the development skills of the author. Unfortunately it also shows that he has no idea about core web development issues, which on the web is probably more important, especially in a portfolio piece.