mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-09-19 20:02:10 +00:00
Adjust image transcript approach
- Use section instead of nested article - Adjust stylesheets to match above markup changes - Mention upcoming aria-details
This commit is contained in:
Rohan Kumar
parent
3f7e32e70f
commit
a9039e1bde
6 changed files with 63 additions and 63 deletions
3
Makefile
3
Makefile
|
|
@ -116,7 +116,7 @@ all: test deploy
|
|||
.PHONY: deploy-envs
|
||||
deploy-envs:
|
||||
@$(MAKE) NO_STATIC=1 HUGO_FLAGS='--gc' USER=seirdy@envs.net WWW_ROOT=/home/seirdy/public_html GEMINI_ROOT=/home/seirdy/public_gemini HUGO_BASEURL='https://envs.net/~seirdy/' OUTPUT_DIR=public_envs hugo
|
||||
@$(MAKE) NO_STATIC=1 HUGO_FLAGS='--gc' USER=seirdy@envs.net WWW_ROOT=/home/seirdy/public_html GEMINI_ROOT=/home/seirdy/public_gemini HUGO_BASEURL='https://envs.net/~seirdy/' OUTPUT_DIR=public_envs deploy
|
||||
@$(MAKE) NO_STATIC=1 HUGO_FLAGS='--gc' USER=seirdy@envs.net WWW_ROOT=/home/seirdy/public_html GEMINI_ROOT=/home/seirdy/public_gemini HUGO_BASEURL='https://envs.net/~seirdy/' OUTPUT_DIR=public_envs lint-local deploy
|
||||
|
||||
.PHONY: deploy-prod
|
||||
deploy-prod:
|
||||
|
|
@ -126,6 +126,7 @@ deploy-prod:
|
|||
@$(MAKE) deploy
|
||||
|
||||
|
||||
# linting and compression can happen in parallel
|
||||
.PHONY: deploy-staging
|
||||
deploy-staging:
|
||||
@$(MAKE) HUGO_BASEURL=https://staging.seirdy.one HUGO_FLAGS='--gc' DOMAIN=staging.seirdy.one USER=deploy@seirdy.one OUTPUT_DIR=public_staging clean
|
||||
|
|
|
|||
|
|
@ -199,19 +199,20 @@ kbd {
|
|||
/* narrow screens: remove unused figure margins
|
||||
* figure captions shouldn't look like regular paragraphs; there should
|
||||
* be some extra space.
|
||||
* This does not hold true for figures in nested articles; the nested
|
||||
* article should instead get the spacing. */
|
||||
article,
|
||||
* This does not hold true for figures in somewhat distinct sections; the
|
||||
* section should instead get the spacing. A section that constitutes a
|
||||
* separate schema.org object would qualify. */
|
||||
section[itemprop="mentions"],
|
||||
figure {
|
||||
margin: 1.5em 0;
|
||||
}
|
||||
|
||||
div[itemprop="articleBody"] > article > figure {
|
||||
section[itemprop="mentions"] > figure {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
/* figcaptions should be distinct from surrounding paragraphs tho */
|
||||
article[itemtype="https://schema.org/ImageObject"] figcaption,
|
||||
section[itemtype="https://schema.org/ImageObject"] figcaption,
|
||||
figure[itemtype="https://schema.org/ImageObject"] figcaption {
|
||||
contain: content;
|
||||
margin: 0 10%;
|
||||
|
|
@ -292,7 +293,7 @@ section[role="doc-endnotes"] {
|
|||
}
|
||||
|
||||
/* Contain figures that are not images. */
|
||||
:not(div[itemprop="articleBody"]) > :not(article) > figure:not([itemtype="https://schema.org/ImageObject"]) {
|
||||
:not(section[itemprop="mentions"]) > figure:not([itemtype="https://schema.org/ImageObject"]) {
|
||||
contain: content;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -20,17 +20,9 @@
|
|||
}
|
||||
}
|
||||
|
||||
/* Print: don't orphan headings
|
||||
* Commented out bc most browsers don't obey this yet. */
|
||||
/* h2, */
|
||||
/* h3, */
|
||||
/* h4 { */
|
||||
/* break-after: avoid; */
|
||||
/* } */
|
||||
|
||||
/* Print: don't break up self-contained items. */
|
||||
figure,
|
||||
article article,
|
||||
section[itemprop="mentions"],
|
||||
li {
|
||||
break-inside: avoid;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ cache-control: max-age=31557600, immutable
|
|||
|
||||
### Inline content
|
||||
|
||||
In addition to HTML, CSS is also a blocking resource. You could pre-load your CSS using a "link" header. Alternatively: if your gzipped CSS is under one kilobyte, consider inlining it in the <head> using a <style> element. Simply inlining stylesheets can pose a security threat, but the "style-src" CSP directive can mitigate this if you include a hash of your inline stylesheet sans trailing whitespace.
|
||||
In addition to HTML, CSS is also a blocking resource. You could pre-load your CSS using a "link" header. Alternatively: if your compressed CSS is under one kilobyte, consider inlining it in the <head> using a <style> element. Simply inlining stylesheets can pose a security threat, but the "style-src" CSP directive can mitigate this if you include a hash of your inline stylesheet sans trailing whitespace.
|
||||
|
||||
Consider inlining images under 250 bytes with a "data:" URI; that's the size at which cache-validation requests might outweigh the size of the image. My 32-pixel PNG site icon is under 150 bytes and inlines quite nicely. On this site's hidden service, it's often the only image on a page (that the hidden service replaces SVGs with PNGs; see the section called "The Tor Browser"). Inlining this image and the stylesheet allows my hidden service's homepage to load in a single request, which is a welcome improvement given the round-trip latency that plagues onion routing implementations.
|
||||
|
||||
|
|
@ -510,14 +510,14 @@ A StackOverflow thread about comic transcripts outlines a good approach to seman
|
|||
|
||||
=> https://stackoverflow.com/questions/65564539/what-is-the-semantically-correct-way-to-include-transcript-from-a-comic What is the semantically correct way to include transcript from a comic?
|
||||
|
||||
My approach is similar. I group an image, alt-text, and caption in a <figure> element and follow it with a transcript in a <details> element. I use "aria-describedby" to semantically link the figure and the transcript.
|
||||
My approach is similar. I group an image, alt-text, and caption in a <figure> element and follow it with a transcript in a <details> element. I use "aria-describedby" to semantically link the figure and the transcript.⁸
|
||||
|
||||
An image, alt-text, figure caption, and transcript combine to form a complex relationship that should be grouped together in a single landmark. I put all three inside an <article> with a heading, and give the group an "aria-label" that indicates the presence of the three sub-elements. Using an article landmark ensures that the figure and caption remain together as a single unit.
|
||||
An image, alt-text, figure caption, and transcript combine to form a complex relationship that should be grouped together in a single landmark. I put all three inside a <section> with a heading, and give the group an "aria-label" that indicates the presence of the three sub-elements. Using a section landmark ensures that the figure and caption remain together as a single unit.
|
||||
|
||||
The html code for the xkcd comic earlier in the page (well, the Web version of this page) is a representative example. I took care of most boilerplate using shortcodes. Here's a simplified version of the final result:
|
||||
|
||||
```
|
||||
<article aria-label="comic, caption, and transcript">
|
||||
<section aria-label="comic, caption, and transcript">
|
||||
<h4>Infinite scrolling</h4>
|
||||
<figure>
|
||||
<img src="SRC"
|
||||
|
|
@ -546,7 +546,7 @@ The html code for the xkcd comic earlier in the page (well, the Web version of t
|
|||
</dl>
|
||||
</div>
|
||||
</details>
|
||||
</article>
|
||||
</section>
|
||||
```
|
||||
|
||||
## About custom colors
|
||||
|
|
@ -700,7 +700,7 @@ Color schemes should also look good to users who apply gamma adjustments. Most o
|
|||
|
||||
Some typographers insist that underlined on-screen text is obsolete and hyperlinks are no exception.
|
||||
|
||||
=> https://practicaltypography.com/underlining.html Underlining | Butterick’s Practical Typography⁸
|
||||
=> https://practicaltypography.com/underlining.html Underlining | Butterick’s Practical Typography⁹
|
||||
|
||||
I disagree. One reason is that underlines make it easy to separate multiple consecutive inline links:
|
||||
|
||||
|
|
@ -730,7 +730,7 @@ Lossless or lossy JPEG compression. Note that JPEG is an inherently lossy format
|
|||
The reference WebP encoder; has dedicated lossless and lossy modes. Lossy WebP compression isn't always better than JPEG, but lossless WebP consistently beats PNG.
|
||||
|
||||
=> https://github.com/AOMediaCodec/libavif avifenc (lossless or lossy), included in libavif
|
||||
The reference AVIF encoder, included in libavif.⁹ AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
|
||||
The reference AVIF encoder, included in libavif.¹⁰ AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
|
||||
|
||||
I put together a quick script to losslessly optimize images using these programs in my dotfile repo:
|
||||
|
||||
|
|
@ -970,7 +970,7 @@ Soft hyphens are great for splitting up text, but some text should stay together
|
|||
10 cm
|
||||
```
|
||||
|
||||
Practical Typography⁸ describes where to use the non-breaking space in more detail:
|
||||
Practical Typography⁹ describes where to use the non-breaking space in more detail:
|
||||
|
||||
=> https://practicaltypography.com/nonbreaking-spaces.html nonbreaking spaces, Butterick's Practical Typography
|
||||
|
||||
|
|
@ -1278,7 +1278,7 @@ Screen readers on touch screen devices are also quite different from their deskt
|
|||
|
||||
Screen reader implementations often skip punctuation marks like the exclamation point ("!"). Ensure that meaning doesn't rely too heavily on such punctuation.
|
||||
|
||||
Screen readers have varying levels of verbosity. The default verbosity level doesn't always convey inline emphasis, such as <em>, <code>, or <strong>. Ensure that your meaning carries through without these semantics.¹²
|
||||
Screen readers have varying levels of verbosity. The default verbosity level doesn't always convey inline emphasis, such as <em>, <code>, or <strong>. Ensure that your meaning carries through without these semantics.¹³
|
||||
|
||||
Default verbosity does, however, convey symbols and emoji. Use symbols and emoji judiciously, since they can get pretty noisy if you aren't careful. Use "aria-labelledby" on symbols when appropriate; I used labels to mark my footnote backlinks, which would otherwise be read as <samp>right arrow curving left</samp>. If you have to use a symbol or emoji, first test how assistive technologies announce it; the emoji name may not communicate what you expect.
|
||||
|
||||
|
|
@ -1344,7 +1344,7 @@ Your page should easily pass the harshest of tests without any extra effort if i
|
|||
These tests begin reasonably, but gradually grow absurd. Once again, use your judgement.
|
||||
|
||||
1. Test in all three major browser engines: Blink, Gecko, and WebKit.
|
||||
2. Evaluate the heaviness and complexity of your scripts (if any) by testing with your browser's JIT compilation disabled.¹⁰
|
||||
2. Evaluate the heaviness and complexity of your scripts (if any) by testing with your browser's JIT compilation disabled.¹¹
|
||||
3. Test using the Tor Browser's safest security level enabled (disables JS and other features).
|
||||
4. Load just the HTML. No CSS, no images, etc. Try loading without inline CSS as well for good measure.
|
||||
5. Print some pages in black-and-white, preferably with a simple laser printer.
|
||||
|
|
@ -1357,7 +1357,7 @@ These tests begin reasonably, but gradually grow absurd. Once again, use your ju
|
|||
12. Test with unorthodox graphical browser engines, like NetSurf, Dillo, Servo, or the Serenity OS browser.
|
||||
13. Test how your page renders in ancient browsers, like Netscape Navigator or Tkhtml. Use a TLS terminator or serve over HTTP from localhost.
|
||||
14. Try printing out your page in black-and-white from an unorthodox graphical browser.
|
||||
15. Download your webpage and test how multiple word processors render and generate PDFs from it.¹¹
|
||||
15. Download your webpage and test how multiple word processors render and generate PDFs from it.¹²
|
||||
16. Combine conversion tools. Combine an HTML-to-EPUB converter and an EPUB-to-PDF converter, or stack multiple article-extraction utilities. Be creative and enjoy breaking your site. When something breaks, examine the breakage and see if it's caused by an issue in your markup, or a CSS feature with an equivalent alternative.
|
||||
17. Build a time machine. Travel decades--or perhaps centuries--into the future. Keep going forward until the WWW is breathing its last breath. Test your site on future browsers. Figuring out how to transfer your files onto their computers might take some time, but you have a time machine so that shouldn't be too hard. When you finish, go back in time to meet Benjamin Franklin:
|
||||
|
||||
|
|
@ -1511,14 +1511,18 @@ A special thanks goes out to GothAlice for the questions she answered in #webdev
|
|||
=> https://datatracker.ietf.org/doc/html/rfc7541#appendix-A RFC 7541: HPACK static table definition
|
||||
=> https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#appendix-A QPACK: Header Compression for HTTP/3
|
||||
|
||||
⁸ Practical Typography only renders invisible text without JavaScript. You can use a textual browser, screen reader, copy-paste the page contents elsewhere, use a reader-mode implementation, or "view source" to read it without enabling scripts. All of these options will ironically override the carefully-crafted typography of this website about typography.
|
||||
⁸ Once it gains basic support across all browsers and screen readers, I might recommend using aria-details instead of aria-describedby for more complex descriptions. Right now, aria-details is only supported by JAWS. WAI-ARIA 1.2 describes aria-details with an example similar to the one I gave for image transcripts.
|
||||
=> https://a11ysupport.io/tech/aria/aria-details_attribute Current support for aria-details
|
||||
=> https://www.w3.org/TR/wai-aria-1.2/#aria-details aria-details specification
|
||||
|
||||
⁹ Practical Typography only renders invisible text without JavaScript. You can use a textual browser, screen reader, copy-paste the page contents elsewhere, use a reader-mode implementation, or "view source" to read it without enabling scripts. All of these options will ironically override the carefully-crafted typography of this website about typography.
|
||||
I find Practical Typography quite useful for printed works, and incorporated a more moderate version of its advice on soft-hyphens into this page. With a few such exceptions, I generally find it to be poor advice for Web content.
|
||||
|
||||
⁹ libavif links against libaom, librav1e, and/or libsvtav1 to perform AVIF encoding and decoding. libaom is best for this use-case, particularly since libaom can link against libjxl to use its Butteraugli distortion metric. This lets libaom optimize the perceptual quality of lossy encodes much more accurately.
|
||||
¹⁰ libavif links against libaom, librav1e, and/or libsvtav1 to perform AVIF encoding and decoding. libaom is best for this use-case, particularly since libaom can link against libjxl to use its Butteraugli distortion metric. This lets libaom optimize the perceptual quality of lossy encodes much more accurately.
|
||||
|
||||
¹⁰ Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnerabilities. In Firefox, toggle javascript.options.ion, javascript.options.baselinejit, javascript.options.native_regexp, javascript.options.asmjs, and javascript.options.wasm in about:config; in Chromium, run chromium with `--js-flags='--jitless'`; in the Tor Browser, set the security level to "Safer".
|
||||
¹¹ Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnerabilities. In Firefox, toggle javascript.options.ion, javascript.options.baselinejit, javascript.options.native_regexp, javascript.options.asmjs, and javascript.options.wasm in about:config; in Chromium, run chromium with `--js-flags='--jitless'`; in the Tor Browser, set the security level to "Safer".
|
||||
|
||||
¹¹ LibreOffice can also render HTML but has extremely limited support for CSS. OnlyOffice seems to work best, but doesn't load images. If your page is CSS-optional, it should look fine in both.
|
||||
¹² LibreOffice can also render HTML but has extremely limited support for CSS. OnlyOffice seems to work best, but doesn't load images. If your page is CSS-optional, it should look fine in both.
|
||||
Fun fact: Microsoft Outlook renders HTML email with Microsoft Word's proprietary HTML engine.
|
||||
|
||||
¹² Screen readers aren't alone here. Several programs strip inline formatting: certain feed readers, search result snippets, and textual browsers invoked with the `-dump` flag are some examples I use every day.
|
||||
¹³ Screen readers aren't alone here. Several programs strip inline formatting: certain feed readers, search result snippets, and textual browsers invoked with the `-dump` flag are some examples I use every day.
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ cache-control: max-age=31557600, immutable
|
|||
|
||||
### Inline content
|
||||
|
||||
In addition to HTML, CSS is also a blocking resource. You could pre-load your CSS using a `link` header. Alternatively: if your gzipped CSS is under **one kilobyte,** consider inlining it in the `<head>` using a `<style>` element. Simply inlining stylesheets can pose a security threat, but the `style-src` <abbr title="Content Security Policy">CSP</abbr> directive can mitigate this if you include a hash of your inline stylesheet sans trailing whitespace.
|
||||
In addition to HTML, CSS is also a blocking resource. You could pre-load your CSS using a `link` header. Alternatively: if your compressed CSS is under a kilobyte consider inlining it in the `<head>` using a `<style>` element. Simply inlining stylesheets can pose a security threat, but the `style-src` <abbr title="Content Security Policy">CSP</abbr> directive can mitigate this if you include a hash of your inline stylesheet sans trailing whitespace.
|
||||
|
||||
Consider inlining images under 250 bytes with a `data:` URI; that's the size at which cache-validation requests might outweigh the size of the image. My 32-pixel PNG site icon is under 150 bytes and inlines quite nicely. On this site's hidden service, it's often the only image on a page (the hidden service replaces SVGs with PNGs; see the section on [the Tor Browser](#the-tor-browser)). Inlining this image and the stylesheet allows my hidden service's homepage to load in a single request, which is a welcome improvement given the round-trip latency that plagues onion routing implemen­tations.
|
||||
|
||||
|
|
@ -552,16 +552,16 @@ A <dfn>`longdesc`</dfn> attribute used to be another way to reference an image t
|
|||
|
||||
The recommended way to link to a transcript is by hyperlinking the image (i.e., wrapping it with `<a>`) or semantically grouping the image with its transcript. Put a short summary in the alt-text, and mention the availability of a transcript in a visible caption.
|
||||
|
||||
A [StackOverflow thread about comic transcripts](https://stackoverflow.com/questions/65564539/what-is-the-semantically-correct-way-to-include-transcript-from-a-comic) outlines a good approach to semantically group images and transcripts, and my approach is similar. I group an image, alt-text, and caption in a `<figure>` element and follow it with a transcript in a `<details>` element. I use <code>aria-<wbr>des­cribedby</code> to semantically link the figure and the transcript.
|
||||
A [StackOverflow thread about comic transcripts](https://stackoverflow.com/questions/65564539/what-is-the-semantically-correct-way-to-include-transcript-from-a-comic) outlines a good approach to semantically grouping images and transcripts, and my approach is similar. I group an image, alt-text, and caption in a `<figure>` element and follow it with a transcript in a `<details>` element. I use <code>aria-<wbr>des­cribedby</code> to semantically link the figure and the transcript.[^11]
|
||||
|
||||
An image, alt-text, figure caption, and transcript combine to form a complex relationship that should be grouped together in a single landmark. I put all three inside an `<article>` with a heading, and give the group an `aria-label` that indicates the presence of the three sub-elements. Using an `article` landmark ensures that the figure and caption remain together as a single unit. The [html code](#xkcd-html) for the [xkcd comic earlier in the page](#infinite-scrolling) is a representative example.
|
||||
An image, alt-text, figure caption, and transcript combine to form a complex relationship that should be grouped together in a single landmark. I put all three inside a `<section>` with a heading, and give the group an `aria-label` that indicates the presence of the three sub-elements. Using a `section` landmark ensures that the figure and caption remain together as a single unit. The [html code](#xkcd-html) for the [xkcd comic earlier in the page](#infinite-scrolling) is a representative example.
|
||||
|
||||
{{<codefigure id="xkcd-html">}}
|
||||
|
||||
{{< codecaption lang="HTML" >}} here's a simplified version of the HTML used to embed a comic in this article. Of course, I take care of most of the boilerplate with shortcodes. {{< /codecaption >}}
|
||||
|
||||
```figure {var1="SRC" str1="figure" str2="img" str3="alt" str4="details" str5="article", str6="figcaption" str7="aria-label" str8="aria-describedby"}
|
||||
<article aria-label="comic, caption, and transcript">
|
||||
```figure {var1="SRC" str1="figure" str2="img" str3="alt" str4="details" str5="section", str6="figcaption" str7="aria-label" str8="aria-describedby"}
|
||||
<section aria-label="comic, caption, and transcript">
|
||||
<h4>Infinite scrolling</h4>
|
||||
<figure>
|
||||
<img src="SRC"
|
||||
|
|
@ -590,7 +590,7 @@ An image, alt-text, figure caption, and transcript combine to form a complex rel
|
|||
</dl>
|
||||
</div>
|
||||
</details>
|
||||
</article>
|
||||
</section>
|
||||
```
|
||||
|
||||
{{</codefigure>}}
|
||||
|
|
@ -636,7 +636,7 @@ Even if you set custom colors, ensure that the page is compatible with color ove
|
|||
|
||||
This page's [canonical location](https://seirdy.one/2020/11/23/website-best-practices.html) is an example application of Technique C25 (and the related [Technique G148](https://www.w3.org/WAI/WCAG22/Techniques/general/G148)). It only uses non-default colors when a user agent requests a dark color scheme (using the `prefers-color-scheme` CSS media query; see the next subsection) and for lightening borders. Any image with a solid background may match the page background; to ensure that their dimensions are clear, I surrounded them with borders. I also set a custom color for the borders and ensure that the image backgrounds don't match the border colors. I included borders to break up some sections, since heading-based delineation is either unavailable or insufficient for them. When overriding color schemes, the page layout remains clear.
|
||||
|
||||
Color overrides go well beyond simple foreground and background color changes. Windows High Contrast Mode (<abbr title="Windows High Contrast Mode">WHCM</abbr>) is perhaps the best example. [WHCM makes advanced modifications to color palettes](#win-hcm): it colors elements with a user-specified palette, all according to semantic markup while ignoring ARIA overrides.[^11]
|
||||
Color overrides go well beyond simple foreground and background color changes. Windows High Contrast Mode (<abbr title="Windows High Contrast Mode">WHCM</abbr>) is perhaps the best example. [WHCM makes advanced modifications to color palettes](#win-hcm): it colors elements with a user-specified palette, all according to semantic markup while ignoring ARIA overrides.[^12]
|
||||
|
||||
<abbr title="Windows High Contrast Mode">WHCM</abbr> leads the standardization process for the `forced-colors` CSS media feature, but it isn't the only implementation of the underlying idea. If you navigate to <samp>about:preferences</samp> in Firefox and activate the <samp translate="yes">Colors</samp> button in the "Language and Appearance" section, you'll be presented with the option to override website palettes with [your own default colors](#default-colors).
|
||||
|
||||
|
|
@ -714,14 +714,14 @@ Accounting for halation, overstimulation, and high-contrast needs is hard to do
|
|||
|
||||
Color palettes need to be effective for different types of vision deficiencies (e.g. color blindnesses) and screens. Color blindness is a far more nuanced topic than "the inability to see some colors". <span itemprop="citation" itemscope itemtype="https://schema.org/BlogPosting">{{<indieweb-person itemprop="author" first-name="Rob" last-name="Pike" url="http://herpolhode.com/rob/">}} describes his experience in {{<cited-work name="Color blindness" extraName="headline" url="https://commandcenter.blogspot.com/2020/09/color-blindness-is-inaccurate-term.html">}}</span>. Color blindness manifests in complex ways. Testing in grayscale is a great start, but it doesn't account for all kinds of color vision deficiencies.
|
||||
|
||||
Different screens and display-calibrations render color differently; what may look like a light-gray on a cheap monitor could look nearly black on a high-end OLED screen. Try to test on both high- and low-end displays, especially when designing a dark color scheme.[^12]
|
||||
Different screens and display-calibrations render color differently; what may look like a light-gray on a cheap monitor could look nearly black on a high-end OLED screen. Try to test on both high- and low-end displays, especially when designing a dark color scheme.[^13]
|
||||
|
||||
Color schemes should also look good to users who apply gamma adjustments. Most operating systems and desktop environments bundle a feature to reduce the screen color temperature at night, while some individuals may select a higher one in the morning.
|
||||
|
||||
In defense of link under­lines {#in-defense-of-link-underlines}
|
||||
----------------------------------
|
||||
|
||||
Some typographers insist that [underlined on-screen text is obsolete](https://practicaltypography.com/underlining.html),[^13] and that hyperlinks are no exception. I disagree.
|
||||
Some typographers insist that [underlined on-screen text is obsolete](https://practicaltypography.com/underlining.html),[^14] and that hyperlinks are no exception. I disagree.
|
||||
|
||||
Readers already expect underlined text to signify a hyperlink. Don't break fundamental affordances for aesthetics. Underlines are also necessary to distinguish the beginnings and ends of multiple consecutive links, especially among color-blind users.
|
||||
|
||||
|
|
@ -766,7 +766,7 @@ Some image optimization tools I use:
|
|||
: The reference WebP encoder; has dedicated lossless and lossy modes. Lossy WebP compression isn't always better than JPEG, but lossless WebP consistently beats PNG.
|
||||
|
||||
`avifenc`
|
||||
: The reference AVIF encoder, included in [libavif](https://github.com/AOMediaCodec/libavif).[^14] AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
|
||||
: The reference AVIF encoder, included in [libavif](https://github.com/AOMediaCodec/libavif).[^15] AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers.
|
||||
|
||||
I put together [a quick script](https://git.sr.ht/~seirdy/dotfiles/tree/3b722a843f3945a1bdf98672e09786f0213ec6f6/Executables/shell-scripts/bin/optimize-image) to losslessly optimize images using these programs. For lossy compression, I typically use [GNU Parallel](https://www.gnu.org/software/parallel/) to mass-generate images using different options before selecting the smallest image at the minimum acceptable quality. Users who'd rather avoid the command line while performing lossy compression can instead check out [Squoosh](https://squoosh.app/), a JavaScript app that bundles Web­Assembly-compiled encoders; I've heard good things about it.
|
||||
|
||||
|
|
@ -887,7 +887,7 @@ Users of <abbr title="assistive technology">AT</abbr>s such as screen readers pr
|
|||
|
||||
Try using a tool to view a list of all your link names. Just about every screen reader and some browser extensions should offer this functionality. Minimize links with ambiguous names, and ensure that identical link names have identical destinations.
|
||||
|
||||
Think twice before placing important content immediately after skippable content such as nested landmarks, long code snippets, figures, and large lists. AT users who wish to skip content may jump directly to the next heading, glossing over anything between the skippable content and subsequent heading; this is especially common on mobile devices.[^15] When it makes sense to do so, place skippable content in its own sections and/or at the end of its parent section.
|
||||
Think twice before placing important content immediately after skippable content such as nested landmarks, long code snippets, figures, and large lists. AT users who wish to skip content may jump directly to the next heading, glossing over anything between the skippable content and subsequent heading; this is especially common on mobile devices.[^16] When it makes sense to do so, place skippable content in its own sections and/or at the end of its parent section.
|
||||
|
||||
### Arbitrary viewports
|
||||
|
||||
|
|
@ -971,7 +971,7 @@ Where long inline `<code>` elements can trigger horizontal scrolling, consider a
|
|||
|
||||
### Keeping text together
|
||||
|
||||
Soft hyphens are great for splitting up text, but some text should stay together. The phrase "10 cm", for instance, would flow poorly if "10" and "cm" appeared on separate lines. Splitting text becomes especially painful on narrow viewports. A non-breaking space keeps the surrounding text from being re-flowed. Use the ` ` HTML entity instead of a space: `10 cm`. <span itemprop="mentions" itemscope itemtype="https://schema.org/Book">{{<cited-work name="Practical Typography" url="https://practicaltypography.com/">}}</span>[^13] describes [where to use the non-breaking space](https://briefs.video/videos/is-progressive-enhancement-dead-yet/) in more detail.
|
||||
Soft hyphens are great for splitting up text, but some text should stay together. The phrase "10 cm", for instance, would flow poorly if "10" and "cm" appeared on separate lines. Splitting text becomes especially painful on narrow viewports. A non-breaking space keeps the surrounding text from being re-flowed. Use the ` ` HTML entity instead of a space: `10 cm`. <span itemprop="mentions" itemscope itemtype="https://schema.org/Book">{{<cited-work name="Practical Typography" url="https://practicaltypography.com/">}}</span>[^14] describes [where to use the non-breaking space](https://briefs.video/videos/is-progressive-enhancement-dead-yet/) in more detail.
|
||||
|
||||
One exception to the rules from <cite>Practical Typography</cite>: don't use a non-breaking space if it would trigger two-dimensional scrolling on a narrow viewport. Between broken text and two-dimensional scrolling, broken text is the lesser evil. I personally set a cutoff at 2.5 cm (1 inch) at 125% zoom.
|
||||
|
||||
|
|
@ -1187,7 +1187,7 @@ On one hand, users who need enhanced focus visibility may override the default f
|
|||
|
||||
The WCAG guidelines recommend making focus indicators 2 px thick in [Success Criterion 2.4.12](https://w3c.github.io/wcag/guidelines/22/#focus-appearance-enhanced). While this success criterion is only AAA-level, it's easy enough to meet and beneficial enough to others that we should all meet it.
|
||||
|
||||
You can use `:focus` and `:focus-visible` to highlight selected and keyboard-focused elements, respectively. Take care to only alter styling, not behavior: only keyboard-focusable elements should receive outlines. Modern browser stylesheets use `:focus-visible` instead of `:focus`; old browsers only support `:focus` and re-style a subset of focusable elements. Your stylesheets should do the same, to match browser behavior.[^16]
|
||||
You can use `:focus` and `:focus-visible` to highlight selected and keyboard-focused elements, respectively. Take care to only alter styling, not behavior: only keyboard-focusable elements should receive outlines. Modern browser stylesheets use `:focus-visible` instead of `:focus`; old browsers only support `:focus` and re-style a subset of focusable elements. Your stylesheets should do the same, to match browser behavior.[^17]
|
||||
|
||||
{{<codefigure>}}
|
||||
|
||||
|
|
@ -1265,7 +1265,7 @@ Screen readers on touch screen devices are also quite different from their deskt
|
|||
|
||||
Screen reader implemen­tations often skip punctuation marks like the exclamation point ("!"). Ensure that meaning doesn't rely too heavily on such punctuation.
|
||||
|
||||
Screen readers have varying levels of verbosity. The default verbosity level doesn't always convey inline emphasis, such as `<em>`, `<code>`, or `<strong>`. Ensure that your meaning carries through without these semantics.[^17]
|
||||
Screen readers have varying levels of verbosity. The default verbosity level doesn't always convey inline emphasis, such as `<em>`, `<code>`, or `<strong>`. Ensure that your meaning carries through without these semantics.[^18]
|
||||
|
||||
Default verbosity does, however, convey symbols and emoji. Use symbols and emoji judiciously, since they can get pretty noisy if you aren't careful. Use `aria-labelledby` on symbols when appropriate; I used labels to mark my footnote backlinks, which would otherwise be read as <samp>right arrow curving left</samp>. If you have to use a symbol or emoji, first test how assistive technologies announce it; the emoji name may not communicate what you expect.
|
||||
|
||||
|
|
@ -1294,7 +1294,7 @@ No matter how simple a page is, I don't think simplicity eliminates the need for
|
|||
|
||||
Automated tests--especially accessibility tests--are a supplement to manual tests, not a replacement for them. Think of them as time-savers that bring up issues for further research, containing both false positives and false negatives.
|
||||
|
||||
These are the tools I use regularly. I've deliberately excluded tools that would be redundant.[^18]
|
||||
These are the tools I use regularly. I've deliberately excluded tools that would be redundant.[^19]
|
||||
|
||||
1. [Nu HTML checker](https://validator.nu/): The W3C's official HTML validator. Valid HTML ensures broader compatibility with a wider range of agents. Note that it uses Jigsaw under the hood for CSS validation, which hasn't implemented support for certain CSS features I've reco­mmended elsewhere on this page. Watch out for false positives.
|
||||
|
||||
|
|
@ -1302,7 +1302,7 @@ These are the tools I use regularly. I've deliberately excluded tools that would
|
|||
|
||||
3. [Light­house](https://developers.google.com/web/tools/lighthouse/): An auditing tool by Google that uses the DevTools protocol in any Chromium-based browser. Skip the "Access­ibility" category, since it just runs a subset of axe-core's audits. The most useful audit is the tap target size check in its "SEO" category. Note that your `sandbox` CSP directive will need to include `allow-scripts` for it to function.
|
||||
|
||||
4. [Webhint](https://webhint.io/): Similar to Light­house. Again, you can ignore the accessibility audits if you already use axe-core. I personally disagree with some of its hints: the "unneeded HTTP headers" hint ignores the fact that the CSP can have an effect on non-hypertext assets, the "HTTP cache" hint has an unreasonable bias against caching HTML, and the "Correct `Content-Type` header" recommends charset attributes a bit too agg­ressively[^19].
|
||||
4. [Webhint](https://webhint.io/): Similar to Light­house. Again, you can ignore the accessibility audits if you already use axe-core. I personally disagree with some of its hints: the "unneeded HTTP headers" hint ignores the fact that the CSP can have an effect on non-hypertext assets, the "HTTP cache" hint has an unreasonable bias against caching HTML, and the "Correct `Content-Type` header" recommends charset attributes a bit too agg­ressively[^20].
|
||||
|
||||
5. [IBM Equal Access Access­ibility Checker](https://www.ibm.com/able/toolkit/verify/automated/): Has a scope similar to axe-core. Its "Sensory Characteristics" audit seems unique.
|
||||
|
||||
|
|
@ -1326,7 +1326,7 @@ These tests begin reasonably, but gradually grow absurd. Once again, use your ju
|
|||
|
||||
1. Test in all three major browser engines: Blink, Gecko, and WebKit.
|
||||
|
||||
2. Evaluate the heaviness and complexity of your scripts (if any) by testing with your browser's <abbr title="just-in-time">JIT</abbr> compilation disabled.[^20]
|
||||
2. Evaluate the heaviness and complexity of your scripts (if any) by testing with your browser's <abbr title="just-in-time">JIT</abbr> compilation disabled.[^21]
|
||||
|
||||
3. Test using the Tor Browser's safest security level enabled (disables JS and other features).
|
||||
|
||||
|
|
@ -1352,7 +1352,7 @@ These tests begin reasonably, but gradually grow absurd. Once again, use your ju
|
|||
|
||||
14. Try printing out your page in black-and-white from an unorthodox graphical browser.
|
||||
|
||||
15. Download your webpage and test how multiple word processors render and generate PDFs from it.[^21]
|
||||
15. Download your webpage and test how multiple word processors render and generate PDFs from it.[^22]
|
||||
|
||||
16. Combine conversion tools. Combine an HTML-<wbr>to-<wbr>EPUB converter and an EPUB-<wbr>to-<wbr>PDF converter, or stack multiple article-extraction utilities. Be creative and enjoy breaking your site. When something breaks, examine the breakage and see if it's caused by an issue in your markup, or a CSS feature with an equivalent alternative.
|
||||
|
||||
|
|
@ -1519,29 +1519,31 @@ A special thanks goes out to GothAlice for the questions she answered in <samp>#
|
|||
|
||||
[^10]: [WebAIM](https://wave.webaim.org/api/docs?format=html) and the [University of Illinois](https://fae.disability.illinois.edu/rulesets/IMAGE_4_EN/) recommend 100 characters; [Tangaru](https://www.tanaguru.com/en/) recommends an even smaller limit of 80 characters.
|
||||
|
||||
[^11]: Since <abbr title="Windows High Contrast Mode">WHCM</abbr> sets colors indepen­dently of explicitly-defined ARIA roles, it's a good way to test adherence to [the First Rule of ARIA](#first-rule-of-aria).
|
||||
[^11]: Once it gains basic support across all browsers and screen readers, I might recommend using `aria-details` instead of <code>aria-<wbr>des­cribedby</code> for more complex descriptions. Right now, [`aria-details` is only supported by JAWS](https://a11ysupport.io/tech/aria/aria-details_attribute). <span itemprop="mentions" itemscope itemtype="https://schema.org/TechArticle">{{<cited-work name="WAI-ARIA 1.2" url="https://www.w3.org/TR/wai-aria-1.2/#aria-details">}}</span> describes `aria-details` with an example similar to the one I gave in [code snippet 5](#xkcd-html).
|
||||
|
||||
[^12]: When making an earlier version of this site's dark-mode color palette, I made the mistake of exclusively testing in cheap or poorly-calibrated displays with bright black points. I mistakenly thought that my `#0b0b0b` background was bright enough to [prevent halation](#halation). Only after testing on a better screen did I realize that it would look almost completely black; I subsequently lightened the background to `#111` to strike a good compromise.
|
||||
[^12]: Since <abbr title="Windows High Contrast Mode">WHCM</abbr> sets colors indepen­dently of explicitly-defined ARIA roles, it's a good way to test adherence to [the First Rule of ARIA](#first-rule-of-aria).
|
||||
|
||||
[^13]: <span itemprop="mentions" itemscope itemtype="https://schema.org/Book">{{<cited-work name="Practical Typography" url="https://practicaltypography.com/">}}</span> only renders invisible text without JavaScript. You can use a textual browser, screen reader, copy-paste the page contents elsewhere, use a reader-mode implemen­tation, or "view source" to read it without enabling scripts. All of these options will ironically override the carefully-crafted typography of this website about typography.
|
||||
[^13]: When making an earlier version of this site's dark-mode color palette, I made the mistake of exclusively testing in cheap or poorly-calibrated displays with bright black points. I mistakenly thought that my `#0b0b0b` background was bright enough to [prevent halation](#halation). Only after testing on a better screen did I realize that it would look almost completely black; I subsequently lightened the background to `#111` to strike a good compromise.
|
||||
|
||||
[^14]: <span itemprop="mentions" itemscope itemtype="https://schema.org/Book">{{<cited-work name="Practical Typography" url="https://practicaltypography.com/">}}</span> only renders invisible text without JavaScript. You can use a textual browser, screen reader, copy-paste the page contents elsewhere, use a reader-mode implemen­tation, or "view source" to read it without enabling scripts. All of these options will ironically override the carefully-crafted typography of this website about typography.
|
||||
|
||||
I find <cite>Practical Typography</cite> quite useful for printed works, and incorporated a more moderate version of its advice on soft-hyphens into this page. With a few such exceptions, I generally find it to be poor advice for Web content.
|
||||
|
||||
[^14]: libavif links against libaom, librav1e, and/or libsvtav1 to perform AVIF encoding and decoding. libaom is best for this use-case, particularly since libaom can link against libjxl to use its Butteraugli distortion metric. This lets libaom optimize the perceptual quality of lossy encodes much more accu­rately.
|
||||
[^15]: libavif links against libaom, librav1e, and/or libsvtav1 to perform AVIF encoding and decoding. libaom is best for this use-case, particularly since libaom can link against libjxl to use its Butteraugli distortion metric. This lets libaom optimize the perceptual quality of lossy encodes much more accu­rately.
|
||||
|
||||
[^15]: ATs typically let users navigate by headings, landmarks, paragraphs, and links. Most users prefer skipping article content with heading-based navigation. Keyboard users can bind different keys to different modes of navigation, but mobile users can only access one navigation mode at a time.
|
||||
[^16]: ATs typically let users navigate by headings, landmarks, paragraphs, and links. Most users prefer skipping article content with heading-based navigation. Keyboard users can bind different keys to different modes of navigation, but mobile users can only access one navigation mode at a time.
|
||||
|
||||
Mobile users wishing to temporarily switch modes have to stop, change their navigation mode, perform a navigation gesture, and switch back. Mobile users trying to skim an article don't always find this worth the effort and sometimes stick to heading-based navigation even when a different mode would be optimal.
|
||||
|
||||
[^16]: If you'd like to learn more, <span itemprop="mentions" itemscope itemtype="https://schema.org/BlogPosting">{{< cited-work name="A guide to designing accessible, WCAG-compliant focus indicators" url="https://www.sarasoueidan.com/blog/focus-indicators/" extraName="headline" >}} by {{< indieweb-person url="https://www.sarasoueidan.com/" first-name="Sara" last-name="Soueidan" url="https://www.sarasoueidan.com/" itemprop="author">}}</span> has far more details on making accessible focus indicators.
|
||||
[^17]: If you'd like to learn more, <span itemprop="mentions" itemscope itemtype="https://schema.org/BlogPosting">{{< cited-work name="A guide to designing accessible, WCAG-compliant focus indicators" url="https://www.sarasoueidan.com/blog/focus-indicators/" extraName="headline" >}} by {{< indieweb-person url="https://www.sarasoueidan.com/" first-name="Sara" last-name="Soueidan" url="https://www.sarasoueidan.com/" itemprop="author">}}</span> has far more details on making accessible focus indicators.
|
||||
|
||||
[^17]: Screen readers aren't alone here. Several programs strip inline formatting: certain feed readers, search result snippets, and textual browsers invoked with the `-dump` flag are some examples I use every day.
|
||||
[^18]: Screen readers aren't alone here. Several programs strip inline formatting: certain feed readers, search result snippets, and textual browsers invoked with the `-dump` flag are some examples I use every day.
|
||||
|
||||
[^18]: I excluded PageSpeed Insights and GTMetrix since those are mostly covered by Lighthouse. I excluded Security Headers, since its approach seems to be recommen­ding headers regardless of whether or not they are necessary. It penalizes forgoing the <code>Per­missions-<wbr>Policy</code> header even if the CSP blocks script loading and execution; see [Security Headers issue #103](https://github.com/securityheaders/securityheaders-bugs/issues/103). I personally find the <code>Per­missions-<wbr>Policy</code> header quite problematic, as I noted in August 2021 on [webappsec-permissions-policy issue #189](https://github.com/w3c/webappsec-permissions-policy/issues/189#issuecomment-904783021).
|
||||
[^19]: I excluded PageSpeed Insights and GTMetrix since those are mostly covered by Lighthouse. I excluded Security Headers, since its approach seems to be recommen­ding headers regardless of whether or not they are necessary. It penalizes forgoing the <code>Per­missions-<wbr>Policy</code> header even if the CSP blocks script loading and execution; see [Security Headers issue #103](https://github.com/securityheaders/securityheaders-bugs/issues/103). I personally find the <code>Per­missions-<wbr>Policy</code> header quite problematic, as I noted in August 2021 on [webappsec-permissions-policy issue #189](https://github.com/w3c/webappsec-permissions-policy/issues/189#issuecomment-904783021).
|
||||
|
||||
[^19]: My site caches HTML documents for ten minutes and caches the RSS feed for several hours. I disagree with webhint's recommen­dations against this: cache durations should be based on request rates and how often a resource is updated. I also disagree with some of its `content-type` recommen­dations: you don't need to declare UTF-8 charsets for SVG content-type headers if the SVG is ASCII-only and called from a UTF-8 HTML document. You gain nothing but header bloat by doing so.
|
||||
[^20]: My site caches HTML documents for ten minutes and caches the RSS feed for several hours. I disagree with webhint's recommen­dations against this: cache durations should be based on request rates and how often a resource is updated. I also disagree with some of its `content-type` recommen­dations: you don't need to declare UTF-8 charsets for SVG content-type headers if the SVG is ASCII-only and called from a UTF-8 HTML document. You gain nothing but header bloat by doing so.
|
||||
|
||||
[^20]: Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnera­bilities. In Firefox, navigate to <samp>about:<wbr>config</samp> and toggle some flags under <code>javascript<wbr>.options</code>.
|
||||
[^21]: Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnera­bilities. In Firefox, navigate to <samp>about:<wbr>config</samp> and toggle some flags under <code>javascript<wbr>.options</code>.
|
||||
|
||||
<figure itemprop="hasPart" itemscope itemtype="https://schema.org/SoftwareSourceCode">
|
||||
<figcaption>
|
||||
|
|
@ -1557,7 +1559,7 @@ A special thanks goes out to GothAlice for the questions she answered in <samp>#
|
|||
|
||||
In Chromium and derivatives, run the browser with `--js-flags='--jitless'`; in the Tor Browser, set the security level to "Safer".
|
||||
|
||||
[^21]: LibreOffice can also render HTML but has extremely limited support for CSS. OnlyOffice seems to work best, but doesn't load images. If your page is CSS-optional, it should look fine in both.
|
||||
[^22]: LibreOffice can also render HTML but has extremely limited support for CSS. OnlyOffice seems to work best, but doesn't load images. If your page is CSS-optional, it should look fine in both.
|
||||
|
||||
Fun fact: Microsoft Outlook renders HTML email with Microsoft Word's proprietary HTML engine.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,6 @@
|
|||
{{- $type = . -}}
|
||||
{{- end -}}
|
||||
|
||||
<article aria-label="{{ $type }}, caption, and transcript" itemprop="mentions" itemscope itemtype="https://schema.org/ImageObject" id="{{ .Get "id" }}">
|
||||
<section aria-label="{{ $type }}, caption, and transcript" itemprop="mentions" itemscope itemtype="https://schema.org/ImageObject" id="{{ .Get "id" }}">
|
||||
{{ .Inner | markdownify | safeHTML }}
|
||||
</article>
|
||||
</section>
|
||||
|
|
|
|||
Loading…
Reference in a new issue