diff --git a/assets/css/main.css b/assets/css/main.css
index c06633d..b5de646 100644
--- a/assets/css/main.css
+++ b/assets/css/main.css
@@ -3,9 +3,11 @@
* specific a11y, compatibility, or critical
* usability need.
*
- * I also don't use any classes besides "pix". My HTML contains
- * microformats2 classnames for IndieWeb parsers, but I don't actually
- * use those for styling.
+ * I also don't use any classes except for image presentation. (e.g. to
+ * specify that an image should have pixelated rendering or be inverted
+ * in dark mode).
+ * My HTML contains microformats2 classnames for IndieWeb parsers, but I
+ * don't actually use those for styling.
*
* To keep myself from caring about minute details, I limited myself to
* only defining spacing in increments of .125em. Borders are either
@@ -55,7 +57,9 @@ html {
* are addressed by adding some body padding.
* I followed Google's a11y recommendations of "at least 8px space
* between tappables" by creating margins/paddings between nav links;
- * re-use that same amount of space here. 1em + .25em = 1.25em */
+ * re-use that same amount of space here. 24px is what it takes to
+ * create atl 48px of non-interactive space on
and elements
+ * containing lists of interactives. */
padding: 0 24px;
}
@@ -91,11 +95,13 @@ html {
* we need to tell users that the full space is interactive.
* Use a border for that. */
border: 1px solid #999;
-
- /* Google a11y: ensure tap targets have >=8 px space between them */
- margin: .25em 0;
}
+ /* If we have a list of disclosure widgets, we need some
+ * non-interactive space on the screen that's safe to tap. */
+ li details {
+ margin: .5em .25em;
+ }
/* Prevent nested lists from overlapping */
nav li ol {
diff --git a/assets/css/print.css b/assets/css/print.css
index c26b61b..89739d4 100644
--- a/assets/css/print.css
+++ b/assets/css/print.css
@@ -1,6 +1,6 @@
/* Print stylesheet: hide stuff that we don't need. */
@media print {
- /* Currently only used for transcripts */
+ /* Currently only used for transcripts and TOC */
article details,
/* Currently only used for in-page heading anchors,
* useless in printouts. */
@@ -11,6 +11,8 @@
display: none;
}
+ /* The triangle bullet on summary elements gives no actionable
+ * information on print. */
summary {
list-style: none;
}
diff --git a/assets/p/touch_targets.avif b/assets/p/touch_targets.avif
index cafba17..0539cbe 100644
Binary files a/assets/p/touch_targets.avif and b/assets/p/touch_targets.avif differ
diff --git a/assets/p/touch_targets.png b/assets/p/touch_targets.png
index ed5e961..c5a3bab 100644
Binary files a/assets/p/touch_targets.png and b/assets/p/touch_targets.png differ
diff --git a/assets/p/touch_targets_dark.avif b/assets/p/touch_targets_dark.avif
index 0640cb6..a99a5a6 100644
Binary files a/assets/p/touch_targets_dark.avif and b/assets/p/touch_targets_dark.avif differ
diff --git a/assets/p/touch_targets_dark.png b/assets/p/touch_targets_dark.png
index 1dbd4ad..0b1a1ea 100644
Binary files a/assets/p/touch_targets_dark.png and b/assets/p/touch_targets_dark.png differ
diff --git a/content/posts/website-best-practices.md b/content/posts/website-best-practices.md
index 1dd9dcf..a1dcf27 100644
--- a/content/posts/website-best-practices.md
+++ b/content/posts/website-best-practices.md
@@ -320,7 +320,7 @@ Pages should finish making all `GET` network requests while loading. This makes
One example is pagination. It's easier to download one long article ahead of time, but inconvenient to load each page separately. Displaying content all at once also improves searchability. The single-page approach has obvious limits: don't expect users to happily download a single-page novel.
-Another common offender is infinite-scrolling. In addition to requiring JavaScript, infinite-scrolling also makes it difficult for readers to find their old place upon re-visiting a page. This creates harsh consequences for accidental navigation. WordPress documentation lists [more problems with infinite scrolling](https://make.wordpress.org/accessibility/handbook/markup/infinite-scroll/)[^6].
+Another common offender is infinite-scrolling. In addition to requiring JavaScript, infinite-scrolling also makes it difficult for readers to find their old place upon re-visiting a page. This creates harsh consequences for accidental navigation. WordPress documentation lists [more problems with infinite scrolling](https://make.wordpress.org/accessibility/handbook/markup/infinite-scroll/).[^6]
A hybrid between the two is paginated content in which users click a "load next page" link to insert the next page at the end of the current page (typically using "dynamic content replacement"). It's essentially the same as infinite scrolling, except additional content is loaded after a click rather than by scrolling. This is only slightly less bad than infinite scrolling; it still has the same fundamental issue of allowing readers to lose their place.
@@ -721,7 +721,7 @@ Color schemes should also look good to users who apply gamma adjustments. Most o
In defense of link underlines {#in-defense-of-link-underlines}
----------------------------------
-Some typographers insist that [underlined on-screen text is obsolete](https://practicaltypography.com/underlining.html)[^13], and that hyperlinks are no exception. I disagree.
+Some typographers insist that [underlined on-screen text is obsolete](https://practicaltypography.com/underlining.html),[^13] and that hyperlinks are no exception. I disagree.
Readers already expect underlined text to signify a hyperlink. Don't break fundamental affordances for aesthetics. Underlines are also necessary to distinguish the beginnings and ends of multiple consecutive links, especially among color-blind users.
@@ -766,7 +766,7 @@ Some image optimization tools I use:
: The reference WebP encoder; has dedicated lossless and lossy modes. Lossy WebP compression isn't always better than JPEG, but lossless WebP consistently beats PNG.
`avifenc`
-: The reference AVIF encoder, included in [libavif](https://github.com/AOMediaCodec/libavif)[^14]. AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
+: The reference AVIF encoder, included in [libavif](https://github.com/AOMediaCodec/libavif).[^14] AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
I put together [a quick script](https://git.sr.ht/~seirdy/dotfiles/tree/3b722a843f3945a1bdf98672e09786f0213ec6f6/Executables/shell-scripts/bin/optimize-image) to losslessly optimize images using these programs. For lossy compression, I typically use [GNU Parallel](https://www.gnu.org/software/parallel/) to mass-generate images using different options before selecting the smallest image at the minimum acceptable quality. Users who'd rather avoid the command line while performing lossy compression can instead check out [Squoosh](https://squoosh.app/), a JavaScript app that bundles WebAssembly-compiled encoders; I've heard good things about it.
@@ -1032,10 +1032,10 @@ For now, I've decided to keep some indentation on list elements (``, ``,
Readers with hand tremors depend on this space to scroll without accidentally selecting an interactive element; Axess Lab described the issue in {{}}. Readers who double-tap to jump or zoom can't do so if there's no screen region that's "safe to tap". Having clearly distinguished links also helps users decide safe places to tap the screen; see the [section on link underlines](#in-defense-of-link-underlines) for more information.
-{{}} {{