I'm deaf. Not blind. But captions got me thinking something about accessibility that transferred straight into how I build websites: when content isn't designed with you in mind, you don't struggle with it — you leave.
Captions are one of the reasons I can watch a technical tutorial, follow a photography vlog, or understand what's happening in a video someone sent me. Without them, the content doesn't exist or is frustrating to watch. It's not that I can't always find ways around it, it just sours the experience for me.
That experience — being locked out of something because of missing accessibility or language options — is what I think about when I'm writing content. I'm not an accessibility consultant. I don't audit sites for WCAG compliance. But I do know what it feels like to be excluded by an interface, and that shapes some of my decision making when I build websites.
Headings Aren't Decoration
When I first started building websites, I thought heading levels were about font size. <h1> is big, <h2> is smaller, <h3> is smaller still. Pick the one that looks right.
That's wrong, and it matters more than almost anything else on the page.
Screen readers build an outline from heading levels. A user can jump from heading to heading, skipping over paragraphs they don't need, the same way a sighted reader scans for the next section break. If your page goes <h1> → <h3> → <h2> → <h4> because that's what looked balanced in the CSS, a screen reader user gets a broken map. The outline makes no sense. I sometimes get this wrong when building, but I try to go back to it when I remember.
On this site, the rule is simple: the page title is the only <h2>. Every section heading is <h3>. Sub-sections under that would be <h4> — I haven't needed them yet, but the path is clear. Emphasis like Prerequisites or Disclaimer stays as <p><strong> — it's a label, not a heading, and putting it in the document outline pollutes it with noise.
This costs nothing to implement. It's just routine. Once you decide on a heading structure, you stick to it.
Tables: They're Fine Until They're Not
A <table> with five columns looks great on a 27-inch monitor. On a phone held in portrait, it's either pinched to illegibility or scrolls horizontally — and screen readers have to narrate every cell in row-major order, which turns a quick-reference table into a minutes-long recitation.
On this site, I've been moving away from tables toward card grids. A two-column CSS grid that stacks into a single column on narrow screens. Each card has a title, a short description, and — critically — the information is self-contained. A screen reader announces a card, reads its content, and moves on. There's no "column 3 of 5" context to lose.
The jail rationale table in the fail2ban guide used to be five columns: jail name, signal, threshold, ban duration, and an explanation. On mobile it was a disaster. Now it's four cards in a grid, each one a self-contained summary of one jail. The reader gets the same information in any viewport, in any reading mode, without context collapse.
Tables still have their place. The incremental banning formula table — three columns, short values — works fine in a table. But if you find yourself writing a table with paragraphs in the cells, those paragraphs want to be cards.
Fonts: Readability Over Style
I used to choose fonts the way I chose wallpaper — pick what looks good and move on. But typeface choice affects whether someone can read your content at all.
Sans-serif fonts — the ones without the little decorative strokes at the ends of letters — are generally more readable on screens than serif fonts. The Section 508 guidelines on accessible typography recommend sans-serif for body text, with a minimum of 12pt (16px) for body copy. Serif fonts aren't banned, but they introduce visual complexity that disproportionately affects readers with dyslexia, low vision, or cognitive disabilities.
This site uses a system font stack — whatever sans-serif font the visitor's operating system provides as the default. On macOS that's San Francisco, on Windows it's Segoe UI, on Linux it's whatever the distribution ships. System fonts have two advantages: they're already tuned by the OS vendor for on-screen readability, and they require zero downloads. No web font files to load, no flash of unstyled text, no layout shift when the custom font finally arrives.
If you do need a custom font — a specific brand typeface, or something with a distinctive character that a system font can't match — services like Google Fonts and Font Squirrel let you filter by category ("sans-serif"), and some offer a "legibility" or "accessible" tag. Those filters exist for a reason. A decorative serif headline font might look great in your design mockup and be unreadable at 14px on a lower end display. Filter first, preview second. And if one typeface doesn't hold up at every screen size, CSS @media queries let you swap weights or adjust sizing per breakpoint — so a font that works for headlines on desktop doesn't have to strain at 14px on a phone.
One more thing about custom fonts: if you're loading them from a CDN rather than hosting the .woff2 files locally, set a solid fallback stack. CDNs can be erratic. They can blip more often than your server does across a mesh of networks. When they do, anyone visiting your site sees whatever you put in font-family after your custom font name. If you wrote font-family: "Fancy Display", serif; and the CDN blips, every visitor gets a serif fallback — which on most systems means Times New Roman. A system font stack as your fallback means a CDN outage is invisible to the reader. The text looks slightly different, but it's still legible sans-serif, and most people won't notice the difference.
Beyond the typeface itself, line height matters more than most people think. The Section 508 guidelines recommend a line height of at least 1.5× the font size. Tighter line spacing forces the eye to work harder tracking from the end of one line to the start of the next — for someone who loses their place easily, that effort compounds with every paragraph until they stop reading entirely. A little extra breathing room between lines costs nothing in terms of page weight and makes a measurable difference in readability.
Color: Contrast Is the Bare Minimum
I'm not colorblind. I have an Associate's in Fine Arts — I've spent a few years in darkrooms and behind viewfinders thinking about contrast, subject isolation, changes in light, and how the eye moves through a composition. But none of that training taught me to think about color as an access issue. It taught me to think about color as a tool for directing attention. It turns out those two things overlap more than you'd expect.
In photography, if your subject doesn't separate from the background, the image doesn't usually read. There are times you deliberately blend them — a portrait fading into shadow, the reveal of an object half-hidden — and that works because you're in control of the moment. The viewer leans in. On a web page, nobody leans in. They scroll. Low-contrast body copy doesn't get read — not because the reader is lazy, but because their eye has to work harder to isolate the shapes of the letters from the background behind them. It is similar to the mental fatigue I can get from reading lips all day — my brain has to work overtime to catch most of it. When interpreting visual details requires that same constant concentration, the mental effort never really pauses. It’s a level of exhaustion others might only feel after six uninterrupted hours staring at a terminal.
The callout boxes on this site used to have bright orange borders on warm orange-tinted backgrounds. They stood out. They also looked like warning alerts, which they weren't. Changing them to a muted steel-blue border on a near-white background did two things: it stopped screaming "emergency" at every reader, and the darker border against the lighter background improved contrast — the same principle as separating a portrait from a busy backdrop, just applied to a CSS hex code.
The principle is simple: if the only way to distinguish two pieces of information is by color, you've lost some of your readers. An error message that turns red without also adding an icon or a bold label is invisible to someone with red-green color blindness. A link that's only distinguishable from body text by a subtle color shift might as well not exist for someone who doesn't perceive that shift.
On a text-heavy site like this one, I get most of this for free. There are no infographics, no dashboards, no color-coded status indicators. But the callout boxes, the code blocks, the inline links — those small decisions compound.
Links Should Survive Being Read Out Loud
Screen readers can extract all the links on a page and present them as a list. If your link text is "click here" or "read more," that list is useless. The reader hears "click here, click here, read more, click here" with no context for where any of them go.
The fix is trivial: write link text that describes the destination. "The fail2ban with nftables guide" instead of "click here for the fail2ban guide." It reads naturally in context and survives extraction. It's also better for sighted readers skimming the page, which is everyone.