New note: ai generated alt + img

Saves about a minute of time.

Makefile

@@ -14,6 +14,7 @@ GEMINI_RSYNC_DEST = $(USER):$(GEMINI_ROOT)
 
 OUTPUT_DIR = public
 RSYNCFLAGS += -rlpcv --zc=zstd --zl=6 --skip-compress=gz/br/zst/png/webp/jpg/avif/jxl/mp4/mkv/webm/opus/mp3
+RSYNCFLAGS_EXTRA ?=
 # compression gets slow for extreme levels like the old "70109"
 ECT_LEVEL=9
 
@@ -66,14 +67,14 @@ htmlproofer:
 	htmlproofer $(OUTPUT_DIR) --disable-external --report-invalid-tags --report-missing-names --report-missing-doctype --report-eof-tags --report-mismatched-tags --check-html --check-opengraph --check-favicon --empty-alt-ignore --file-ignore $(OUTPUT_DIR)/search/index.html --url-ignore '../music.txt'
 
 linter-configs/htmltest.yml:
-	rsync $(RSYNCFLAGS) deploy@seirdy.one:/home/deploy/refcache.json linter-configs/htmltest/refcache.json
+	rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) deploy@seirdy.one:/home/deploy/refcache.json linter-configs/htmltest/refcache.json
 
 # basic checks for generated HTML and broken links. Persist the broken
 # link cache remotely so we can run this in CI.
 .PHONY: htmltest
 htmltest: linter-configs/htmltest.yml
 	htmltest -c linter-configs/htmltest.yml $(OUTPUT_DIR)
-	rsync $(RSYNCFLAGS) linter-configs/htmltest/refcache.json deploy@seirdy.one:/home/deploy/refcache.json
+	rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) linter-configs/htmltest/refcache.json deploy@seirdy.one:/home/deploy/refcache.json
 
 .PHONY: hint
 hint: hugo .hintrc-local
@@ -122,11 +123,11 @@ mentions.json: hugo
 
 .PHONY: deploy-html
 deploy-html:
-	rsync $(RSYNCFLAGS) --exclude 'gemini' --exclude '*.gmi' --exclude-from .rsyncignore $(OUTPUT_DIR)/ $(WWW_RSYNC_DEST) --delete
+	rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) --exclude 'gemini' --exclude '*.gmi' --exclude-from .rsyncignore $(OUTPUT_DIR)/ $(WWW_RSYNC_DEST) --delete
 
 .PHONY: deploy-gemini
 deploy-gemini:
-	rsync $(RSYNCFLAGS) --exclude '*.html' --exclude '*.xml' --exclude '*.xhtml' --exclude '*.gz' --exclude '*.br' --exclude-from .rsyncignore $(OUTPUT_DIR)/gemini/ $(OUTPUT_DIR)/about $(OUTPUT_DIR)/posts $(OUTPUT_DIR)/about $(OUTPUT_DIR)/publickey.* $(GEMINI_RSYNC_DEST)/ --delete
+	rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) --exclude '*.html' --exclude '*.xml' --exclude '*.xhtml' --exclude '*.gz' --exclude '*.br' --exclude-from .rsyncignore $(OUTPUT_DIR)/gemini/ $(OUTPUT_DIR)/about $(OUTPUT_DIR)/posts $(OUTPUT_DIR)/about $(OUTPUT_DIR)/publickey.* $(GEMINI_RSYNC_DEST)/ --delete
 
 .PHONY: deploy
 deploy: deploy-html deploy-gemini

assets/css/main.css

@@ -367,12 +367,13 @@ sup {
 /* narrow screens: reduce list indentation, hyphenate nested lists
  * touch screens: lists of links should be easy to tap so give them
  * some spacing (partial SC 2.5.5). There should be non-interactive
- * space to the left that's safe to tap. */
+ * space to the left that's safe to tap.
+ * 1.75em is the minimum required for ol numbers to fit. */
 dd,
 ol,
 ul {
 	margin: 0;
-	padding-left: 1.5em;
+	padding-left: 1.75em;
 }
 
 blockquote,
@@ -425,8 +426,12 @@ h1 {
 	hyphens: auto;
 }
 
-/* Very narrow screens: full hyphenation.
- * This is the typical width of a smart feature phone. */
+/* Very narrow screens: full hyphenation, compactness
+ * This is the typical width of a smart feature phone, or a browser
+ * sidebar. At this tiny width, users are either unlikely to be using a
+ * touchscreen (KaiOS-like feature phones, desktop browser sidebars) or
+ * they're just reading non-interactively. being compact probably takes
+ * precedence over being touch-friendly. */
 @media (max-width: 272px) {
 	body {
 		font-size: 100%;
@@ -441,6 +446,10 @@ h1 {
 		padding: .25em;
 	}
 
+	dd {
+		padding-left: 1em;
+	}
+
 	hr {
 		margin: .25em 0;
 	}
@@ -565,11 +574,11 @@ summary {
 	vertical-align: -.1em;
 }
 
-.h-card a.u-uid {
+.p-author a.u-uid {
 	text-decoration: none;
 }
 
-a .p-name {
+a .u-photo + .p-name {
 	text-decoration: underline;
 }
 

content/notes/ai-generated-images-alt-text.md

@@ -0,0 +1,15 @@
+---
+title: "Re: AI-Generated Images from AI-Generated Alt Text"
+date: 2022-08-05T23:50:16-07:00
+replyURI: "https://adrianroselli.com/2022/08/ai-generated-images-from-ai-generated-alt-text.html"
+replyTitle: "AI-Generated Images from AI-Generated Alt Text"
+replyType: "BlogPosting"
+replyAuthor: "Adrian Roselli"
+replyAuthorURI: "https://adrianroselli.com/"
+---
+
+This is a great post to illustrate the utility of detailed alt-text when an image is the primary content. I think it's less relevant for the more common use of images: as illustrative examples or supplements to surrounding text.
+
+Take an image embedded in an article. Sighted users are capable of viewing a detailed image and instantly filtering for the information that's relevant to the surrounding content. It's harder to do this with a blurb of text, so this situation would call for more a more brief description.
+
+The opposite extreme: the most detailed textual alternatives I work with are image transcripts (e.g. for comics). Flat text is a poor fit; semantic HTML works better. I'm hoping aria-details gains traction in the future and settling for [short alt + long `aria-describedby` text](https://seirdy.one/posts/2020/11/23/website-best-practices/#image-transcripts) in the meantime.

content/posts/website-best-practices.gmi

@@ -356,14 +356,15 @@ A hybrid between the two is paginated content in which users click a "load next
 
 I've discussed loading pages in the background, but what about saving a page offline (e.g. with Ctrl + s)? While lazy-loading won't interfere with the ability to save a complete page offline, some of these related issues can. Excessive pagination and inline scrolling make it impossible to download a complete page without manually scrolling or following pagination links to the end.
 
-### Other ways to defer content
+## Long-page performance
 
-Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
-
-A similar image attribute that I *do* recommend is the "decoding" attribute. I typically use `decoding="async"` so that image decoding can be deferred.
+Deferring network requests is a bad idea, as established in the previous “Against lazy loading” section. There are other ways to improve large-page performance.
 
+An alternative to the loading attribute that I do recommend is the decoding attribute. I typically use decoding="async" so that image decoding can be deferred.
 => https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding <img> decoding on MDN
 
+### CSS containment
+
 Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS specification.
 
 CSS containment allows authors to isolate sub-trees of the DOM. This lets browsers make more informed optimizations: they can delay painting off-screen content or reduce re-calculations when isolated nodes change. Combined with a property like "content-visibility", it enables browsers to defer all rendering of less essential below-the-fold content.
@@ -378,13 +379,29 @@ Using containment for content at the end of the page is relatively safe. Using i
 
 The benefits of containment are especially noticeable when injecting styles into a page. "Dark mode" extensions perform noticeably better when enough elements receive layout and paint containment.
 
+# Performance of assistive technologies
+
+Eric Bailey’s gave a presentation describes how computing the accessibility tree can be expensive if a page has too many DOM nodes and custom elements:
+=> https://noti.st/ericwbailey/Yfyaxa/slides The intersection of performance and accessibility
+
+Browsers use complex heuristics to determine which elements to report, to reduce the size of the accessibility tree. Now that all major browsers are moving to multi-process architectures, some browser components interface with assistive technology (AT) in a separate process. Data about the page’s semantics needs to cross process boundaries, incurring additional overhead.
+
+Re-calculating nodes in the accessibility tree can create small delays for user interaction. These delays add up, causing the accessibility tree to fall out-of-sync with the actual page state. In extreme cases, an out-of-control accessibility tree may crash the AT. Moreover, speech synthesizers may be slow to start speaking when the CPU is under load. Delayed speech synthesis is incredibly annoying because it tends to omit words while “warming up”.
+
+When pages grow long, keep performance in check by doing the following:
+
+* Prefer semantic HTML over custom elements. The browser’s accessibility-tree-generation and element-filtering is optimized for semantic HTML; it has to do more guesswork to decipher custom elements.
+* Avoid scripts that delay user-input or cause complex DOM mutations. These will introduce delays that can cause significant AT usability issues.
+* Remember that CSS can impact the accessibility tree. Avoid using scripts to alter properties such as "display" and "visibility".
+* Test with screen readers on underpowered hardware. Examples include old entry-level Android phones and netbooks with aggressive thermal throttling.
+
 ## In-page search
 
 In-page search (e.g., using "Ctrl + f") has been a basic feature in document readers well before browsers, and continues to be an essential feature today.
 
 Searchability is a good reason to prefer conveying information textually, when possible: video (especially without accurate captions), pictures of text, etc. aren't so easily searchable.
 
-Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; Reddit's atrocious redesign is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in the "other ways to defer content" section.
+Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; Reddit's atrocious redesign is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in the "Long-page performance" section.
 
 => gemini://seirdy.one/misc/find.png searching for the word "good" in the phrase "I wonder how much good a" when a "see more" link obscures the match, before and after revealing the hidden text. From the Reddit redesign.
 

content/posts/website-best-practices.md

@@ -397,11 +397,14 @@ Caption below the panel
 
 {{< /transcribed-image-transcript >}} {{< /transcribed-image >}}
 
-### Other ways to defer content
+Long-page performance
+---------------------
 
-Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
+Deferring network requests is a bad idea, as established in the [previous "Against lazy loading" section](#against-lazy-loading). There are other ways to improve large-page performance.
 
-A similar image attribute that I _do_ recommend is the [`decoding` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding). I typically use `decoding="async"` so that image decoding can be deferred.
+An alternative to the `loading` attribute that I _do_ recommend is the [`decoding` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding). I typically use `decoding="async"` so that image decoding can be deferred.
+
+### CSS containment
 
 Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS specification.[^10]
 
@@ -424,6 +427,22 @@ Leveraging containment and `content-visibility` is a progressive enhancement, so
 
 Using containment for content at the end of the page is relatively safe. Using it for content earlier in the page risks introducing [layout shifts](#layout-shifts). Eliminate the layout shifts by calculating a value for the `contain-intrinsic-size` property. {{<mention-work itemtype="TechArticle">}}{{<cited-work url="https://www.terluinwebdesign.nl/en/css/calculating-contain-intrinsic-size-for-content-visibility/" name="Calculating 'contain-intrinsic-size' for 'content-visibility'" extraName="headline">}}, by {{<indieweb-person first-name="Thijs" last-name="Terluin" url="https://www.terluinwebdesign.nl/en/about-us/thijs-terluin/" org="Teluin Webdesign" org-url="https://www.terluinwebdesign.nl/en/" itemprop="author">}}{{</mention-work>}}, is a comprehensive guide to calculating intrinsic size values.
 
+### Performance of assistive technologies
+
+{{<mention-work itemtype="CreativeWork" itemprop="mentions">}}{{<indieweb-person first-name="Eric" last-name="Bailey" url="https://ericwbailey.design/" itemprop="author" appendString="’s">}} presentation {{<cited-work name="The intersection of performance and accessibility" url="https://noti.st/ericwbailey/Yfyaxa/slides">}}{{</mention-work>}} describes how computing the accessibility tree can be expensive if a page has too many DOM nodes and custom elements. Browsers use complex heuristics to determine which elements to report, to reduce the size of the accessibility tree. Now that all major browsers are moving to multi-process architectures, some browser components interface with assistive technology (<abbr>AT</abbr>) in a separate process. Data about the page's semantics needs to cross process boundaries, incurring additional overhead.
+
+Re-calculating nodes in the accessibility tree can create small delays for user interaction. These delays add up, causing the accessibility tree to fall out-of-sync with the actual page state. In extreme cases, an out-of-control accessibility tree may crash the <abbr>AT</abbr>. Moreover, speech synthesizers may be slow to start speaking when the CPU is under load. Delayed speech synthesis is incredibly annoying because it tends to omit words while "warming up".
+
+When pages grow long, keep performance in check by doing the following:
+
+* Prefer semantic HTML over custom elements. The browser's accessibility-tree-generation and element-filtering is optimized for semantic HTML; it has to do more guesswork to decipher custom elements.
+
+* Avoid scripts that delay user-input or cause complex DOM mutations. These will introduce delays that can cause significant <abbr>AT</abbr> usability issues.
+
+* Remember that CSS can impact the accessibility tree. Avoid using scripts to alter properties such as `display` and `visibility`.
+
+* Test with screen readers on underpowered hardware. Examples include old entry-level Android phones and netbooks with aggressive thermal throttling.
+
 In-page search
 --------------
 
@@ -431,7 +450,7 @@ In-page search (e.g., using <kbd>Ctrl</kbd> + <kbd>f</kbd>) has been a basic fea
 
 Searchability is a good reason to prefer conveying information textually, when possible: video (especially without accurate captions), pictures of text, etc. aren't so easily searchable.
 
-Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; [Reddit's atrocious redesign](#reddit-redesign) is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in [the "other ways to defer content" section](#other-ways-to-defer-content).
+Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; [Reddit's atrocious redesign](#reddit-redesign) is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in [the "Long-page performance" section](#long-page-performance).
 
 {{<image-figure id="reddit-redesign">}}
 

layouts/shortcodes/indieweb-author.html

@@ -22,7 +22,6 @@
 	(btw this is all made of <span> cuz it is supposed to be inline)
 --><span itemprop="author copyrightHolder" itemscope="" itemtype="https://schema.org/Person" itemid="https://seirdy.one/#seirdy" class="h-card p-author author vcard">
 	<a itemprop="url" href="https://seirdy.one/" rel="author me home cc:attributionURL" class="u-url u-uid url" property="cc:attributionName">
-		{{ partial "indieweb-icon.html" }}
-		<span itemprop="name" class="p-name fn n">
+		{{ partial "indieweb-icon.html" -}} <span itemprop="name" class="p-name fn n">
 			<span itemprop="givenName" class="p-given-name given-name">Rohan</span>&#160;<span itemprop="familyName" class="p-family-name family-name">Kumar</span></span></a>
 </span>

layouts/shortcodes/indieweb-icon.html

@@ -2,9 +2,9 @@
 {{- $favicon_base64 := $favicon.Content | base64Encode -}}
 {{- $favicon_svg := resources.Get "/favicon.svg" | resources.Fingerprint "md5" -}}
 {{- if in site.BaseURL ".onion" -}}
-<img itemprop="image" class="u-photo photo" width="16" height="16" alt=""
-	src="data:image/png;base64,{{ $favicon_base64 }}" />
+<img itemprop="image" width="16" height="16" alt=""
+	src="data:image/png;base64,{{ $favicon_base64 }}" class="u-photo photo" />
 {{- else -}}
-<img itemprop="image" class="u-photo photo" width="16" height="16" alt=""
-	src="{{ $favicon_svg.Permalink }}" />
+<img itemprop="image" width="16" height="16" alt=""
+	src="{{ $favicon_svg.Permalink }}" class="u-photo photo" />
 {{- end }}

linter-configs/budget.json

@@ -31,7 +31,7 @@
 			},
 			{
 				"resourceType": "document",
-				"budget": 75
+				"budget": 70
 			},
 			{
 				"resourceType": "image",

scripts/bin/check-whole-site

@@ -61,8 +61,9 @@ base_url="${1-http://localhost:8089}"
 
 # HTML validation is already parallelized, so run that single-threaded.
 make -j1 HUGO_FLAGS=-DF HUGO_BASEURL="$base_url" clean hugo xhtmlize validate-html
-make -j "$jobs" -f Makefile.online HUGO_BASEURL="$base_url" all-extra URLS="$(curl -sSL "$base_url/sitemap.xml" | htmlq loc -t | rg -v '/search/$' | tr '\n' ' ')"
-make deploy-staging -j "$jobs"
+make -j "$jobs" -f Makefile.online HUGO_BASEURL="$base_url" all-extra URLS="$(curl -sSL "$base_url/sitemap.xml" | htmlq loc -t | rg -v '/search/$' | tr '\n' ' ')" &
+make deploy-staging RSYNCFLAGS_EXTRA=-q
+wait
 make -f Makefile.online hint-online URLS="$(curl -sSL --compressed https://staging.seirdy.one/sitemap.xml | htmlq loc -t | rg -v '/(?:search|wcag-is-a-starting-point)/$' | sort | tr '\n' ' ')"
 # TODO: run lighthouse on every page in the sitemap.
 

scripts/xhtmlize-single-file.sh

@@ -35,7 +35,7 @@ sed 7d "$html_file" | xmllint --format --encode UTF-8 --noent - | sd '^\t(?:\t)?
 		| sd '<pre(?: tabindex="0")?>\n\t*<(code|samp)( |>)' '<pre tabindex="0"><$1$2' \
 		| sd '(?:\n)?</(code|samp)>\n(?:[\t\s]*)?</pre>' '</$1></pre>' \
 		| sd '</span>.span itemprop="familyName"' '</span> <span itemprop="familyName"' \
-		| sd '(</picture>|src="[^"]*" ?/>)<span itemprop="name" class="p-name fn n">' '$1 <span itemprop="name" class="p-name fn n">' \
+		| sd -f m 'class="u-photo photo"[^<]*<' 'class="u-photo photo"/> <' \
 		| sd '([a-z])<(data|time)' '$1 <$2' \
 		| sd '</span>(<a[^>]*rel="(?:nofollow ugc|ugc nofollow)"(?:[^>]*)?>liked</a>)' '</span> $1' \
 		| sd -s '/>' ' />'