Skip to main content
cartoon drawing of an archaeopteryx working on a laptop
Archeaopteryx
Adventures of a novice coder

Hello, Website!

I've toyed around with the thought of making a personal website a few times. Like many people, I picked up the basics of html, css and js out of curiosity and could at least make simple pages. But going from that to actually producing content on the web felt like an insurmountable task.

Learning about Github Pages suddenly made my beginner-website ideas feel achievable, and it gave the option to code the site from scratch. It's always good to get your hands a little dirty.

This meant that I finally had to make concrete decisions about what I wanted my personal website to actually be. The following is a short summary of the design decisions for this simple site, and some things I learned along the way that I found interesting.

Personal webpage goals

I had some ideas for content, but was faced with a blank page in terms of layout.

Eventually I came up with something of a list of goals to guide the design. Easy navigation, simple layout, readability, mobile-friendly instead of mobile first, and that nifty horizontal bar that shows you how far you've read. That last one will have to wait a bit, but at least I finally had some ideas for what the page should look like.

I still needed a color scheme. So I came up with the idea for my archeaopteryx 'logo'. After an afternoon with Inkscape, I wound up with something that could serve as the definition for the website color scheme.

An important goal was accessibility for users with screenreaders, color-blindness, or who rely on keyboard navigation. Even if this is just a small personal page I still value the effort to make the web more accessible and want to do my part.

Accessibility

Making an accessible website turned out to be a bit more complex than I expected, and I'm sure there are still many points where I can improve. Thankfully, there are many useful resources, such as the site for the Web Accessibility Initiative, to help the uninitiated.

First, there are points intrinsic to the html. Images should have an "alt text" description, and the principles of semantic html should be followed. Furthermore, it should be possible to navigate the website with keyboard alone. This was already essentially the case since tabbing iterates through anchor elements by default. But it could be improved by including the ability to skip directly to the main content.

Then there are points that are a bit more stylistic in nature, such as the font selection, the definition of the font-size, and the color scheme. An extensive topic that I only barely scratched the surface of.

skip-to-main

Having a 'skip-to-main' option spares users relying on screenreaders or keyboard navigation from going through all of the navigation options before reaching the content. Fortunately for the casual coder, there are plenty of resources that give suggestions for implementing the 'skip to main' feature without it being noticed by users that don't need it. I wound up adding


/*Hidden skip to main option for keyboard users */
a.skip-main {
    left: -999px;
    position: absolute;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
    z-index: -999;
}

a.skip-main:focus {
    left: auto;
    top: auto;
    width: 30%;
    height: auto;
    overflow: auto;
    margin: 0 35%;
    padding: 5px;
    font-size: x-large;
    outline: 3px solid red;
    background-color: #FFF;
    text-align: center;
    z-index: 999;
}
                        

to the css for the my article pages. This basically means that an anchor element of class 'skip-main' is initially only 1 pixel and located off the viewable screen. If a 'skip-main' anchor element comes into focus via the tab key, then it moves onto the viewable area and becomes a noticable feature. This anchor element should then link to the start of the main content. I added the necessary anchor


<a class="skip-main" href="#main">Skip to main content</a>
                        

to the div with my main navigation menu and gave my main element the id 'main' for the anchor reference to hook to, as well as the tabindex value of -1.


<main id="main" tabindex="-1">
                        

The tabindex of -1 means that the main element is not part of the normal navigational flow of the website. You cannot tab directly to 'main'. But it can gain focus by other means. In this case, it gains focus if the user follows the 'skip to main' link.

Font-sizing

This is something that I will almost certainly have to revisit in the future. It seems that setting the font size in pixels causes problems for users who need to be able to enlarge the font on their device. From what I understand, font sizing should be defined using relative values (the em and rem units, or percentages) or using keywords (medium, large...) rather than using pixel values.

For now, I'm mostly using keyword definitions. Initially there were so many decisions to be made, I wanted to be limited to a few predefined keywords. But I will probably change to using em units for more flexibility.

Colors

My first color scheme was based on the named css colors 'saddlebrown' and 'seagreen'. I assumed that I was on solid ground with this choice. Sure, distinguishing green and brown might be a problem, but I'm not really encoding information in the colors, and there seemed to be good contrast for both colors with the white and grey backgrounds. But a test was naturally in order.

There's a nice looking tool for simulating colorblindness called Color Oracle from a research group in Australia. Unfortunately, it didn't run on my laptop. So I wound up using an online tool to test my color choices.

It turns out that seagreen on the grey background of the sidebar wasn't the greatest of choices. But some small adjustments to the colors gave the same visual feel while increasing the color contrast to acceptable values.

Mobile friendly, not mobile-first

The first time I switched on the responsive design mode of Firefox, I was shocked at just how terrible my fledgling website looked. I had added preliminary @media rules for smaller screens, but underestimated just how drastically I would have to change the layout.

Now the site should at least be tolerably usable on mobile (mostly thanks to whoever came up with the viewport unit), but it still doesn't look great. I was a bit surprised to find that, despite my efforts to be mobile-friendly, I still wouldn't want to use my own website on a smartphone.

I think the core issue is that my content was written with a larger screen in mind. To really make the site mobile friendly, I would have had to also divide up and write the content in a mobile friendly way. Apparently I badly underestimated the difficulty of making a site look good on both desktop and mobile.

Initial lessons learned

I feel like I learned two very important lessons. One: even for making a simple website, the most difficult challenge faced is the blank page. And two: static site generators provide a valuable service. This is a tiny, simple website, yet my mind is already drifting to how to automate things and I am impressed with how easy it is to lose the oversight.

Overall, making this site has been a fun experience, and I look forward to improving it!