But since so many people do not understand the importance of HTML for accessibility, I feel the need to stress that this page may be a horrible experience for non-sighted people.
To sighted people, obscure unicode characters may look like text in a different font, but do they for screen readers? The same goes for ASCII art and the tables on this page.
Do all the fun stuff! But please draw the right conclusions for real-world projects.
I only clicked this story because I was worried someone was just using canvas and JS and ignoring the fact that it's entirely invisible to accessibility features. I heard there is ongoing work to introduce a direct accessibility tree API, but for now the DOM is required.
Instead it's much adieu about nothing since you could simply serve a text file.
That being said, <plaintext> is a nifty historical footnote I didn't know about, so that's cool.
Side note, a lot of people aren't aware that businesses in the US can be sued for violations of the Americans with Disabilities Act (ADA) for non-accessible websites.
BTW, Shakespeare's Much Ado About Nothing was a pun on "noting" and entailed the passing of notes. I believe "nothing" was pronounced more like "noting" at the time.
and now without much ado I will say goodbye for this comment. Adieu.
Thanks for pointing this out. I'm visually impaired but don't tend to need a screen reader that often. But the times I do want/need to use one, I inevitably find things that are just awful. For fun, I tried turning on TalkBack on my phone and this demo site was completely inaccessible (TalkBack didn't pick up anything other than the archive.org controls). Maybe part of that is it being on archive.org, but I suspect it's due to the lack of any real HTML.
I'm curious how Talkback/Narrator handles this same content, but as a standard text file. I suspect it's still bad, but something about the weird HTML shenanigans being played might be messing up the screen readers.
I'm curious why? I built a JS-driven website and did extensive testing with the screen readers available to me (phone, etc). Adding a few aria properties seemed to work wonders. I think the problem isn't the SPA concept but rather that people don't bother testing. However, a horrible screen reader experience can be achieved without an SPA too and many do.
RFCs were originally formatted as plain-text, and render well on most browsers (as long as the viewport width can fit 70 characters).
The first time I inspected one in a modern browser devtools, I was confused: "where's the HTML? How do they do this layout?". It's done with spaces, same way as you would with a typewriter.
They don't render well even outside of the huge smartphone use case because they lack trivial formatting present even in the old printed medium (and even typewriters were richer, could retype the same char on the same spot to make it stand out or use underlines)
A byte-order mark (BOM) would have the highest priority. [1]
BOM > HTTP charset > HTML meta charset
Also works for local files (not served over HTTP).
> You could skip the meta encoding declaration if you have a BOM, but we recommend that you keep it, since it helps people looking at the source code to ascertain what the encoding of the page is. [1]
> <meta charset="UTF-8"> is real. Without this, text encoding sniffing takes places and some browsers just displayed rubbish.
I am curious. Which browsers do this? I thought this tag is unnecessary in HTML5 because the information that the page is UTF-8 encoded is already implicitly conveyed by the DOCTYPE. (UTF-8 is the only encoding allowed for HTML5.)
I tried rehosting this file on localhost and removing the <meta charset="UTF-8">, breaks it in the latest versions of Safari, Firefox and Chrome
I tried to fix it by replacing the fake doctype with <!DOCTYPE html>, and it fails in the same way (but the page gets slightly more padding in the top of each page, proving it's doing something to switch modes).
I cannot reproduce this. I used VSCode's live previewer to host the file on localhost (macOS) and tried with the browsers you listed. Removing the meta tag or changing the doctype did not make a difference.
Is it possible that you accidentally deleted the `<plaintext>` tag when making your changes? That breaks the page for me.
I live in Japan, try changing your OS language from English to Japanese - in Japanese a lot of things switch to defaulting to Shift-JIS instead of UTF-8 when nothing is specified.
Didn't need to. When hosting per `python -m http.server 9000` I get the same result as you. Very interesting. Thank you for bringing this to my attention.
As you can see, I didn't use that doctype. I experimented with a few older browsers (and one of those online virtual testers) and a few displayed weird results without it.
Funny, but I’m saying it seriously as a countermeasure to the bloat epidemic. An SMS parking app doesn’t even need Internet and works fine. Use the simplest technology to achieve a goal and enhance.
You forget the fact that bloat is driven by many stakeholders, not just developers. Bloat is the consequence of ever increasing demand for bells and whistles, the pressure to release something (case in point: github projects that don't get updates every other month are considered dead) amongst other factors.
An SMS parking app works fine as long as you limit it to the very specific use case. As soon as the "enhance"-part enters the picture, chances are simplicity leaves the scene at the same moment. Complexity can only be avoided by keeping the problem simple.
As someone who travels a lot, SMS based app stuff is one of the most annoying common problems.
It’s easy to find a way to get internet anywhere, but getting an sms message at a phone number is way harder (or easy but expensive); bonus points if you restrict it to local phone numbers only. Lots of countries require ID checks to get a local number and the system breaks with foreign IDs.
It would be fun to have something like Advent of code, but for arbitrary restrictions.
The grand finale could be making something without using a computer at all or buying anything (Not even for research, you have to use actual books or talk to people), and trying to use as little tech as possible.
Like, you can use a power drill, but if you use a brace and bit you get extra points. You can document with a phone camera but if you can draw you might want to illustrate instead.
Oof. That's a shame. I've seen some folks automatically switching out dead links on their blog with archive.org versions. Is that something you're doing, or did you manually switch the ones you knew were gone?
But since so many people do not understand the importance of HTML for accessibility, I feel the need to stress that this page may be a horrible experience for non-sighted people.
To sighted people, obscure unicode characters may look like text in a different font, but do they for screen readers? The same goes for ASCII art and the tables on this page.
Do all the fun stuff! But please draw the right conclusions for real-world projects.