Fix non-interactive space section & impl

Improve non-interactive space on the homepage and use a better
screenshot to illustrate the concept.

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
+ * I also don't use any classes except for image presentation. (e.g. to
- * microformats2 classnames for IndieWeb parsers, but I don't actually
+ * specify that an image should have pixelated rendering or be inverted
- * use those for styling.
+ * 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 <ul> and <ol> 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 {

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;
 	}

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 under­lines {#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 Web­Assembly-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 (`<ol>`, `<dl>`,
 
 Readers with hand tremors depend on this space to scroll without accidentally selecting an interactive element; <span itemprop="citation" itemscope itemtype="https://schema.org/BlogPosting"><span itemprop="publisher">Axess Lab</span> described the issue in {{<cited-work name="Hand Tremors and the giant button problem" url="https://axesslab.com/hand-tremors/" extraName="headline">}}</span>. 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.
 
-{{<image-figure>}} {{<picture name="touch_targets" alt="Phone screen has three touch-targets separated by sections labeled \"space\".">}}
+{{<image-figure>}} {{<picture name="touch_targets" alt="List of rectangles with a 56 pixel wide square to its left, filling negative space.">}}
 
 <figcaption itemprop="caption">
-Interactive content should be separated by non-interactive regions, such as whitespace or plain non-interactive text. Image credit: Axess Lab
+I made sure to leave enough non-interactive space in <a href="../../../#webrings">my homepage&rsquo;s webring list</a> to accommodate a 48&nbsp;px tap target, with extra space in between.
 </figcaption>
 {{</image-figure>}}
 
@@ -1045,7 +1045,9 @@ Always make sure one non-interactive region exists on the screen at a time, 48 C
 
 Tap targets should be at least 44 pixels tall and wide [according to the WCAG](https://www.w3.org/TR/WCAG22/#target-size-enhanced); this is large enough to easily tap on a touch&shy;screen. The WCAG makes an exception for inline targets, like links in a paragraph.
 
-[Google has more aggressive tap-target recommen&shy;dations](https://web.dev/tap-targets/ "{id='google-tap-target'}"): it recommends raising the limit 48&nbsp;px with with 8&nbsp;px gaps, going so far as to make tap target size a ranking factor in search. The edges of a touch screen are often tap-targets (the top edge might toggle navigation or scroll to the top, the bottom may have home/back buttons, and the right side may have a scrollbar), so keep elements slightly away from those.
+[Google has more aggressive tap-target recommen&shy;dations](https://web.dev/tap-targets/ "{id='google-tap-target'}"): it recommends raising the limit 48&nbsp;px with with 8&nbsp;px gaps, going so far as to make tap target size a ranking factor in search.
+
+The edges of a touch screen are often tap-targets (the top edge might toggle navigation or scroll to the top, the bottom may have home/back buttons, and the right side may have a scrollbar), so keep elements slightly away from those. Keeping away from edges is doubly important on phones: they may have rounded edges that are easy to miss-tap, or reinforced cases that make the very edge of a screen difficult to reach.
 
 On lists without visible bullets, I dropped the default indentation. I had to find other ways to ensure adequate tap-target size and provide sufficient non-interactive space for readers with hand-tremors to scroll. Some examples: