mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-12-24 01:42:10 +00:00
Spelling, grammar, re-phrasings
This commit is contained in:
parent
7e386b0aa9
commit
7f8e65738b
6 changed files with 12 additions and 12 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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 px, and not overlap any other tap targets within a 56-by-56 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 px, and not overlap any other tap targets within a 56-by-56 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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in a new issue