Fixing a line width issue on this blog
Published on under the IndieWeb category.
A member of the IndieWeb community, jeremycherfas.net, informed me that the text on my blog posts was hard to read. This was interesting because I pay a lot of attention to making sure content on my site is readable. Jeremy made me aware of something that I had not considered in the design of my blog post pages: the line width.
Researching the issue
Line width refers to the width of the container in which words appear. When I designed this site, I decided that all of the text in blog posts would be equal to the size of the full page container. This container is the same length as the navigation bar and footer. Such a long container did make it more difficult to read posts on this blog, especially if you were on a larger screen.
Designing for accessibility is not about ticking items off a box or using specific tools to conduct audits. While these two tasks are important, so too are looking at one’s site for themselves and seeing if anything sticks out as a potential problem. After Jeremy highlighted the issue of line width to me, I started to see why it could be an issue. If I was reading a longer blog post I have written—and my content is typically quite long—it would be easy to get tired because my eyes would have to move from left to right a lot in order to read a full page.
People have known that it is harder to read long columns of text for a long time. A blog post I ran into, which I discuss below that talks about text line width, was written in 2003. I just was not consciously aware line width was an issue on my blog post pages. I found a passage from “Web Style Guide – Basic Design Principles for Creating Website” by Patrick J. Lynch and Sarah Horton:
Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text.
I found the quote above cited in a great article called “Ideal line length for content” on which I relied when thinking of solutions to my problem. This article pointed me to a solution of using the “em” CSS property (one em refers to the size of an uppercase M and changes depending on the font size a user has set for their browser). This property would let me make my container size responsive which would not be possible by specifying a pixel (px) value for the width of my text containre.
Implementing a solution
I spent a bit of time playing around with potential solutions. One solution, highlighted in the “Ideal line length for content” article mentioned earlier, was to set a line width to 30em. This would be enough to fit about 10-20 words in each row of text at 16px (which is the base font size for this site). 30em looked good but I tried 35em to see if that would look any better. I personally preferred 35em since it made space for a few more words on a line but no line of text would have too many words.
Here is the final style rule I wrote to fix the line width issue on my blog posts:
.e-content, .other-posts {
max-width: 35em;
margin: auto;
}
The “margin: auto;” rule lets me center my content so that articles appear in the middle of the page rather than the side. I apply these rules to .e-content and .other-posts so as to ensure that all content that could appear in an article would be centered.
One challenge I did encounter was how I would make images appear full-size in the container when I had limited its width by so much. This is something I am still looking into. My biggest concern was the feature image—the image that appears at the top of most blog posts—so I wrote some Python code that would take all of my img tags at the top of blog posts and turn them into Jekyll front matter. You can find this script here.
Turning the featured image into front matter meant I could place the image anywhere on a blog post, even outside of the post “content” where all of a blog post typically goes. Here is some example front matter for my blog post on building a web page from scratch:
---
layout: post
categories: ["IndieWeb", "Post"]
image_alt_text: "A web page with a blue background and pink heading"
title: "Build your own web home page: Tutorial"
---
The featured image and image alt text are now in front matter, as you can see. I place the image just above the e-content section so that the image doesn’t get constrained by the size of the content container.
I use the following img tag to add an image to a blog post:
<img src="{{ page.image }}" alt="{{ page.image_alt_text }}" class="u-photo">
Wrapping up
Thanks to Jeremy, I have learned something new about content layout. I had no idea that longer line widths were proven to be harder to read. After some visual inspection myself, I found that the longer line widths were not optimal. Indeed, designing a website to be visually appealing is a long-term process. If I see something that does not look right—or a kind reader raises a potential issue with the readability of content on this site—I will investigate.
I am not quite finished with my readability changes yet. I will need to change my search engine so that search results are limited in their width too. I also want to investigate how I can make images inside an article appear bigger than the container. I have no idea how to do this just yet but other websites have this effect so I am confident it can be done.
Have you noticed any visual issues on my site? Is some content hard for you to read? Have you run into an accessibility issue? If so, I want to hear from you. Send me an email at readers@jamesg.blog with your thoughts and comments.