Skip to content
Browse files
Update home page; migrate old content
- Highlight open rebuild/redesign
- Intentionally did not migrate:
    - Old home page content (irrelevant)
    - work index (will temporarily redirect to v1 subdomain)
    - work pages (will redirect to v1 subdomain)
    - resume (will temporarily redirect to v1 subdomain)
    - colophon (will temporarily redirect to v1 subdomain)
  • Loading branch information
kylegach committed May 6, 2020
1 parent a7e3d1f commit 09999f9ad4bbabcc375253dc20aee646279a2dbb
Showing 10 changed files with 637 additions and 1 deletion.
@@ -1,4 +1,12 @@
module.exports = function(config) {
config.addCollection('writing', (collection) => {
return [


return {
dir: {
input: 'src',
@@ -0,0 +1,30 @@
{% set siteName = 'Kyle Gach' %}
{% set pageTitle = title + '' + siteName if title else siteName %}

<!DOCTYPE html>
<html lang="en">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>{{ pageTitle }}</title>
{{content | safe}}

<hr />
<li><a href="/">Home</a></li>
<li><a href="/writing/">Writing</a></li>
<li><a href="">Email</a></li>
<li><a href="">Twitter</a></li>
<li><a href="">GitHub</a></li>
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@@ -1 +1,9 @@
# Hello world
layout: layouts/base

# Kyle Gach

Rhymes with scratch.

_I'm rebuilding and redesigning this website in the open. [Follow along if you wish](
@@ -0,0 +1,22 @@
title: Of the Web
permalink: /writing/of-the-web/
date: 2016-04-12T14:01:34Z
layout: layouts/base

# {{ title }}

I’ve been _on_ the web for most of my life, but, without a site to call home, I haven’t been [_of_ the web]( for far too long.


I’m proud to announce the launch of this site, by far my most personal website ever. Making this spot on the web mine has taken great effort and care, and I’ve deeply enjoyed all of it^[Well, almost all of it. Those SVG animations were fairly tedious to make.]. Like any successful project, I defined a vision/goals for this site before I started any work:

1. **[Learn and employ many new tools](/colophon/) to accurately demonstrate my understanding of building for the web, in a manner I believe to be best**. This site’s primary purpose is to serve as my portfolio, and I wanted to use this site as a way to show off a bit, when doing so isn’t always appropriate or possible for the projects I work on at [CivicPlus](

2. **Make this site as accessible and fast as I can**. The web is best when it is open to all, and making things accessible and fast (which are often overlapping concerns) helps provide that. I’ll probably be writing much more about this.

3. **Build for learnability**. I learned everything I know about building for the web from the generosity and kindness of others who shared their knowledge, tools, struggles, and passions. I owe my entire career to the web community, and I want to give back. While viewing source in the age of module bundlers and style processors is of less utility than it used to be, I hope that sharing this [site’s source code]( can help someone curious enough to dig in.

It’s empowering to have a place of your own, viewable to all, where every aspect is exactly as you want it. Or, at least, as close as you can get it within your knowledge and skill set. For example, I get frustrated when I have to look at a white screen at night, so I made a “night mode” that automatically flips on after sunset. I’m eager to find more ways to express and practice building my ideal web with design, code, and prose, and I’m delighted to finally have a place to do so.
@@ -0,0 +1,102 @@
title: Everything I Did to Make This Site Accessible
permalink: /writing/everything-i-did-to-make-this-site-accessible/
date: 2016-04-16T04:54:54Z
layout: layouts/base

# {{ title }}

I believe the web is meant to be open and available to everyone, no matter who they are, what device/software they’re using, or the speed/quality of the network they’re on.


Accessibility (also known as [a11y]( is so much bigger than just making things work for people with no or low vision. But, even if you define it so narrowly, that’s still [285 million people]( or ~5% of the world’s population. What follows is a collection of everything I’ve done to make this site as accessible as I could.

_Note: I‘m using [The A11y Project‘s helpful checklist]( as a rough starting point for this post._

## Not relying on JavaScript (Progressive Enhancement)

This site is built using [React](, a JS library. _But_, it renders everything from the server before all that JS does anything. The JS then progressively enhances the site to enable things like super-fast additional page loads and the SVG animations. This means that the site will be accessible even if the JS were to fail for any reason. You may think the numbers for that are small... like, 1%. Keep in mind that it’s not 1% of people who always encounter a broken site, and 99% of people who don’t. It’s 1% of _visits_. I stole that line from [this wonderful illustration of the phenomenon](

Also, progressive enhancement makes supporting older browsers *so much easier*. Because the site will always work without JS, you can [cut the mustard]( so that your JS only runs on your supported browsers. Meaning you don’t ever have to write JS to work in non-modern browsers.

## Making it responsive

The only reasonable way I know of to ensure a website is usable on _any_ device/software is [Responsive Web Design](

## Writing semantic HTML

The easiest way to make something accessible is when you get it for free. By using `<header>`, `<footer>`, `<nav>`, `<button>`, and other elements appropriately, you build accessibility into the very structure of your app. This includes using `<h1>`, `<h2>`, etc&hellip; in a sensible order. I reviewed this site’s code and found some areas I could improve.

[A11y commit #1](

## Supplanting semantic HTML with `aria` landmark roles

While most browsers automatically associate, say, `<main>` with `aria-role="main"`, [not all do]( So it’s best to go ahead and define those yourself.

[A11y commit #2](

## Focus states

A lot of sites have some CSS like this to remove the default dotted outline when elements are focused in some browsers:

a:focus {
outline: none;

Don‘t do that! If you absolutely must remove it, you also _must_ define your own focus styles.

## Use alt text (and the equivalent for SVG)

Any image in the content of a site must have an appropriate `alt` attribute defined. The only exception is images that are purely decorative.

For SVGs, you can use the `<title>` and `<desc>` elements to describe the graphic in combination with `aria` attributes. See the commit for examples.

[A11y commit #3](

## Test for sufficient color contrast and color blindness

Researchers have determined a minimum threshold for foreground/background color contrast that is readable by most people, which is specified as part of [WCAG]( You can use a tool like [aXe](, which integrates into Chrome‘s Dev Tools, or [tota11y](, which can be integrated into your site or used as a bookmarklet, to check if the text of your site meets this threshold. There are some gotchas, though:

1. It will only test actual text and backgrounds, not text that is part of or on top of an image.
2. It cannot determine the contrast of pseudo-elements (`::before` & `::after`)

After running checks, if I find any colors that need changed, I like to use [Colorable]( to find values with sufficient contrast.

[A11y commit #4]( &amp; [A11y commit #5](

## Consider a “Skip to content” link

Sometimes a site can have a lot of stuff that a person using a screenreader or restricted to a keyboard would have to wade through before they get to the content. Including a [link to skip down to the content]( in the very beginning of your page that is visually hidden until focused is a nice way to help them out.

This site has a very minimal header and the primary navigation is at the bottom of the page, so the link I‘m adding will be “Skip to navigation”.

[A11y commit #6]( &amp; [A11y commit #7](

## Make sure to use descriptive links

Consider the post teasers on my [Writing](/writing/) page. They have a title, a brief excerpt of the post, and a Keep Reading&hellip; link. Sighted users can see that the “Keep Reading&hellip;” belongs to the post above it, but screen readers have no way of relaying that information to their users. That is, not without a little help.

We can use `aria` attributes again to add a more descriptive label to those links:

<article role="article">
<h3 id="everything-i-did-to-make-this-site-accessible"><a href="/writing/everything-i-did-to-make-this-site-accessible/">Everything I Did to Make This Site Accessible</a></h3>
<em><span title="April 12, 2016">3 days ago</span></em>
<div>I believe the web is meant to be open and available to everyone, no matter who they are, what device/software...</div>
<a href="/writing/everything-i-did-to-make-this-site-accessible/" aria-labelledby="everything-i-did-to-make-this-site-accessible">Keep reading…</a>

_Thanks to [this CodePen]( by [Gray Ghost Visuals]( for the technique._

You should also generally avoid using generic phrases like “Click here” for your links, because they provide very little context.

[A11y commit #8](

## Test, test, test

After you’ve done everything you can, you should test your site using assistive technology tools. Ideally, you‘d do so with someone who uses such tools on a regular basis, but you can simply use the tools yourself in a pinch. If you‘re on a Mac, you have [VoiceOver]( built in.

0 comments on commit 09999f9

Please sign in to comment.