I’ve mostly re-written this article since the last time it was submitted (the canonical URL changed but a redirect is in place).
I’ve shifted much of its focus to accessibility. Accessibility guidance tends to be generic rather than specific, and any information more specific or detailed than WCAG is scattered across various places.
I’ve quickly skimmed through your article, stopping mainly at the sections that interest me, and I would have liked it to be split into a series of more focused articles / pages. Right now it’s hard to see where a section starts and when one begins.
All-in-all I’ve found quite some good advises in there.
Thanks for writing it!
I’m a big fan that I keep seeing a stronger push away from CDNs considered a best practice.
I really wish prefers-reduced-data had much better support so it was easier to plan around the connection issue the author brings up. <picture> tag lets you use media attributes so you could only load if the user wants the image. The problem comes up when trying to support onlyreduced because using CSS alone, you can’t really prove the negative of “if reduced or the browser doesn’t support the feature”. I burnt a lot of time on this recently to no avail.
Another thumbs up for focusing on users changing the fonts on their browser and respecting that instead of ignoring it with a big font stack assuming I’d ever want to see Ubuntu just because I’m on Linux. Related to the above paragraph, when I’m on a stable connection however, I do still prefer a self-hosted font for branding’s sake because I value the typography if well designed–which is subjective and some websites just throw in Roboto because “I dunno, pick something that’s kinda inoffensive to read”.
I never get tired of always suggesting against px either. I set my font size a bit larger on some contexts (like my media server where I’ll browse the web on the couch). Sites using rem and % have no trouble. I still do prefer px specifically for border as a lot of time I didn’t want a round up error to make things to thick or thin.
I appreciate calling it “small viewports” instead of “mobile” because “small viewport” makes only one assertion about the user agent: it’s viewport is small.
More controversially, I’ll also disagree with black for prefers-color-scheme: dark. Because #000 consumes the least amount of energy, it is the best choice for dark environments and the planet. With a true dark and good contrast, I can really crank down the brightness on my laptop and phone (both OLED) which saves battery too. Folks that say it’s unnatural don’t seem to account for the device itself not being a black hole for light. Not everyone, but I do think #000 complainers might have meh monitors with the brightness turned up higher than it needs to be (but just a guess). I’m pretty bummed that the Lobster’s team got bullied out of the #000 background for its dark theme (luckily the CSS vars made my user styles a breeze).
I hard disagree with SVGO usage though. SVGO’s defaults are far too aggressive, including stripping out licence metadata which is categorized the same as editor attributes—which could put you in violation of CC BY and is generally just not nice to the artist. No separation means you can’t get rid of just your Inkscape attributes that help when editing (like you grid values, etc.). The SVGO maintainer is adamant that all users should be reading the manuals and while that’s somewhat true, a) pick better defaults and b) many tools have it in the toolchain and you cannot configure it (think create-react-app, et. al). You can see some projects like SVGR where most of their issues are SVGO-related. My suggestion: use scour, aggressive options are opt-in.
The Helmholtz–Kohlrausch effect and the APCA’s perceptual contrast research show that the mathematical difference between two colors is quite different from the perceptual contrast we experience.
There’s more than one type of contrast at play here. Lowering brightness until halation, overstimulation, etc. become non-issues will likely compromise legibility. You can get a much higher contrast that doesn’t trigger halation as easily by giving the background some extra lightness.
If you still want a solid-black (or almost-solid-black) background, look into the prefers-contrast media query. You can use it to specify a reduced or increased contrast preference. I try to keep a default that balances the different needs, but offer alternative palettes for reduced/increased contrast preferences.
The main issue I’ve run into with svgo is that it defaults to dropping the viewbox attribute on the svg element in cases where it is not redundant, i.e. does affect rendering.
Yep. I mentioned SVGR; they have 149 issues related to SVGO which makes it ≅⅓ of their issues and they span the whole spectrum of issues. It’s so flawed that I ban its usage in teams I work around now to save them the headaches it can cause as well as the potential legal trouble you could run into on the licensing front.
Given that the article touches on many non-mainstream browsers, I think a special consideration should have also been given to console browsers like lynx, w3m, and others. I know almost nobody uses one of these to browse the internet these days, but they might be used by some automated tools to ingest your contents for archival or quick preview.
From my own experience it’s quite hard to get a site to look “good” in all of these, as each have their own quirks. Each renders headings, lists, and other elements in quite different ways. (In my view w3m is more closer to a “readable” output, meanwhile lynx plays a strange game with colors and indentation…)
For example I’ve found that using <hr/> are almost a requirement to properly separate various sections, especially the body of an article from the rest of the navigation header / footer. (In fact I’ve used two consecutive <hr/>s for this purpose, because the text might include a proper <hr/> on its own.)
On a related topic, also a note regarding how the page “looks” without any CSS / JS might be useful. (One can simulate this in browser by choosing the View -> Page Style -> No Style option.)
As with console browsers, I’ve observed that sometimes including some <hr/>s makes things much more readable (Obviously these <hr/> can be given a class and hidden with CSS in a “proper” browser.)
I know almost nobody uses one of these to browse the internet these days
I find them essential when on a broken/new machine which doesn’t have X11 set up correctly yet. Or on extremely low-power machines where Firefox is too much of a resource hog. Especially mostly-textual websites should definitely be viewable using just these browsers, as they may contain just the information needed to get a proper browser working.
I actually was recently showing other members on their team that they will do better markup and CSS if they always test with a TUI browser and/or disabling styles in Fx after doing it myself for a few years now. It will often lead to better SEO too since non-Google crawlers will not be running that JS you wrote.
Er, sort of. There are lots of great reasons to test in a textual browser, but “accessibility” is lower on that list than most people realize. It’s easy for sighted users to visually skip over blocks of content in a TUI or GUI, but the content needs to be semantic for assistive technologies to do the same.
I consider textual browsers a “sniff test” for accessibility. They’re neither necessary nor sufficient, but they’re a quick and simple test that can expose some issues.
I do absolutely advocate for testing with CSS disabled; CSS should be a progressive enhancement.
I’ve mostly re-written this article since the last time it was submitted (the canonical URL changed but a redirect is in place).
I’ve shifted much of its focus to accessibility. Accessibility guidance tends to be generic rather than specific, and any information more specific or detailed than WCAG is scattered across various places.
Feedback welcome. I’m always adding more.
I’ve quickly skimmed through your article, stopping mainly at the sections that interest me, and I would have liked it to be split into a series of more focused articles / pages. Right now it’s hard to see where a section starts and when one begins.
All-in-all I’ve found quite some good advises in there. Thanks for writing it!
Update: added an “Against focusable containers” section.
I’m a big fan that I keep seeing a stronger push away from CDNs considered a best practice.
I really wish
prefers-reduced-datahad much better support so it was easier to plan around the connection issue the author brings up.<picture>tag lets you usemediaattributes so you could only load if the user wants the image. The problem comes up when trying to support onlyreducedbecause using CSS alone, you can’t really prove the negative of “if reduced or the browser doesn’t support the feature”. I burnt a lot of time on this recently to no avail.Another thumbs up for focusing on users changing the fonts on their browser and respecting that instead of ignoring it with a big font stack assuming I’d ever want to see Ubuntu just because I’m on Linux. Related to the above paragraph, when I’m on a stable connection however, I do still prefer a self-hosted font for branding’s sake because I value the typography if well designed–which is subjective and some websites just throw in Roboto because “I dunno, pick something that’s kinda inoffensive to read”.
I never get tired of always suggesting against
pxeither. I set my font size a bit larger on some contexts (like my media server where I’ll browse the web on the couch). Sites usingremand%have no trouble. I still do preferpxspecifically forborderas a lot of time I didn’t want a round up error to make things to thick or thin.I appreciate calling it “small viewports” instead of “mobile” because “small viewport” makes only one assertion about the user agent: it’s viewport is small.
More controversially, I’ll also disagree with black for
prefers-color-scheme: dark. Because#000consumes the least amount of energy, it is the best choice for dark environments and the planet. With a true dark and good contrast, I can really crank down the brightness on my laptop and phone (both OLED) which saves battery too. Folks that say it’s unnatural don’t seem to account for the device itself not being a black hole for light. Not everyone, but I do think#000complainers might have meh monitors with the brightness turned up higher than it needs to be (but just a guess). I’m pretty bummed that the Lobster’s team got bullied out of the#000background for its dark theme (luckily the CSS vars made my user styles a breeze).I hard disagree with SVGO usage though. SVGO’s defaults are far too aggressive, including stripping out licence metadata which is categorized the same as editor attributes—which could put you in violation of CC BY and is generally just not nice to the artist. No separation means you can’t get rid of just your Inkscape attributes that help when editing (like you grid values, etc.). The SVGO maintainer is adamant that all users should be reading the manuals and while that’s somewhat true, a) pick better defaults and b) many tools have it in the toolchain and you cannot configure it (think
create-react-app, et. al). You can see some projects like SVGR where most of their issues are SVGO-related. My suggestion: usescour, aggressive options are opt-in.The energy usage difference has been shown to be negligable: https://www.xda-developers.com/amoled-black-vs-gray-dark-mode/
Personally, I like to keep my phone brightness quite low, and I find the contrast between text and #000 backgrounds to be rather…painful.
I’m aware that it’s a low difference, but
#000is still the lowest. The internet has a lot of devices connected to it, so it does add up.Lowering brightness reduces the contrast. Simple as that.
Contrast is a little more complex than that.
The Helmholtz–Kohlrausch effect and the APCA’s perceptual contrast research show that the mathematical difference between two colors is quite different from the perceptual contrast we experience.
There’s more than one type of contrast at play here. Lowering brightness until halation, overstimulation, etc. become non-issues will likely compromise legibility. You can get a much higher contrast that doesn’t trigger halation as easily by giving the background some extra lightness.
If you still want a solid-black (or almost-solid-black) background, look into the
prefers-contrastmedia query. You can use it to specify a reduced or increased contrast preference. I try to keep a default that balances the different needs, but offer alternative palettes for reduced/increased contrast preferences.The main issue I’ve run into with svgo is that it defaults to dropping the viewbox attribute on the svg element in cases where it is not redundant, i.e. does affect rendering.
Yep. I mentioned SVGR; they have 149 issues related to SVGO which makes it ≅⅓ of their issues and they span the whole spectrum of issues. It’s so flawed that I ban its usage in teams I work around now to save them the headaches it can cause as well as the potential legal trouble you could run into on the licensing front.
Given that the article touches on many non-mainstream browsers, I think a special consideration should have also been given to console browsers like
lynx,w3m, and others. I know almost nobody uses one of these to browse the internet these days, but they might be used by some automated tools to ingest your contents for archival or quick preview.From my own experience it’s quite hard to get a site to look “good” in all of these, as each have their own quirks. Each renders headings, lists, and other elements in quite different ways. (In my view
w3mis more closer to a “readable” output, meanwhilelynxplays a strange game with colors and indentation…)For example I’ve found that using
<hr/>are almost a requirement to properly separate various sections, especially the body of an article from the rest of the navigation header / footer. (In fact I’ve used two consecutive<hr/>s for this purpose, because the text might include a proper<hr/>on its own.)On a related topic, also a note regarding how the page “looks” without any CSS / JS might be useful. (One can simulate this in browser by choosing the
View -> Page Style -> No Styleoption.)As with console browsers, I’ve observed that sometimes including some
<hr/>s makes things much more readable (Obviously these<hr/>can be given a class and hidden with CSS in a “proper” browser.)I find them essential when on a broken/new machine which doesn’t have X11 set up correctly yet. Or on extremely low-power machines where Firefox is too much of a resource hog. Especially mostly-textual websites should definitely be viewable using just these browsers, as they may contain just the information needed to get a proper browser working.
I actually was recently showing other members on their team that they will do better markup and CSS if they always test with a TUI browser and/or disabling styles in Fx after doing it myself for a few years now. It will often lead to better SEO too since non-Google crawlers will not be running that JS you wrote.
Netsurf is still a browser to consider too.
Er, sort of. There are lots of great reasons to test in a textual browser, but “accessibility” is lower on that list than most people realize. It’s easy for sighted users to visually skip over blocks of content in a TUI or GUI, but the content needs to be semantic for assistive technologies to do the same.
I consider textual browsers a “sniff test” for accessibility. They’re neither necessary nor sufficient, but they’re a quick and simple test that can expose some issues.
I do absolutely advocate for testing with CSS disabled; CSS should be a progressive enhancement.