mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-11-10 00:12:09 +00:00
More on color overrides, some hyphens.
This commit is contained in:
Rohan Kumar
parent
46a0e5127b
commit
75e3e019c7
2 changed files with 54 additions and 43 deletions
|
|
@ -337,7 +337,7 @@ Long pages with many DOM nodes may benefit from CSS containment, a more recently
|
|||
|
||||
CSS containment allows authors to isolate sub-trees of the DOM. Combined with a property like "content-visibility", it enables browsers to defer rendering of less essential below-the-fold content. Try to avoid the "hidden" parameter when "auto" is better:
|
||||
|
||||
> content-visibility: auto is a more complex value than hidden; rather than being similar to display: none, it adaptively hides/displays an element’s contents as they become relevant to the user. It also doesn’t hide its skipped contents from the user agent, so screen readers, find-in-page, and other tools can still interact with it.
|
||||
> "content-visibility: auto" is a more complex value than "content-visibility: hidden"; rather than being similar to display: none, it adaptively hides/displays an element’s contents as they become relevant to the user. It also doesn’t hide its skipped contents from the user agent, so screen readers, find-in-page, and other tools can still interact with it.
|
||||
=> https://drafts.csswg.org/css-contain/#using-cv-auto CSS Containment Module
|
||||
|
||||
Leveraging containment is a progressive enhancement, so there aren't any serious implications for older browsers. I use it for my site footers and endnotes.
|
||||
|
|
@ -554,6 +554,10 @@ I describe best practices for preparing pictures of text in the "Pictures of tex
|
|||
|
||||
## About custom colors
|
||||
|
||||
Always remember that any color palette you define in your stylesheets is merely a suggestion. Any colors you don't define could fall back to arbitrary defaults; all colors you define could be overridden by the user agent or operating system.
|
||||
|
||||
### Default colors
|
||||
|
||||
Some users' browsers set default page colors that aren't black-on-white. For instance, Linux users who enable GTK style overrides might default to having white text on a dark background. Websites that explicitly set foreground colors but leave the default background color (or vice-versa) end up being difficult to read. The same phenomenon occurs on pages with text foregrounds with image backgrounds.
|
||||
|
||||
=> gemini://seirdy.one/misc/website_colors.png Screenshot of a website with gray text on a darker gray background. Details follow.
|
||||
|
|
@ -587,7 +591,7 @@ The Web version of this page is an example application of Technique C25 and the
|
|||
|
||||
The Web version of this page 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 or disabling CSS altogether, the page layout remains clear.
|
||||
|
||||
Color overrides go well beyond simple foreground and background color changes. Windows’ High Contrast Mode, for instance, makes more advanced modifications:
|
||||
Color overrides go well beyond simple foreground and background color changes. Windows' High Contrast Mode, for instance, makes more advanced modifications to color palettes: it colors elements only based on their semantic roles, ignoring ARIA overrides of HTML semantics. Since WHCM sets colors independent of explicitly-defined ARIA roles, it's a good way to test adherence to the First Rule of ARIA (see the "Split elements and posessive hyperlinks" sub-section of the "Screenreader improvements" section). WHCM recently began the process of standardization through the "forced-colors" media feature.
|
||||
|
||||
> Win HCM is a collection of user defined color themes that overwrite your definitions in CSS.
|
||||
> It’s not about design but readability.
|
||||
|
|
@ -596,7 +600,9 @@ Color overrides go well beyond simple foreground and background color changes. W
|
|||
> You can use a special media query combined with special CSS color keywords to give elements the user defined colors.
|
||||
=> https://accessabilly.com/accessibility-issues-concerning-windows-high-contrast-mode/ Accessibility issues concerning Windows HCM
|
||||
|
||||
In fact, the CSS Working Group is working on a specification for re-coloring websites:
|
||||
WHCM leads the standardization process for forced colors, but it isn't the only implementation of the underlying idea. If you navigate to about:preferences in Firefox and activate the Colors button in the "Language and Appearance" section, you'll be presented with the option to override website colors with your own.
|
||||
|
||||
Not all approaches completely discard a designer's specified color palette. The CSS Working Group is working on a specification for re-coloring websites:
|
||||
|
||||
=> https://drafts.csswg.org/css-color-adjust-1/ CSS Color Adjustment Module Level 1
|
||||
|
||||
|
|
@ -1235,7 +1241,7 @@ Some screen readers split up sections by HTML elements. This means HTML elements
|
|||
|
||||
This is especially concerning on my website, where I tend to hyperlink peoples' names (a common practice on the IndieWeb): making names possessive with an "apostrophe + s" creates pronunciation issues. "Seirdy's Home" could be read as "Seirdy. Link. S. Home" if the word "Seirdy" is a hyperlink.
|
||||
|
||||
A workaround is to use the "text" ARIA role to remove the semantics of elements.
|
||||
A workaround is to use the "text" ARIA role to remove the semantics of elements. This workaround doesn't work in certain screen readers, including Orca, so don't count on it.
|
||||
|
||||
> To force a screen reader to interpret the heading as one object, I wrapped the text inside the heading in a span and added role=”text”.
|
||||
```
|
||||
|
|
@ -1251,7 +1257,7 @@ If you're unfamiliar with ARIA, always remember the first rule of ARIA:
|
|||
|
||||
=> https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better_bad_aria No ARIA is better than Bad ARIA
|
||||
|
||||
ARIA exposes a host of accessibility hazards when used improperly, so only use this approach when there's no good alternative. This workaround doesn't work in certain screen readers, including Orca, so don't count on it.
|
||||
ARIA exposes a host of accessibility hazards when used improperly, so only use this approach when there's no good alternative.
|
||||
|
||||
The best solution for possessive nouns is to include the "apostrophe + s" inside the hyperlink.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ I realize not everybody's going to ditch the Web and switch to Gemini or Gopher
|
|||
|
||||
My primary focus is [inclusive design](https://100daysofa11y.com/2019/12/03/accommodation-versus-inclusive-design/). Specifically, I focus on supporting _under­represented ways to read a page_. Not all users load a page in a common web-browser and navigate effortlessly with their eyes and hands. Authors often neglect people who read through accessibility tools, tiny viewports, machine translators, "reading mode" implemen­tations, the Tor network, printouts, hostile networks, and uncommon browsers, to name a few. I list more niches in [the conclusion](#conclusion). Compatibility with so many niches sounds far more daunting than it really is: if you only selectively override browser defaults and use plain-old, semantic HTML (<abbr title="plain-old, semantic HTML">POSH</abbr>), you've done half of the work already.
|
||||
|
||||
One of the core ideas behind the flavor of inclusive design I present is being _inclusive by default._ Web pages shouldn't use accessible overlays, reduced-data modes, or other personalizations if these features can be available all the time. Of course, some features conflict; you can't display a light and dark color scheme simultaneously. Personalization is a fallback strategy to resolve conflicting needs. Dispro­portionately under­represented needs deserve dispro­portionately greater attention, so they come before personal preferences instead of being relegated to a separate lane.
|
||||
One of the core ideas behind the flavor of inclusive design I present is being _inclusive by default._ Web pages shouldn't use accessible overlays, reduced-data modes, or other personal­izations if these features can be available all the time. Of course, some features conflict; you can't display a light and dark color scheme simultaneously. Personal­ization is a fallback strategy to resolve conflicting needs. Dispro­portionately under­represented needs deserve dispro­portionately greater attention, so they come before personal preferences instead of being relegated to a separate lane.
|
||||
|
||||
Another focus is minimalism. [Progressive enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement) is a simple, safe idea that tries to incorporate some responsibility into the design process without rocking the boat too much. I don't find it radical enough. In addition to progressive enhancement, I prefer limiting any enhancements to ones that have been demonstrated to solve specific accessibility, security, performance, or significant usability problems faced by people _besides me._
|
||||
|
||||
|
|
@ -181,7 +181,7 @@ Google's answer to this problem is "Core Web Vitals" containing metrics such as
|
|||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote itemprop="text">
|
||||
|
||||
SpeedIndex is based on the idea that what counts is how fast the visible part of the website renders. It doesn't matter what's happening elsewhere on the page. It doesn't matter if the network is saturated and your phone is hot to the touch. It doesn't matter if the battery is visibly draining. Everything is OK as long as the part of the site in the viewport appears to pop into view right away.
|
||||
Speed­Index is based on the idea that what counts is how fast the visible part of the website renders. It doesn't matter what's happening elsewhere on the page. It doesn't matter if the network is saturated and your phone is hot to the touch. It doesn't matter if the battery is visibly draining. Everything is OK as long as the part of the site in the viewport appears to pop into view right away.
|
||||
|
||||
Of course, it doesn’t matter how fast the site appears to load if the first thing the completed page does is serve an interstitial ad. Or, if like many mobile users, you start scrolling immediately and catch the 'unoptimized' part of the page with its pants down.
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ A supplementary metric to use alongside download size is **round trips.** Estima
|
|||
3. Finish downloading _two screenfuls of content_
|
||||
4. Finish downloading the full page.
|
||||
|
||||
### Congestion control
|
||||
### Con­gestion control {#congestion-control}
|
||||
|
||||
Understanding round-trips requires understanding your server's approach to congestion control.
|
||||
|
||||
|
|
@ -364,7 +364,7 @@ Long pages with many DOM nodes may benefit from CSS containment, a more recently
|
|||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote itemprop="text">
|
||||
|
||||
`content-visibility: auto` is a more complex value than `hidden`; rather than being similar to `display: none`, it adaptively hides/<wbr>displays an element's contents as they become <a href="https://drafts.csswg.org/css-contain/#relevant-to-the-user">relevant to the user</a>. It also doesn’t hide its <a href="https://drafts.csswg.org/css-contain/#skips-its-contents">skipped contents</a> from the user agent, so screen readers, in-page search, and other tools can still interact with it.
|
||||
`content-visibility: auto` is a more complex directive than `content-visibility: hidden`; rather than being similar to `display: none`, it adaptively hides/<wbr>displays an element's contents as they become <a href="https://drafts.csswg.org/css-contain/#relevant-to-the-user">relevant to the user</a>. It also doesn’t hide its <a href="https://drafts.csswg.org/css-contain/#skips-its-contents">skipped contents</a> from the user agent, so screen readers, in-page search, and other tools can still interact with it.
|
||||
|
||||
</blockquote>
|
||||
{{< quotecaption partOfType="TechArticle" >}}
|
||||
|
|
@ -403,7 +403,7 @@ Correct, consistent spelling is important to readers who use search. In-page sea
|
|||
|
||||
Moreover, some search implemen­tations (such as the one built into Firefox) support case-sensitive matching. Inconsistent capitalization of proper nouns, acronyms, and initialisms can make searching difficult.
|
||||
|
||||
### Problematic overrides
|
||||
### Problem­atic overrides {#problematic-overrides}
|
||||
|
||||
Search is so essential to some users' ability to navigate that some desktop users enable "type-ahead" search, to automatically begin a search upon typing multiple characters.[^7] If you ignored my advice to avoid JavaScript, at least think twice before using it to define custom keyboard shortcuts which interfere with this type of functionality. I singled out type-ahead search, but there are countless other examples of uncommon keyboard behavior that JavaScript overrides interfere with.
|
||||
|
||||
|
|
@ -426,7 +426,7 @@ A personal example: I set my preferred browser font to `sans-serif`, and map it
|
|||
|
||||
The "users don't know better and need us to make decisions for them" mindset isn't without merits; however, in my opinion, it's overused. Using system fonts doesn't make your website harder to use, but it does make it smaller and stick out less to the subset of users who care enough about fonts to change them. This argument isn't about making software easier for non-technical users; it's about branding by asserting a personal preference.
|
||||
|
||||
### Can't users globally override stylesheets instead?
|
||||
### Style­sheet overrides aren't an excuse {#stylesheet-overrides-arent-an-excuse}
|
||||
|
||||
It's not a good idea to require users to automatically override website stylesheets to see their preferred fonts. Doing so would break websites that use fonts such as Font Awesome to display vector icons. We shouldn't have these users constantly battle with websites the same way that many ad- and script-blocking users (myself included) already do when there's a better option.
|
||||
|
||||
|
|
@ -469,7 +469,7 @@ Expect some readers to have images disabled or unloaded. Examples include:
|
|||
Accordingly, follow good practices for alt-text:
|
||||
|
||||
* Concisely summarize the image content the best you can, without repeating the surrounding content.
|
||||
* Images should usually have alt-text under 100 characters.[^10] Save longer descriptions for a caption or `aria-describedby`. Exceptions exist.
|
||||
* Images should usually have alt-text under 100 char­acters.[^10] Save longer descriptions for a caption or `aria-describedby`. Exceptions exist.
|
||||
* Don't include significant information that isn't present in the image; I'll cover how to handle supple­mentary information in the next subsections.
|
||||
|
||||
The <abbr title="Web Accessibility Initiative">WAI</abbr> provides some guidelines in <cite>[An `alt` Decision Tree](https://www.w3.org/WAI/tutorials/images/decision-tree/)</cite>. It's a little lacking in nuance, but makes for a good starting point. Remember that guidelines and "good practices" always have exceptions.
|
||||
|
|
@ -566,21 +566,19 @@ An image, alt-text, figure caption, and transcript combine to form a complex rel
|
|||
<img
|
||||
src="SRC"
|
||||
aria-describedby="transcript-xkcd-1309"
|
||||
alt="Comic: infinite-scrolling books require careful
|
||||
page-turns to avoid losing the page.">
|
||||
alt="Comic: infinite-scrolling books require
|
||||
careful page-turns to avoid losing the page.">
|
||||
<figcaption>
|
||||
Infinite-scroll means that accidental navigation
|
||||
to a link results in losing your place.
|
||||
See <a href=#transcript-xkcd-1309>transcript</a>.
|
||||
</figcaption>
|
||||
</figure>
|
||||
<details>
|
||||
<summary>Toggle transcript</summary>
|
||||
<div id="transcript-xkcd-1309">
|
||||
<p>
|
||||
Megan stands at a desk, reading a book, touching
|
||||
it very gingerly. Cueball is standing behind her.
|
||||
</p>
|
||||
<p>Megan stands at a desk, reading a book,
|
||||
touching it very gingerly. Cueball is
|
||||
standing behind her.</p>
|
||||
<dl>
|
||||
<dt>Cueball</dt>
|
||||
<dd>Why are you turning the pages like that?</dd>
|
||||
|
|
@ -605,6 +603,10 @@ I describe best practices for preparing pictures of text in [the "Pictures of te
|
|||
About custom colors
|
||||
-------------------
|
||||
|
||||
Always remember that any color palette you define in your stylesheets is merely a suggestion. Any colors you don't define could fall back to arbitrary defaults; all colors you define could be overridden by the user agent or operating system.
|
||||
|
||||
### Default colors
|
||||
|
||||
Some users' browsers set default page colors that aren't black-on-white. For instance, Linux users who enable GTK style overrides might default to having white text on a dark background. Websites that explicitly set foreground colors but leave the default background color (or vice-versa) end up being difficult to read. The same phenomenon occurs on pages with text foregrounds with image backgrounds.
|
||||
|
||||
<figure>
|
||||
|
|
@ -626,7 +628,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, for instance, makes more advanced modifications to color palettes.
|
||||
Color overrides go well beyond simple foreground and background color changes. Windows High Contrast Mode (<abbr title="Windows High Contrast Mode">WHCM</abbr>), for instance, makes more advanced modifications to color palettes: it colors elements only based on their semantic roles, ignoring ARIA overrides of HTML semantics.[^11] It recently began the process of standardization through the `forced-colors` media feature.
|
||||
|
||||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote itemprop="text">
|
||||
|
|
@ -635,7 +637,7 @@ Color overrides go well beyond simple foreground and background color changes. W
|
|||
<li>It’s not about design but <strong>readability</strong>.</li>
|
||||
<li>Some stuff will disappear in Win HCM, some won’t. Best advice is to use <strong>semantic <abbr title="Hypertext Markup Language">HTML</abbr></strong> to keep things visible.</li>
|
||||
<li>You can use transparent <code>outline</code> to keep things visble like focus indicators and surface boundaries or use <code>currentColor</code> to maintain SVG <code>fill</code> colors in Win HCM.</li>
|
||||
<li>You can use a special <strong>media query</strong> combined with special <strong><abbr title="Cascading Style Sheets">CSS</abbr> color keywords</strong> to give elements the user defined colors.</li>
|
||||
<li>You can use a special <strong>media query</strong> combined with special <strong><abbr title="Cascading Style Sheets">CSS</abbr> color key­words</strong> to give elements the user defined colors.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
{{< quotecaption partOfType="WebSite" >}}
|
||||
|
|
@ -644,7 +646,9 @@ Color overrides go well beyond simple foreground and background color changes. W
|
|||
{{< /quotecaption >}}
|
||||
</figure>
|
||||
|
||||
In fact, the CSS Working Group is working on a specification for re-coloring websites in <span itemscope itemtype="https://schema.org/TechArticle">{{<cited-work name="CSS Color Adjustment Module Level 1" extraName="headline" url="https://drafts.csswg.org/css-color-adjust-1/">}}</span>. The Chromium team's in-progress [auto dark mode](https://chromestatus.com/feature/5672533924773888) will use this specification to darken websites globally. Websites can opt out with the `color-scheme` property, but they really shouldn't have to: stylesheets should be robust enough to handle re-coloring.
|
||||
<abbr title="Windows High Contrast Mode">WHCM</abbr> leads the standardization process for forced colors, 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).
|
||||
|
||||
Not all approaches completely discard a designer's specified color palette. The CSS Working Group is working on a specification for stylesheet processing in <span itemscope itemtype="https://schema.org/TechArticle">{{<cited-work name="CSS Color Adjustment Module Level 1" extraName="headline" url="https://drafts.csswg.org/css-color-adjust-1/">}}</span>. The Chromium team's in-progress [auto dark mode](https://chromestatus.com/feature/5672533924773888) will use this specification to darken websites globally. Websites can opt out with the `color-scheme` property, but they really shouldn't have to: stylesheets should be robust enough to handle re-coloring.
|
||||
|
||||
### Dark themes
|
||||
|
||||
|
|
@ -723,7 +727,7 @@ Underlines also make it easy for color-blind readers to distinguish both the beg
|
|||
|
||||
Readers already expect underlined text to signify a hyperlink. Don't break fundamental affordances for aesthetics.
|
||||
|
||||
Image optimiza­tion {#image-optimization}
|
||||
Image op­timiza­tion {#image-optimization}
|
||||
-----------------------
|
||||
|
||||
Some image optimization tools I use:
|
||||
|
|
@ -742,9 +746,9 @@ 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)[^11]. 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)[^13]. 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 WebAssembly-compiled encoders; I've heard good things about it.
|
||||
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.
|
||||
|
||||
You also might want to use the HTML `<picture>` element, using JPEG/PNG as a fallback for more efficient formats such as WebP or AVIF, but only if the size savings are more significant than a couple hundred bytes. More info in the [MDN `<picture>` docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture)
|
||||
|
||||
|
|
@ -834,7 +838,7 @@ Layout
|
|||
|
||||
Page layout should be simple, predictable, consistent, familiar, and static. Avoid anything too unusual, since novelty could introduce a learning curve.
|
||||
|
||||
### Accessible skimming
|
||||
### Access­ible skimming {#accessible-skimming}
|
||||
|
||||
Keep the source order, DOM order, and visual order identical to ensure consistent behavior when navigating with the mouse, keyboard, assistive-technology, et al. Doing so should also result in a logical <kbd>Tab</kbd> order.
|
||||
|
||||
|
|
@ -1047,7 +1051,7 @@ Line spacing (leading) is at least space-and-a-half within paragraphs, and parag
|
|||
|
||||
The <abbr title="Web Accessibility Initiative">WAI</abbr>'s Cognitive and Learning Disabilities Accessibility Task Force [recommends changing this Success Criterion's level](https://w3c.github.io/coga/extension/#changedlevels), finding it too important to be relegated to AAA status.
|
||||
|
||||
Non-<wbr>browsers: reading mode {#non-browsers-reading-mode}
|
||||
Non-<wbr>brow­sers: reading mode {#non-browsers-reading-mode}
|
||||
-------------------------------
|
||||
|
||||
Fully standards-compliant browsers aren't the only programs people use. They also use "reading mode" tools and services.
|
||||
|
|
@ -1091,7 +1095,7 @@ For example: machine translation will leave `<code>` and `<samp>` blocks as-is.
|
|||
|
||||
[Google's style guide](https://developers.google.com/style/placeholders) recommends annotating format placeholders in code blocks with the `<var>` element; consider doing so and adding a `translate="yes"` attribute to placeholder values, at your discretion. For an example, check this article's code sample [describing my PNG optimization pipeline](#png-pipeline).
|
||||
|
||||
### Changing text direction
|
||||
### Chan­ging text direction {#changing-text-direction}
|
||||
|
||||
Consider the implications of translating between left-to-right (LTR) and right-to-left (RTL) languages. Do a search through your stylesheets for keywords like "left" and "right" to ensure that styles don't depend too heavily on text direction. Once you've cleared the low-hanging fruit, try translating the page to a language like Arabic.
|
||||
|
||||
|
|
@ -1109,7 +1113,7 @@ My previous advice regarding line spacing and maximum line length fell in the fi
|
|||
|
||||
This section contains miscellaneous advice regarding the latter category of stylesheet overrides.
|
||||
|
||||
### Monospace handling
|
||||
### Mono­space handling {#monospace-handling}
|
||||
|
||||
By default, most browsers render monospace text at a reduced size. If you want your monospace text to be readable, set its font family to `monospace monospace` (sic).
|
||||
|
||||
|
|
@ -1205,7 +1209,7 @@ Some screen readers split up sections by HTML elements. This means HTML elements
|
|||
|
||||
This is especially concerning on my website, where I tend to hyperlink peoples' names (a common practice on the IndieWeb): making names possessive with an "apostrophe + s" creates pronunciation issues. "Seirdy's Home" could be read as "Seirdy. Link. S. Home" if the word "Seirdy" is a hyperlink.
|
||||
|
||||
A workaround is to use the "text" ARIA role to remove the semantics of elements.
|
||||
A workaround is to use the "text" ARIA role to remove the semantics of elements. This workaround doesn't work in certain screen readers, including Orca, so don't count on it.
|
||||
|
||||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote itemprop="text">
|
||||
|
|
@ -1227,7 +1231,7 @@ To force a screen reader to interpret the heading as one object, I wrapped the t
|
|||
{{< /quotecaption >}}
|
||||
</figure>
|
||||
|
||||
If you're unfamiliar with ARIA, always remember the first rule of ARIA: [No ARIA is better than Bad ARIA](https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better_bad_aria). ARIA exposes a host of accessibility hazards when used improperly, so only use this approach when there's no good alternative. This workaround doesn't work in certain screen readers, including Orca, so don't count on it.
|
||||
If you're unfamiliar with ARIA, always remember the <dfn id="first-rule-of-aria">First Rule of ARIA</dfn>: [No ARIA is better than Bad ARIA](https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better_bad_aria). ARIA exposes a host of accessibility hazards when used improperly, so only use this approach when there's no good alternative.
|
||||
|
||||
The best solution for possessive nouns is to include the "apostrophe + s" inside the hyperlink.
|
||||
|
||||
|
|
@ -1239,8 +1243,8 @@ Beware of `display` and `visibility` CSS properties; they can interfere with con
|
|||
|
||||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote itemprop="text">
|
||||
<p>Sometimes doing this can have an unintended effect of nuking the semantics of the elements, as conveyed to screen reading software, in the <a href="https://www.tpgi.com/the-browser-accessibility-tree/">browser accessibility tree</a>. Screen readers and other assistive tech, in general, do not have direct access to the HTML DOM, they are provided access to a subset of information in the HTML DOM via <a href="https://www.w3.org/TR/wai-aria-1.1/#dfn-accessibility-api">Accessibility APIs</a>. Sometimes what an element represents in the HTML DOM is not how it is represented in the accessibility tree.</p>
|
||||
<p>If what is represented in the accessibility tree does not represent the developer’s intended UI, it’s either (wittingly/unwittingly) the <strong>fault of the developer or the browser</strong>. But what we can be sure of, in these cases, is that it is <strong>not the fault of the screen reader</strong>.</p>
|
||||
<p>Sometimes doing this can have an unintended effect of nuking the semantics of the elements, as conveyed to screen reading software, in the <a href="https://www.tpgi.com/the-browser-accessibility-tree/">browser accessibility tree</a>. Screen readers and other assistive tech, in general, do not have direct access to the HTML DOM, they are provided access to a subset of information in the HTML DOM via <a href="https://www.w3.org/TR/wai-aria-1.1/#dfn-accessibility-api">Accessi­bility APIs</a>. Sometimes what an element represents in the HTML DOM is not how it is represented in the accessibility tree.</p>
|
||||
<p>If what is represented in the accessibility tree does not represent the devel­oper’s intended UI, it’s either (wittingly / unwittingly) the <strong>fault of the developer or the browser</strong>. But what we can be sure of, in these cases, is that it is <strong>not the fault of the screen reader</strong>.</p>
|
||||
</blockquote>
|
||||
{{< quotecaption partOfType="BlogPosting" >}}
|
||||
{{<indieweb-person first-name="Steve" last-name="Faulkner" url="https://twitter.com/stevefaulkner" itemprop="author" org="TPGi" org-url="https://www.tpgi.com/" >}},
|
||||
|
|
@ -1248,12 +1252,11 @@ Beware of `display` and `visibility` CSS properties; they can interfere with con
|
|||
{{< /quotecaption >}}
|
||||
</figure>
|
||||
|
||||
|
||||
Screen readers on touch screen devices are also quite different from their desktop counterparts, and typically feature fewer capabilities. Be sure to test on both desktop and mobile.
|
||||
|
||||
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.[^13]
|
||||
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.[^14]
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -1272,7 +1275,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. 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.[^14]
|
||||
1. 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.[^15]
|
||||
2. Test using the Tor Browser's safest security level enabled (disables JS and other features).
|
||||
3. Load just the HTML. No CSS, no images, etc. Try loading without inline CSS as well for good measure.
|
||||
4. Print out the site in black-and-white, preferably with a simple laser printer.
|
||||
|
|
@ -1284,7 +1287,7 @@ These tests begin reasonably, but gradually grow absurd. Once again, use your ju
|
|||
10. Read the (prettified and indented) HTML source itself and parse it with your brain. See if anything seems illogical or un­necessary. Imagine giving someone a printout of your page's `<body>` along with a whiteboard. If they have a basic knowledge of HTML tags, would they be able to draw something resembling your website?
|
||||
11. Test with unorthodox graphical browser engines, like NetSurf, Servo, or the Serenity OS browser.
|
||||
12. Try printing out your page in black-and-white from an unorthodox graphical browser.
|
||||
13. Download your webpage and test how multiple word processors render and generate PDFs from it.[^15]
|
||||
13. Download your webpage and test how multiple word processors render and generate PDFs from it.[^16]
|
||||
14. 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.
|
||||
15. 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](https://xkcd.com/567/).
|
||||
|
||||
|
|
@ -1396,7 +1399,7 @@ I've learned about a great number of under­represented ways to browse from t
|
|||
|
||||
An early version of this article received useful responses when I [posted it to Lobsters](https://lobste.rs/s/akcw1m/opinionated_list_best_practices_for); I incorporated some feedback shortly afterward.
|
||||
|
||||
A special thanks goes out to GothAlice for the questions she answered in `#webdev` on Libera.Chat.
|
||||
A special thanks goes out to GothAlice for the questions she answered in <samp>#webdev</samp> on Libera.Chat.
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -1413,7 +1416,7 @@ A special thanks goes out to GothAlice for the questions she answered in `#webde
|
|||
|
||||
[^6]: Ironically, that page doesn't load the main text without JavaScript despite citing a JavaScript requirement as a downside. If you can't load the page, the same reasons are [outlined here](https://addyosmani.com/blog/infinite-scroll-without-layout-shifts/) in the "Accessibility concerns for infinite scroll" section.
|
||||
|
||||
[^7]: Firefox users [can enable "find as you type"](https://website-archive.mozilla.org/www.mozilla.org/access/access/type-ahead/) by toggling a preference in `about:config`. Chromium (and derivatives) users can [install an extension](https://github.com/Foxy/chrome-type-ahead); note that it requires full-page access and performs script injection to work.
|
||||
[^7]: Firefox users [can enable "find as you type"](https://website-archive.mozilla.org/www.mozilla.org/access/access/type-ahead/) by toggling a preference in <samp>about:config</samp>. Chromium (and derivatives) users can [install an extension](https://github.com/Foxy/chrome-type-ahead); note that it requires full-page access and performs script injection to work.
|
||||
|
||||
[^8]: Iterating through a list of font names to see if each one is available on a user's system is a slow but effective way to determine installed fonts without being granted permission to use the Font Access API. [Browser­Leaks has a demo](https://browserleaks.com/fonts) of this approach. Warning: the page might hog your CPU for a while.
|
||||
|
||||
|
|
@ -1421,15 +1424,17 @@ A special thanks goes out to GothAlice for the questions she answered in `#webde
|
|||
|
||||
[^10]: [WebAIM](https://wave.webaim.org/api/docs?format=html) and the [University of Illinois](https://fae.disability.illinois.edu/rulesets/IMAGE_4_EN/) recommends 100 characters; [Tangaru](https://www.tanaguru.com/en/) recommends an even lower limit of 80 characters.
|
||||
|
||||
[^11]: 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.
|
||||
[^11]: Since <abbr title="Windows High Contrast Mode">WHCM</abbr> sets colors independent of explicitly-defined ARIA roles, it's a good way to test adherence to [the First Rule of ARIA](#first-rule-of-aria).
|
||||
|
||||
[^12]: <span 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.
|
||||
|
||||
[^13]: 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.
|
||||
[^13]: 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.
|
||||
|
||||
[^14]: Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnera­bilities. In Firefox, navigate to `about:config` and toggle some flags under <code>javascript<wbr>.options</code>.
|
||||
[^14]: 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.
|
||||
|
||||
[^15]: Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnera­bilities. In Firefox, navigate to <samp>about:config</samp> and toggle some flags under <code>javascript<wbr>.options</code>.
|
||||
|
||||
<figure itemscope itemtype="https://schema.org/SoftwareSourceCode">
|
||||
<figcaption>
|
||||
|
|
@ -1445,7 +1450,7 @@ A special thanks goes out to GothAlice for the questions she answered in `#webde
|
|||
|
||||
In Chromium and derivatives, run the browser with `--js-flags='--jitless'`; in the Tor Browser, set the security level to "Safer".
|
||||
|
||||
[^15]: 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.
|
||||
[^16]: 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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue