~seirdy/seirdy.one

Seirdy's personal website and gemini capsule

c01a306 Receipts for djsumdog's instances

~seirdy pushed to ~seirdy/seirdy.one git

a day ago

566c815 Receipts for new instance

~seirdy pushed to ~seirdy/seirdy.one git

a day ago
View project feed  RSS 

#seirdy.one

sourcehut GitLab mirror GitHub mirror Codeberg mirror

builds.sr.ht status

Code for my personal website, seirdy.one. Built with Hugo.

Also builds my Gemini capsule: gemini://seirdy.one/.

#Dependencies

To build:

  • Hugo 0.93 or later
  • bmake or GNU Make. OpenBSD make (omake) should work too, but I haven't tested it.
  • Git (Hugo uses Git info for features like date last updated)
  • htmlq, to parse HTML when fetching some webring links and for some post-processing.
  • POSIX utils: grep, find, POSIX-compliant /bin/sh, etc.

Before deploying, I use some tools to process the output.

  • xmllint, part of libxml2, to format the generated polygot XHTML5 markup.
  • sd (for advanced multi-line regex operations, much of which exist to fix xmllint's output)

I also apply static compression at max levels, using the following tools:

To deploy:

  • rsync, with SSH and zstd support

To lint:

  • stylelint, invoked using pnpm.
  • lychee, to check broken links.
  • A very recent build of the w3c's Nu HTML checker to validate the HTML and XHTML.
  • jq, to filter false-positives from the Nu HTML checker.

#Build instructions

  • To just build the HTML: make hugo
  • To build the polygot formatted HTML and XHTML: make hugo xhtmlize
  • To lint and validate: make hugo xhtmlize lint-local
  • To build everything and compress: make hugo xhtmlize compress
  • To deploy the clearnet site and corresponding Tor hidden service: make deploy-prod deploy-onion

make can parallelize only a little, since many jobs depend on previous jobs.

#Compatibility

I made the site as inclusive as possible. Tested using multiple screen readers (Orca, TalkBack, Apple VoiceOver, Windows Narrator, NVDA), and I regularly test with the following browsers/engines. Testing in a browser does not imply any sort of endorsement; I just want to meet people where they're at and I want my site to be as robust as possible.

For all the listed options, I test "reading mode" whenever it's available. Most of my testing happens on Linux since that's my main OS, but I sometimes test on a Windows machine.

The main compatibility issue is a lack of support for <details>; the only non-mainstream engine to support it is Servo. The site is still perfectly usable without support for <details>; users will just be annoyed by pre-expanded toggle buttons that don't do anything.

#Desktop

Mainstream engines:

  • Gecko: Nightly, Stable, ESR, and sometimes Pale Moon
  • the Tor Browser
  • Blink: latest Chromium snapshot, stable, and QtWebEngine
  • WebKit, via Webkit2GTK3

Non-mainstream engines:

  • NetSurf
  • The SerenityOS Browser (does not yet support ECDSA-based certs, so I test on my Tildeverse mirror). Known issue: SVG avatar doesn't render unless I view it in a new tab.
  • Very old WebKit via rekonq (Qt4 QtWebKit).
  • KHTML (KF5), via Konqueror.
  • Servo
  • Tkhtml, via Hv3 (no TLS 1.2, so I use a terminating proxy or localhost version)

Tested on a provisional basis, when I have access to a Windows machine:

  • Winternight Classic.
  • IE 11.
  • Even older WebKit, via Safari 5.1.7. Requires a TLS terminating proxy.
  • Ancient Gecko, via NetScape Navigator. Requires a TLS terminating proxy.

Desktop screen readers tested:

  • Orca
  • NVDA
  • Windows Narrator
  • TODO: borrow someone's mac and test macOS VoiceOver.

#Mobile

  • Android: Blink, Gecko, Tor Browser
  • iOS WebKit: latest stable version, iOS 12, iOS 10 on an iPhone 5. Also tested Reader Mode.
  • TODO: try a KaiOS device and Samsung Internet's dark mode.

The site should work well even on viewports that are under 240 CSS pixels wide.

Mobile screen readers:

  • TalkBack
  • VoiceOver
  • TODO: test KaiOS Readout

#Smart watches

  • Borrowed an Apple Watch to try the embedded browser.
  • TODO: test on a Tizen or Wear OS device's browser (Samsung Internet is a popular choice)

#Accessibility

To my knowledge, this site meets all applicable WCAG 2.2 AA requirements.

This site meets all applicable WCAG 2.2 AAA requirements, with the following exceptions:

  • SC 1.4.8 Visual Presentation: long article body text for articles should have an average character count per line below 80 characters. Some lines may exceed this limit. Text outside of article bodies has a longer line width.
  • SC 2.4.9 Link Purpose (Link Only): I mostly follow this guideline, but there may be some exceptions. Link purpose in context is always clear, though.
  • SC 3.1.5 Reading Level: the required reading ability often exceeds the lower secondary education level
  • SC 3.1.6 Pronunciation: I do not yet provide pronunciation information.

I have only tested WCAG compliance in mainstream browser engines (Blink, Gecko, WebKit).

I also go further than WCAG in many aspects.

  • Rather than follow SC 2.5.5's requirement to achieve a minimum tap target size of 44 by 44 pixels, I follow Google's more strict guidelines. These guidelines mandate that targets are at least 48-by-48 pixels, with no overlap against any other targets in a 56-by-56 pixel range.
  • I ensure at least one such 56-by-56 pixel non-interactive region exists on the page, for users with hand tremors or or anyone who wants to tap the screen without clicking something.
  • I only set custom colors in response to the prefers-color-scheme: dark media query. These custom colors pass APCA contrast ratios, all being close to the ideal lightness contrast of 90. They are also autism- and overstimulation-friendly colors: yellow links are significantly de-saturated to reduce harshness.