From 80b6563b2fe777790a49c43513d3d8c8846ae484 Mon Sep 17 00:00:00 2001 From: Rohan Kumar Date: Thu, 17 Nov 2022 17:02:22 -0800 Subject: [PATCH] Manually fix changed/irregular links --- content/about/uses.md | 2 +- content/meta/site-design.md | 4 ++-- content/notes/re-debunking-myths-about-https.md | 2 +- content/notes/resize-and-reflow.md | 2 +- content/posts/keeping-platforms-open.md | 2 +- content/posts/website-best-practices.gmi | 2 +- content/posts/website-best-practices.md | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/about/uses.md b/content/about/uses.md index 02c23d8..f14a276 100644 --- a/content/about/uses.md +++ b/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: diff --git a/content/meta/site-design.md b/content/meta/site-design.md index 0083362..c9cffc6 100644 --- a/content/meta/site-design.md +++ b/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. diff --git a/content/notes/re-debunking-myths-about-https.md b/content/notes/re-debunking-myths-about-https.md index b3b06e9..b8e362f 100644 --- a/content/notes/re-debunking-myths-about-https.md +++ b/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" diff --git a/content/notes/resize-and-reflow.md b/content/notes/resize-and-reflow.md index 8f276d2..f337a30 100644 --- a/content/notes/resize-and-reflow.md +++ b/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: diff --git a/content/posts/keeping-platforms-open.md b/content/posts/keeping-platforms-open.md index 52aa877..b5922f2 100644 --- a/content/posts/keeping-platforms-open.md +++ b/content/posts/keeping-platforms-open.md @@ -147,7 +147,7 @@ The reason societies with democratic governments are better places to live in th {{}} -{{}} {{}} diff --git a/content/posts/website-best-practices.gmi b/content/posts/website-best-practices.gmi index fcd45d9..8ac5bd5 100644 --- a/content/posts/website-best-practices.gmi +++ b/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: diff --git a/content/posts/website-best-practices.md b/content/posts/website-best-practices.md index d865719..ca56acb 100644 --- a/content/posts/website-best-practices.md +++ b/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 {{}}{{}} by {{}}. -If you've got some time on your hands, I _highly_ recommend reading the [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/). The WCAG 2 standard is technology-neutral, so it doesn't contain Web-specific advice. For that, check the [How to Meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref). 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 [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/). The WCAG 2 standard is technology-neutral, so it doesn't contain Web-specific advice. For that, check the [How to Meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref/). 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/).