When a figure is in the middle of a section, mobile screen reader users
might not switch away from heading-based navigation. Instead, they might
just jump to the next heading.
Re-organize the page to put some skippable content closer to the end of
sections, and add a section describing the need for this.
Also add a transcript to the screenshot of BMFW, and adopt the new
quotecaption shortcode, and fix some structured data by using some
shortcodes properly.
- Goldmark 1.4.12 switches footnotes from a <section> to a <div>; update
regexes and stylesheet to account for this.
- Goldmark 1.4.12 allows multiple footnotes with the same reference; use
that.
- Clean up templates for unminified output. Also delete an unused class.
- Switch to unminified output by default.
- give code blocks their own figure numbers/names/ID
- Split figcaption into quotecaption and codecaption
- create codefigure partial to reduce markup for SoftwareSourceCode
figures
Create a for <figcaption> and a render hook for code snippets inside
figures, replacing some ugly and complex inline HTML in my markdown
sources.
The only visible change is slightly worse HTML alignment and programming
language indicators (with microdata).
This removed the need to use one of the regex replacements in the
processed_content.html shortcode, and increased the minimum required
Hugo version to 0.93.
Some old browser engines don't fully support hyphenation, so they need
some extra help. Now, the entire site should fit in a 150 CSS-pixel wide
viewport.
Clean up some link text too so the text alone is more useful.
All pages except bookmarks can now fit on your smartwatch without any
adjustments, so we can disable the auto-zoom-out-to-match-mobile
wizardry that watch browsers do (comparable to the
zoom-out-to-match-desktop stuff that early mobile browsers did).
Yay.
- Shrink some excessive alt text
- Remove some redundant links
- Screenreaders that split elements up aren't just on touchscreens
- Mention ChromeVox in list of screen readers
- Move TOC higher in page
- Spelling
- Drop more unused classes
Putting the heading in the navigation element makes the structure more
logical and matches the behavior of most other websites.
Move it before the introduction in my web best practices post.
- Replace hashes in code snippets with variables for screen-readability
- Use hyphens where valid instead of combined words for screen reader
pronunciation
- Typo
- Add WIP section on screen reader support tips not already covered.
- New section on in-page search
- Mention most alt search indexes don't support JS
- Background images bad
- More sample tests: word processors that support HTML
- Mention checking privacy policies for 3p content
- Elaborate on more mainstream examples of color overrides
- Link to CSS WG docs instead of MDN for prefers-contrast since they're
more detailed.
- Specify that I'm just removing margins in <figure> elements for
quotations.
- Add quote describing how blind readers struggle to find non-semantic context
- Mention that longdesc is deprecated by simple hyperlinks. Describe an alternative.
- Transcripts are necessary for machine translation
- Improve alt-text used alongside an image transcript
- Re-phrase a line referring to a previous section; after some
re-arrangements, that section is no longer a "previous" section.
- Replace spatial terminology ("bottom") with sequential terminology
("end")
- Add note on font enumeration without the Font Access API
- Acknowledge testing in grayscale but emphasize that it isn't enough.
- Move defense of link underlines to just after the section on custom
colors, since it's more relevant to it.
- Add xkcd image into the page instead of just linking, since the linked
page content is an image that doesn't include a transcript or
descriptive alt-text.
- Trivial rephrasings
- Make sure that headings don't have the same name as any links, to
avoid creating links with similar names but different purposes
- Remove useless <aside> elements that wrap landmarks.
- Move TOC down a bit, after the intro.
- Elaborate on each image optimization tool
- Mention using GNU Parallel or squoosh.app
- Describe libavif with libaom+butteraugli and the YUV400 color space
- Why you should avoid srcsets based on viewport or display properties
- Fix code snippet for <picture> sample
Threw in some formatting and very minor phrasing fixes.
- Elaborate on how contrast needs to be maintained under different
conditions like different screens, gamma adjustments, and color
blindnesses
- Add my skepticism about progressive decoding.
- Describe how to calculate intrinsic side to avoid layout-shifts caused
by CSS Containment
- Mention use of relative font sizes.
- Replace incorrect use of the word "inline" when describing images.
- Cite WAI more
- Mention merit of dark image variants
- Fix shitty ARIA
- use a <dl> list in one place.
- Describe use of `prefers-contrast: less`
- Narrow screen fixes.
- Give the intro a heading
- Make the preface an <aside> with a "doc-preface" DPUB-ARIA role
- Move the TOC before the intro
- Give the TOC a "doc-toc" DPUB-ARIA role
- Provide a TLDR
- Mention that captions can be repositioned relative to figure content
- Edit my captions in light of that fact
- Add unformatted/plain-text agents to "future work"
- Lowercase a heading
Describe how to best include images and figures in a way that flows well
and is accessible to both sighted and non-sighted users.
Describe how sticky elements can be a usability hazard on short
viewports
- Add changefreq
- Clean up structured data for quotations
- Add more sample unorthodox tests
TODO: dark image variant of image in new "Beyond alt-text" section
Fediverse users gave good feedback, and I found other info elsewhere.
- Avoid the system-ui font
- Re-clarify article scope (textual websites)
- Mention dynamic content injection
- Describe saving pages offline
- Mention pictures of text versus narrow viewports
- Remove unnecessary info on why i removed margins from figures
- Mention indentation in preformatted code
- Describe appropriate size ranges for inlining images.
- Mention possibility of reporting issues in reading mode section
- Add info on screen readers changing kb nav to "future updates"
- Add info on special keyboard-driven browsers to "future updates"
- Describe best-practices for alt-text, figcaptions, and briefly
mention transcripts.
- Add a conclusion
Also fix anchors for headings containing HTML entities and some minor
fixes throughout.
- Mention calculation of font metrics
- Add related issues to lazy loading
- Justify importance of dark themes
- Trivial formatting tweak in a <pre> block
- Mention OCSP stapling, 0-RTT
- Spelling/grammar help machine translation
- Add more details to "future work" section
- Acknowledge Axess Lab
Add a better screenshot showcasing bad custom colors. Also give it a
figcaption.
The figcaption meant that I had to revise a statement later down when I
said I don't use figcaptions for images.
Ask.moe uses Google Custom Search now, so it's not a search engine
anymore; it's a search client.
Lots of people asked about You.com so I put it under Bing.
These recommendations also included stuff for <figure> elements; in the
spirit of dogfooding, I used some <figure> elements where appropriate
elsewhere in the page.
- Describe how contrast overkill in dark mode can cause halation
- Add more info on compatibility with the Tor browser
- Mention the rationale for a custom image border color
- More accurately note how in addition to fontconfig mappings, I also
set my browser preferred font to "sans-serif".
- Clarify that underlines help identify both the beginnings and ends of
hyperlinks.
- Formatting/phrasing fixes, esp in Gemtext.
- Expand "rationale" with info on bias
- "rationale" got bigger so I added sub-headings
- Move "rationale" section to the bottom since its increased size pushed
away the actual engines
All pages should now look good on screens 230px wide (DPR=1), inc. most
feature-phones running e.g. KaiOS.
Add borders to images so they look distinct from the surrounding page.
This should reduce a lot of repetition. Supports first/last names,
nicknames, generic names that don't conform to first/last norms, and
has basic support for affiliated organizations.
Also snuck in more info on website colors to the web best practices
article, inc. a link to Chris' Wiki.
This requires making <nav> *not* display inline except for the
unstyled-list navlinks. This should also do a better job at appeasing
reader modes.
For the same reason, also make one link a citation
- Explain how FLOSS can allow transparency into the development
processes
- Give examples of proprietary software that's more secure
- Make the conclusion just a little more detailed.
