fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-27 14:12:09 +00:00
Code Issues Projects Releases Wiki Activity

Spelling, grammar, re-phrasings

Browse source
This commit is contained in:
Rohan Kumar 2022-08-23 09:20:36 -07:00
parent 7e386b0aa9
commit 7f8e65738b
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
6 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/about/uses.gmi
View file

@ -17,7 +17,7 @@ Here's the software I use. I've recently started to reduce my use of TUIs in fav
* Image viewer: mpv (one less program to keep track of), swayimg. Both support AVIF and JPEG-XL now.
* Session manager: tmux (I don't use it for tiling, Sway handles that)
* IRC client: WeeChat. Might use senpai eventually, if I can get it to play well with espeak-ng.
* News: Newsboat. I'm thinking of switching to an feed-to-IMAP or Maildir setup eventually so I can get sync and use mblaze, and replace a TUI with a CLI. Ideally something that supports WebSub.
* News: Newsboat. I'm thinking of switching to a feed-to-IMAP or Maildir setup eventually so I can get sync and use mblaze, and replace a TUI with a CLI. Ideally something that supports WebSub.
* Screen reader: Orca
=> https://sr.ht/~seirdy/mpd-scripts/ mpd-scripts page

6
content/about/uses.md
View file

@ -18,10 +18,10 @@ Environment
Fedora 36
: Primary OS. Uses Linux, Systemd, GNU libc, GNU coreutils, and SELinux.
: Primary OS. Uses Linux, Systemd, GNU libc, GNU coreutils, dnf, firewalld, and SELinux.
Sway
: Dynamic Wayland compositor that focus on tiling window management.
: Dynamic Wayland compositor that focuses on tiling window management but also supports tabbed and stacking layouts.
Zsh
: Login shell. POSIX-compatible and mostly Bash-compatible. Custom static build to skip checking system files and improve startup performance.
@ -59,7 +59,7 @@ WeeChat
: IRC client. I might use [senpai](https://sr.ht/~taiite/senpai/) eventually, if I can get it to play well with espeak-ng.
Newsboat
: Feed reader for RSS and Atom feeds. I'm thinking of switching to an feed-to-IMAP or Maildir setup eventually so I can get sync and use mblaze, and replace a TUI with a CLI. Ideally something that supports [WebSub.](https://websub.net/draft)
: Feed reader for RSS and Atom feeds. I'm thinking of switching to a feed-to-IMAP or Maildir setup eventually so I can get sync and use mblaze, and replace a TUI with a CLI. Ideally something that supports [WebSub.](https://websub.net/draft)
Orca
: Screen reader. Great for when I'm dealing with overstimulation and need to "turn everything off" for a while. I don't actually rely on this to use my machine.

4
content/meta/site-design.md
View file

@ -91,7 +91,7 @@ Alternative engines
: I test compatibility with current alternative engines: the SerenityOS browser, Servo, NetSurf, Kristall, and litehtml. I have excellent compatibility with litehtml and Servo. The site is usable in NetSurf, and the SerenityOS browser. Only Servo supports `<details>`. [The SerenityOS browser doesn't support ECDSA certificates](https://github.com/SerenityOS/serenity/issues/14160), but the Tildeverse mirror works fine. The SerenityOS browser also has some issues displaying my SVG avatar; it does not attempt to use the PNG fallback.
Textual browsers
: The site works well with textual browsers. Lynx and Links2 are first-class citizens for which all features work as intended. I also test in [felinks (an ELinks fork)](https://github.com/rkd77/elinks), edbrowse, and w3m. [w3m doesn't support soft hyphens](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830173), but the site is still otherwise usable in it. I maintain compatibility with these engines by making CSS a strictly-optional progressive enhancement and using semantic markup. I also test with ; I occasionally try Edbrowse too. In all textual browsers, the aforementioned incomplete `<details>` handling applies.
: The site works well with textual browsers. Lynx and Links2 are first-class citizens for which all features work as intended. I also test in [felinks (an ELinks fork)](https://github.com/rkd77/elinks), edbrowse, and w3m. [w3m doesn't support soft hyphens](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830173), but the site is still otherwise usable in it. I maintain compatibility with these engines by making CSS a strictly-optional progressive enhancement and using semantic markup. I occasionally try Edbrowse too. In all textual browsers, the aforementioned incomplete `<details>` handling applies.
Abandoned engines
: I occasionally test abandoned engines, sometimes with a TLS-terminating proxy if necessary. These engines include Tkhtml, KHTML, Dillo,[^1] Internet Explorer[^2] (with and without compatibility mode), Netscape Navigator, old Presto-based Opera versions,[^3] and outdated versions of current browsers. The aforementioned issue with `<details>` applies to all of these choices. I use Linux, but testing in browsers like Internet Explorer depends on my access to a Windows machine. Besides the `<details>` issues, the site works perfectly well in Internet Explorer 11 and Opera Presto. The site has layout issues but remains usable in Tkhtml, KHTML, and Netscape.
@ -121,7 +121,7 @@ This site is **parser-friendly.** It uses well-formed polygot (X)HTML5 markup co
I make Atom feeds available for articles and notes, and have a combined Atom feed for both. These feeds are enhanced with Ostatus and ActivityStreams XML namespaces.
All HTML pages have an XHTML5 counterpart, which is currently the same except for the presence of an XML declaration. To see this counterpart, add "index.xhtml" to the end of a URL or request a page with an `Accept` header containing `application/xhtml+xml` but not `text/html`. All pages parse correctly using all the XHTML browser parsers I could try.
All HTML pages have an XHTML5 counterpart, which is currently the same except for the `content-type` HTTP header. To see this counterpart, add "index.xhtml" to the end of a URL or request a page with an `Accept` header containing `application/xhtml+xml` but not `text/html`. All pages parse correctly using all the XHTML browser parsers I could try.
### Reading mode compatibility

8
content/meta/wcag-conformance.md
View file

@ -114,7 +114,7 @@ Principle 1: Perceivable
: I supply a focus indicator with excellent contrast ([ST G195](https://w3c.github.io/wcag/techniques/general/G195)) and give all graphics a border, should their background colors blend into the page background. Borders follow guidelines for non-text contrast. Any graphic containing text that must be read also has a transcript available.
[SC 1.4.12: Text Spacing](https://w3c.github.io/wcag/understanding/text-spacing.html)
: My entire stylesheet is optional, and overrides of anything related to the forms of spacing or sizing covered by the SC should not cause any issues. Furthermore, I line spacing to 1.5 using CSS ([ST C21](https://w3c.github.io/wcag/techniques/css/C21)). I do not set word, letter, and paragraph spacing; these are all set by the user-agent.
: My entire stylesheet is optional, and overrides of anything related to the forms of spacing or sizing covered by the SC should not cause any issues. Furthermore, I set line spacing to 1.5 using CSS ([ST C21](https://w3c.github.io/wcag/techniques/css/C21)). I do not set word, letter, and paragraph spacing; these are all set by the user-agent.
[SC 1.4.13: Content on Hover or Focus](https://w3c.github.io/wcag/understanding/content-on-hover-or-focus.html)
: The only content available on hover is content exposed by a `title` attribute. I ensure that this content is not made exclusively available through the `title` attribute; it must also be visible in the surrounding text, or previously in the document. Moreover: content exposed by the `title` attribute is actually an exception listed by this SC, so I pass.
@ -128,7 +128,7 @@ I fully pass all guidelines under Principle 2 at the A and AA levels. SC 2.4.9 L
[SC 2.1.1: Keyboard](https://w3c.github.io/wcag/understanding/keyboard.html) OR [SC 2.1.3: Keyboard (No exception)](https://w3c.github.io/wcag/understanding/keyboard-no-exception.html)
: I don't use any scripts, only vanilla HTML elements and their built-in functionlaity ([ST H91](https://w3c.github.io/wcag/techniques/html/H91)). Additionally, I ensure that non-interactive but horizontally-scrollable elements are focusable, such as `<pre>` elements.
: I don't use any scripts, only vanilla HTML elements and their built-in functionality ([ST H91](https://w3c.github.io/wcag/techniques/html/H91)). Additionally, I ensure that non-interactive but horizontally-scrollable elements are focusable, such as `<pre>` elements.
[SC 2.1.2: No Keyboard Trap](https://w3c.github.io/wcag/understanding/no-keyboard-trap.html)
: Nothing on this site can trigger a keyboard trap in a compliant browser, as I only use vanilla (X)HTML elements.
@ -159,7 +159,7 @@ There is absolutely no animation or flashing content on any of my pages, save fo
: I use navigation landmarks and headings to bypass blocks. This includes [ST ARIA11](https://w3c.github.io/wcag/techniques/aria/ARIA11) and [ST H69](https://w3c.github.io/wcag/techniques/html/H69). I also follow advisory techniques [C6: Positioning content based on structural markup](https://w3c.github.io/wcag/techniques/css/C6) and [H97: Grouping related links using the nav element](https://w3c.github.io/wcag/techniques/html/H97). Later, I also adopted [ST G1](https://w3c.github.io/wcag/techniques/general/G1) by adding a skip-link to jump to the main content
[SC 2.4.2: Page Titled](https://w3c.github.io/wcag/understanding/page-titled.html)
: All pages use the `title` element ([ST H25](https://w3c.github.io/wcag/techniques/html/H25). I regularly crawl my entire site with HTML-Proofer, which should automatically flag any exceptions.
: All pages use the `title` element ([ST H25](https://w3c.github.io/wcag/techniques/html/H25)). I regularly crawl my entire site with HTML-Proofer, which should automatically flag any exceptions.
[SC 2.4.3: Focus Order](https://w3c.github.io/wcag/understanding/focus-order.html)
: I adopt [ST C27](https://w3c.github.io/wcag/techniques/css/C27): my source, visual, and DOM order are identical (assuming you read top-to-bottom, left-to-right)
@ -207,7 +207,7 @@ There is absolutely no animation or flashing content on any of my pages, save fo
: My site has no motion-actuation events. Any motion actuation changes (e.g. changing device orientation) are provided and configured by the operating system.
[SC 2.5.5: Target Size (Enhanced)](https://w3c.github.io/wcag/understanding/target-size-enhanced.html) OR [SC 2.5.8: Target Size (Minimum)](https://w3c.github.io/wcag/understanding/target-size-minimum.html)
: I exceed both of these criteria by instead following Google's more aggressive tap-target recommendations: all tap targets that are not part of body text should be at least 48-by-48&nbsp;px, and not overlap any other tap targets within a 56-by-56&nbsp;px region. Section permalinks, navigation links, links in description-list described term, footnote backlinks, etc. all meet these requirements. Lighthouse's "SEO" audits can automatically flag a small subset of violations.
: I exceed both of these criteria by instead following Google's more aggressive tap-target recommendations: all tap targets that are not part of body text should be at least 48-by-48&nbsp;px, and not overlap any other tap targets within a 56-by-56&nbsp;px region. Section permalinks, navigation links, links in description-list described terms, footnote backlinks, etc. all meet these requirements. Lighthouse's "SEO" audits can automatically flag a small subset of violations.
[SC 2.5.6: Concurrent Input Mechanisms](https://w3c.github.io/wcag/understanding/concurrent-input-mechanisms.html)
: I do not restrict any input modalities, as I use only native elements and do not use any scripts.

2
content/posts/cli-best-practices.gmi
View file

@ -62,7 +62,7 @@ This is a non-exhaustive list of simple, baseline recommendations for designing
2. Refer to the latest WCAG publication (currently WCAG 2.2) and take a look at the applicable criteria. Many have accompanying techniques for plain-text interfaces:
=> https://w3c.github.io/wcag/techniques/#text WCAG techniques page
Avoiding reliance on color and using whitespace and/or indentation for pseudo-headings are two sample recommendations from the WCAG.
Avoiding reliance on color in favor of whitespace and/or indentation for pseudo-headings are two sample recommendations from the WCAG.
3. Make sure your web-based documentation and forge frontends are accessible, or are mirrored somewhere with good accessibility. I love what the Gitea folks are doing, but sadly their web frontend has a number of critical issues.[6] For now, if your forge has accessibility issues, mirroring to GitHub and/or Sourcehut seems like a good option.

2
content/posts/cli-best-practices.md
View file

@ -83,7 +83,7 @@ This is a non-exhaustive list of simple, baseline recommendations for designing
1. Send your tool's output through a program like `espeak-ng` and listen to it. Can you make sense of the output?
2. Refer to the latest <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> publication (currently WCAG 2.2) and take a look at the applicable criteria. Many have [accompanying techniques for plain-text interfaces.](https://w3c.github.io/wcag/techniques/#text). Avoiding reliance on color and using whitespace and/or indentation for pseudo-headings are two sample recommendations from the WCAG.
2. Refer to the latest <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> publication (currently WCAG 2.2) and take a look at the applicable criteria. Many have [accompanying techniques for plain-text interfaces.](https://w3c.github.io/wcag/techniques/#text). Avoiding reliance on color in favor of whitespace and/or indentation for pseudo-headings are two sample recommendations from the WCAG.
3. Make sure your web-based documentation and forge frontends are accessible, or are mirrored somewhere with good accessibility. I love what the Gitea folks are doing, but sadly their web frontend has a number of critical issues.[^2] For now, if your forge has accessibility issues, mirroring to GitHub and/or Sourcehut seems like a good option.