Developing a Web Site Nonvisually in a Linux Environment

Introduction

Now that this Web site is essentially functional, it is a suitable opportunity to document the decisions made in its initial development. This may spare others who have similar needs to mine a certain amount of research and experimentation.

By way of background, I use both Braille and speech-based assistive technologies, including screen readers and specialized tools such as Emacspeak. I am also familiar with the Linux environment, both on the desktop and as a server. I already had a Web server running on a Linux system that I controlled, hosted by Linode/Akamai, to which I could easily copy files. Hence, the problem was confined to creating the Web site itself, as the installation and configuration of the server was already complete.

Requirements

I wanted to automate the visual presentation of the content as much as possible, placing these details in the hands of software developers with expertise in layout and typography. This would enable me to concentrate on writing logically structured markup and text, with a style sheet taking care of its appearance. This is not an unfamiliar strategy: as a regular user of LaTeX, I am accustomed to having the typographical details decided by the creator of my chosen document class. It was also important for the style sheet to implement a responsive design, so that the content could be read efficiently on a variety of mobile and desktop displays.

I also desired full control over the structure of the site and of individual pages. Writing the HTML code manually has always been an effective approach to ensuring markup-related accessibility requirements are met. Research quickly persuaded me that there would be sufficient markup in common between different pages that a template system was needed to simplify development and maintenance. Additionally, I wanted to be able to edit Web content in any text editor, and to use Git for revision control. I had already been managing my writing projects using Git, thus applying it to the Web site was a straightforward extension of a well established practice.

The Solution Adopted

Static site generators have grown in popularity during recent years. I recalled that the presenters of the Linux Unplugged podcast had switched from the WordPress content management system to the Hugo static generator in redesigning their site. I concluded that Hugo should be able to meet my needs as well.

A static site generator is typically a command line tool that takes a directory containing source files as input, processes them, and writes the files comprising the final Web content to the output. The files in the output directory can simply be copied to the Web server using standard tools such as Rsync. Such tools are ubiquitously available in Linux distributions. Using Linux as my desktop environment made the mechanics of editing, organizing, and transferring files easy.

Thus began the ongoing process of learning to use Hugo. As one would expect, Hugo templates are written in HTML, but there is a template language (a simple, special-purpose programming language) to control the insertion of content into templates. Much of the content can be written in any of several formats, including HTML directly, although Markdown appears to be the most widely used alternative. I opted to follow convention by using Markdown to write most of the document content. Light-weight markup formats such as Markdown are easy to read and to edit with my assistive technologies, as the markup used to indicate documents structures is relatively concise.¹ In cases in which more control was desired over the final output, I could of course write in HTML.

To specify the visual presentation, I chose the Pico CSS framework. There is a “classless” version of the style sheet that avoids the need to specify HTML class attributes. Thus, one can just write simple and correct HTML, applying the default presentation provided by the style sheet.

Documentation

I soon discovered that the best way to learn Hugo sufficiently to satisfy my initial requirements was to refer to multiple sources of documentation. The official documentation is valuable, but it is not a tutorial. A useful supplement was this Hugo tutorial. As often happens, Web searches proved to be the quickest route to solving the specific, technical problems that I encountered.

Refinement

As is apparent from the foregoing overview, I am very much a beginner in Web site development, notwithstanding familiarity with several of the underlying technologies. With the basics in place, the rest should largely be a matter of refinement, and, obviously, of striving to write interesting content.