Existing link colors made it hard to distinguish between visited and
unvisted links on screens that had warmer color temperatures. Adjusted
the colors to make the distinction clear.
Unfortunately, that adjustment made superscript visited links (for
footnotes) fail the APCA, so I added a solid black background to
superscripts. Now they too should have good contrast.
- I felt dark-mode links were still a bit harsh, so I lightened them.
- Improved perceptual contrast of the purple visited links by making the
background color slightly less blue.
- On widescreen, make footer links inline. They happen to be about the
same width as the global nav, which makes this work well.
WCAG recommends telling visitors about their current place in a site's
hierarchy. All pages are exactly zero or one level below a section, so
simply emphasizing a member of the navigation links should be
sufficient.
- Use borders instead of <hr>
- Distinguish <kbd> from <code> and body text with boldness
- Improve dark contrast and make dark visited links look distinct from
regular text
- Improve focus indicators
- Fix print directive i accidentally deleted
- Switch from inline-start to "left" since old browsers prolly outnumber
the number of poeple using Eng-Arabic machine translation engines that
also alter the text direction.
- Mention checking privacy policies for 3p content
- Elaborate on more mainstream examples of color overrides
- Link to CSS WG docs instead of MDN for prefers-contrast since they're
more detailed.
- Specify that I'm just removing margins in <figure> elements for
quotations.
- Re-phrase a line referring to a previous section; after some
re-arrangements, that section is no longer a "previous" section.
- Replace spatial terminology ("bottom") with sequential terminology
("end")
- Add note on font enumeration without the Font Access API
- Acknowledge testing in grayscale but emphasize that it isn't enough.
- Move defense of link underlines to just after the section on custom
colors, since it's more relevant to it.
- Add xkcd image into the page instead of just linking, since the linked
page content is an image that doesn't include a transcript or
descriptive alt-text.
- Trivial rephrasings
- Even less halation for dark theme
- More contrast for borders
- Slightly larger font, fixes APCA contrast issue for <small>
- Make responsive navbar work in NetSurf
- Make aria-current page bold
- Use content-visibility to unload footers and endnotes
- Add aria-labels to unclear webring link text
- Replace <hr> elements with css borders; the semantic meaning of <hr>
was unnecessary with section breaks.
Use -inline-start instead of -left for machine translators that change
direction. Wrap that in a feature query so browsers that don't support
these rules can fall back to default styling. Those browsers are desktop
browsers anyway, where this doesn't relaly make a huge difference.
Add reduced-contrast for dark mode, for readers with severe astigmatism.
Reduced-contrast is the same as regular dark mode, except that the
background is lighter.
Somehow fit all of this in <1kb, any bigger and I'll have to stop
inlining.
- Add dark variant of an image
- Some WebP images weren't significantly smaller than their PNG
counterparts; replace them with JPEG-XL. No browser supports it yet
but I need those meme image formats aaaaaaaaa
Describe how to best include images and figures in a way that flows well
and is accessible to both sighted and non-sighted users.
Describe how sticky elements can be a usability hazard on short
viewports
- Add changefreq
- Clean up structured data for quotations
- Add more sample unorthodox tests
TODO: dark image variant of image in new "Beyond alt-text" section
Add a better screenshot showcasing bad custom colors. Also give it a
figcaption.
The figcaption meant that I had to revise a statement later down when I
said I don't use figcaptions for images.
Pulls content exported from Buku, so I don't have to commit every time I
add a bookmark.
Since I added another nav item, I had to adjust the navbar css.
WCAG AAA guidelines encourage limiting text to 80 chars. Unlike A and
AA, the AAA level is more of a list of suggestions than a requirement.
Most other studies seem to indicate 70 is a good minimum but 100 is a
bit excessive.
"ch" units are broken on NetSurf, so I went with the closest "em"
approximation (since I already use "em" everywhere else).
All pages should now look good on screens 230px wide (DPR=1), inc. most
feature-phones running e.g. KaiOS.
Add borders to images so they look distinct from the surrounding page.
This requires making <nav> *not* display inline except for the
unstyled-list navlinks. This should also do a better job at appeasing
reader modes.
For the same reason, also make one link a citation
- Remove reference to unused syntax.css
- Stop Apple's magic phone-number-linkification. If I need to link a
telephone number I'll use a tel: URI, thank you very much.
The newish APCA contrast algorithm correctly reveals that blue-on-black
and purple-on-black links have lower perceptual contrast than
yellow-on-black links.
A Fediverse survey with 19 participants revealed that others tend to
prefer the older look over this one, but the number in favor was much
larger than I thought; it was a 3:2 split. I decided that on my poor
laptop screen facing sunlight with simulated color vision deficiencies,
the yellow links are indeed easier to read so I went with them.
Statically grab and include webmentions during Hugo builds, no JS
involved. Hugo supports making web requests and parsing the resulting
JSON, so there was no need to use an external program either.
- Add a cache-busting fingerprint to all the icons in the webmanifest
- Add a <meta> and open graph tag for a description.
- Include a 512px icon in the manifest
- Use the recommended resolution for the open graph image
- Since the mask-icon is onl served as a cache-busted asset and never
served as a plain link from the site root, move it to assets/
- Cache-bust the webmanifest and put it in assets/
I just found out that lots of Android devices will letterbox icons; the
latest version of Lighthouse will preview an icon in the safe clipping
range, and that range was way too small for my existing icons. I made a
new version that was mask-safe with the white foreground shrunk down a
bit so it would fit. See [0].
[0]: https://web.dev/maskable-icon-audit/
For consistency, I renamed the Apple mask icon as well.
Why are there so many extensions to the HTML standard for icons? This is
getting ridiculous.
It's time for a rant about icon standards. Let's recap! what icons do I
have so far?
- A 192px apple-touch-icon. Apple icons are supposed to be 180px, but
192px gets re-sized down just fine. This used to be apple-specific but
then Android and others started using it. I picked 192px instead of the
standard 180px because we need...(next bullet)
- A 192px icon for Android devices. Rather than having a separate icon
for this, I just re-used the existing Apple icon in case the user's
browser wants both so it can just cache and re-use it.
- The original 32px favicon.png. I picked PNG instead of ICO because an
ICO containing the optimized PNG was a whopping 2kb while the png was
176 bytes. It looks fine when scaled down to 16px with a variety of
automatic downscaling algos, so there was no need to include an extra
16px version.
- A mask-icon. I was hesitant to implement this since it seemed very
vendor-specific (desktop Safari only), but it somehow became an
accepted registered extension to the spec [1] so I figured that it was
only a matter of time before a bunch of other things started using it.
- A webmanifest file to describe even more icons. It re-defines the
aforementioned 192px icons. I chose to re-use the icon for the same
reason as before. It also describes the next two bullets:
- favicon.svg: used in the manifest in case the device wants something
bigger than 192px.
- A maskable icon (svg), completely unrelated to the aforementioned
mask-icon, with the focus of the image shrunk down to handle cropping
e.g. on some Android devices.
[1]: https://html.spec.whatwg.org/multipage/semantics.html#attr-link-sizes
What I SHOULD have, in an imaginary world where web standards make sense:
- A 32x32 raster icon. Probably PNG, but lossless-webp migth work
too.
- A 16x16 raster icon, only if the 32x32 version doesn't downscale
well.
- An svg icon for any other resolution.
What I don't, and probably never will have:
- A msapplication icon for IE 10 on Windows 8.0, for adding sites to the
Windows 8 Start Screen.
- A browserconfig.xml in my site's root directory for adding sites to
the Windows 8.1+ Start Screen/Menu with custom icons.
Since MS dumped IE and switched to Edge, documentation for the above was
never updated. I don't run proprietary operating systems, so I can't
test adding a website to the tiled Start Menu or Windows Task Bar.
Now that MS re-wrote Edge as a Chromium-based browser, I really have no
idea how it handles icons; I'd imagine it just does what Chrome does,
but it probably does some odd witchcraft to support adding sites to
Start or the taskbar. Docs don't seem to exist. Until they update the
docs, I'll assume that adding MS icons would mean supporting a
non-standard IE-specific feature.
Due to its simplicity, my site should render fine in browsers going as
far back as IE5; it even works in KHTML. But there are some lines I
won't cross: it'll probably *render* on IE5 but it won't *load* since
https://seirdy.one is TLS 1.2/1.3 only. And it won't support special
proprietary non-standard extensions.
WTF we're almost at 80 lines. I should've just written a blog post.
- The old icon was too off-center; improve it.
- Add a mask icon
- Replace deprecated apple-touch-icon-precomposed.png with
non-precomposed icon.
- Cache-bust all icons
