Manually fix changed/irregular links

content/about/uses.md

@@ -255,7 +255,7 @@ jq
 [htmltest](https://github.com/wjdp/htmltest) OR [html-proofer](https://github.com/gjtorikian/html-proofer)
 : Two very similar tools. html-proofer is slow but supports more features; I run the faster htmltest more often. They check for broken links, markup errors, and valid icons. htmltest's ability to cache links is really useful: instead of testing nearly two thousand links every run, I can spread the load over the course of a week. It's also much easier to build a static binary of htmltest than other link-checkers, like Lychee.
 
-[webhint](https://webhint.io)
+[webhint](https://webhint.io/)
 : When all the aforementioned tests pass, my staging site deploys and webhint runs on every page in its sitemap. Webhint checks HTTP headers, validates the Web App Manifest, ensures caching and compression work, checks for compatibility issues, validates compliance with a performance budget, and looks for common HTML/CSS mistakes. I skip its axe-based tests, since those are already covered by axe-core.
 
 Tools I have yet to add to this section:

content/meta/site-design.md

@@ -63,7 +63,7 @@ I also accept user feedback. Feel free to contact me through any means linked on
 The following automated tools supplement manual testing:
 
 - [axe-core](https://github.com/dequelabs/axe-core)
-- [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/toolkit/verify/automated)
+- [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/toolkit/verify/automated/)
 - [AInspector](https://github.com/ainspector/ainspector-for-firefox)
 - [WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/)
 - [ARC Toolkit](https://www.tpgi.com/arc-platform/arc-toolkit/)
@@ -179,7 +179,7 @@ I've implemented several features from IndieMark:
 
 - Microformats: representative `h-card`, in-text `h-card` and `h-cite` when referencing works, `h-feed`.
 
-- Sending and receiving Webmentions. I receive Webmentions with [webmentiond](https://github.com/zerok/webmentiond), and send them from my own computer using [Pushl](https://github.com/PlaidWeb/Pushl).
+- Sending and receiving Webmentions. I receive Webmentions with [webmentiond](https://github.com/zerok/webmentiond), and send them from my own computer using [Pushl](https://github.com/PlaidWeb/Pushl/).
 
 - Displaying Webmentions: I render backlinks, IndieWeb "likes" (not silo likes), and comments below posts. I model their appearance after Tumblr's display of interactions.
 

content/notes/re-debunking-myths-about-https.md

@@ -1,7 +1,7 @@
 ---
 title: "Re: debunking myths about HTTPS"
 date: 2022-09-19T14:39:08-07:00
-replyURI: "https://blog.julien-maury.dev/en/snippets/https-myths/"
+replyURI: "https://web.archive.org/web/20220919214257/https://blog.julien-maury.dev/en/snippets/https-myths/"
 replyTitle: "Debunking myths about HTTPS"
 replyType: "Article"
 replyAuthor: "Julien Maury"

content/notes/resize-and-reflow.md

@@ -5,7 +5,7 @@ replyURI: "https://yatil.net/blog/resize-text-reflow"
 replyTitle: "WCAG SC 1.4.4 Resize Text and 1.4.10 Reflow"
 replyType: "BlogPosting"
 replyAuthor: "Eric Eggert"
-replyAuthorURI: "https://yatil.net"
+replyAuthorURI: "https://yatil.net/"
 ---
 
 This is a good article on the difference between SC 1.4.4 and 1.4.10. However, I don't think these criteria go far enough:

content/posts/keeping-platforms-open.md

@@ -147,7 +147,7 @@ The reason societies with democratic governments are better places to live in th
 
 </blockquote>
 {{<quotecaption partOfType="OpinionNewsArticle">}}
-{{<indieweb-person first-name="Nathan" last-name="Myhrvold" url="http://www.nathanmyhrvold.com/" itemprop="author">}},
+{{<indieweb-person first-name="Nathan" last-name="Myhrvold" url="https://www.nathanmyhrvold.com/" itemprop="author">}},
 {{<cited-work name="The Virtue of Inefficient Government" url="https://slate.com/news-and-politics/1996/10/the-virtue-of-inefficient-government.html" extraName="headline">}}
 {{</quotecaption>}}
 {{</quotation>}}

content/posts/website-best-practices.gmi

@@ -1770,7 +1770,7 @@ If you've got some time on your hands, I *highly* recommend reading the WCAG:
 
 The WCAG 2 standard is technology-neutral, so it doesn't contain Web-specific advice. For that, check the the how-to quick reference. It combines the WCAG with its supplementary list of techniques:
 
-=> https://www.w3.org/WAI/WCAG22/quickref How to Meet WCAG (Quick Reference)
+=> https://www.w3.org/WAI/WCAG22/quickref/ How to Meet WCAG (Quick Reference)
 => https://www.w3.org/WAI/WCAG22/Techniques/ Techniques for WCAG 2.2
 
 The WCAG are an excellent starting point for learning about accessibility, but make for a poor stopping point. Much of the content on this page simply isn't covered by the WCAG. One of my favorite resources for learning about what the WCAG *doesn't* cover is Axess Lab:

content/posts/website-best-practices.md

@@ -1841,7 +1841,7 @@ The [Web Bloat Score calculator](https://www.webbloatscore.com/) is a JavaScript
 
 One resource I found useful (that eventually featured this article!) was the "Your page content" section of {{<mention-work itemprop="citation" itemtype="TechArticle">}}{{<cited-work name="Your Personal Website" url="https://www.billdietrich.me/YourPersonalWebSite.html" extraName="headline">}} by {{<indieweb-person first-name="Bill" last-name="Dietrich" url="https://www.billdietrich.me" itemprop="author">}}{{</mention-work>}}.
 
-If you've got some time on your hands, I _highly_ recommend reading the <cite>[Web Content Accessibility Guidelines (WCAG)&nbsp;2.2](https://www.w3.org/TR/WCAG22/)</cite>. The WCAG 2 standard is technology-neutral, so it doesn't contain Web-specific advice. For that, check the <cite>[How to Meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref)</cite>. It combines the WCAG with its supplementary [list of techniques](https://www.w3.org/WAI/WCAG22/Techniques/).
+If you've got some time on your hands, I _highly_ recommend reading the <cite>[Web Content Accessibility Guidelines (WCAG)&nbsp;2.2](https://www.w3.org/TR/WCAG22/)</cite>. The WCAG 2 standard is technology-neutral, so it doesn't contain Web-specific advice. For that, check the <cite>[How to Meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref/)</cite>. It combines the WCAG with its supplementary [list of techniques](https://www.w3.org/WAI/WCAG22/Techniques/).
 
 The WCAG are an excellent starting point for learning about accessibility, but make for a poor stopping point. Much of the content on this page simply isn't covered by the WCAG. One of my favorite resources for learning about what the WCAG _doesn't_ cover is [Axess Lab's articles](https://axesslab.com/articles/).