When I was starting this site in September, 2018, its “About” page looked like this:
What I didn’t know at the time was that its links were unfriendly from an accessibility standpoint — for two reasons, both of them affecting people with certain visual impairments:
- When links aren’t underlined, you’re leaving their color as the only method which distinguishes them from unlinked text.
- These links’ particular shade of blue lacked sufficient contrast with the white background.
Then, a few months later, I took an online accessibility course1 for my Day Job of that time and learned I’d been falling far short on this count, especially where the WCAG specification is concerned.
Since then, I’ve made sure that my links are underlined2 and contrast sufficiently with whichever background they have at the time. While the former was fairly easy to achieve, I’ve taken pains to style all my site’s text with sufficient contrast, in both light and dark viewing modes. That applies to even the syntax highlighting in code segments. (The WebAIM contrast checker is a page I’ve used often.)
In fact, it’s because of those code segments that I’m writing this.
Yesterday, I became aware that there was one more thing I could do to enhance accessibility, but it required me to rethink a position I’d long held on one of the Holy Wars among developers: tabs vs. spaces. In other words: when you add an indent to a line of code, should you do so with one tab character or multiple space characters?
If you have no idea what I’m talking about or what difference it could possibly make, you probably haven’t worked with other developers on a shared code base — and you probably won’t get the humor in this clip from an old Silicon Valley episode:
Note: Clicking the video constitutes your consent to view it via YouTube (including cookies). To view it on the YouTube site instead, please use this link.
As for me, my former position on this Holy War was for spaces over tabs when it’s solely my choice, as is the case for this site.
Then, yesterday, I had my mind changed.
That’s when I saw a Hacker News thread about Garrit Franke’s article, “The only true answer to ‘tabs vs spaces.’” My curiosity piqued, I followed a chain of links from that discussion and found two particular items:
- A 2019-07-02 post on the JavaScript subreddit called “Nobody talks about the real reason to use Tabs over Spaces.”
- A 2020-08-04 comment by Mario Zehe on a GitHub issue.
Now, since I am a team of one where this site is concerned, you might think it wouldn’t matter what I do with its code. After all, these links refer to what happens when multiple developers, some of whom have visual impairments, work together on code.
However, the code samples I provide in various articles typically come from the site’s code. What if any visually impaired people want to copy/paste my code samples? Besides, my site repo is public, so even code I don’t copy into articles might be problematic for such folks. These considerations are why I decided to convert nearly3 all my code’s indents from spaces-based to tabs-based.
So that’s what I did. Fortunately, Visual Studio Code makes that fairly easy, albeit one file at a time.
I also changed the site’s .editorconfig file to the following, specifically the indent_style setting (which had been space):
root = true
[*]
indent_size = 2
indent_style = tab
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
charset = utf-8
[*.{sh,txt,yml,yaml}]
indent_style = space
[layouts/_default/_markup/*.*]
insert_final_newline = falseUpdate, 2022-07-04: This .editorconfig file is a revised version of what I originally posted. This takes into account certain troublesome3 file types.
As for making sure my existing code samples then still looked as I desired (for me, that’s two spaces per indent, as you saw in that indent_size setting above), I adjusted the site’s styling to add a tab-size setting for the display of code samples:
code[class*="language-"],
pre[class*="language-"] {
color: #ddd;
background: none;
text-align: left;
white-space: pre;
word-spacing: normal;
word-break: normal;
word-wrap: normal;
line-height: 1.5;
tab-size: 2;
hyphens: none;
}But, when somebody copies the code, it’ll come through as tabs, and then that person’s chosen editor app settings can take care of it, no matter how much horizontal space that person wants each indent to represent on the screen. This flexibility for visually challenged visitors is what I hope I’ve achieved with these modifications.
Whether efforts like these are worth the time where your own site’s code is concerned (assuming you’re in a dev environment where you even have the choice), only you can decide. But, as for this site and its code, it was my call to make; and I think I made the right one.
It was offered by the University of Toronto through Canvas Network. Unfortunately, it doesn’t appear to be in the current Canvas Network catalog; otherwise, I’d recommend it without reservation. ↩︎
For a long time, they weren’t really underlined. Instead, because HTML underlining often screwed up the descenders on characters like p and g, I styled my site’s links to have borders underneath. The visual effect was the same. However, with wider browser support for several key CSS features — such as text-underline-offset, text-decoration-thickness, and text-decoration-skip-ink — it became possible for the underlines to be real again, simplifying overall styling (especially for dark mode). ↩︎
There are a few kinds of code — YAML is a notable example — where you still must use spaces for indents. Thus, don’t go whole-hog and change all files’ spaces-based indents to tabs without making sure you don’t hose such spaces-dependent files and formats, especially if it’s code on which your site actually depends (e.g., a YAML config file for your site). Similarly, you won’t want to include such FUBARed code in samples in your own posts. ↩︎ ↩︎
Latest commit (b87343dc) for page file:
2023-08-17 at 10:22:28 AM CDT.
Page history