Building an Accessible Website

What is This Website?

This website is a proof of concept intended to show a basic accessible, responsive website. The site was created to serve as an illustration of the principles, techniques, and tools described in my scholarly paper, "Making it Work for Everyone: HTML5 and CSS3 for Responsive, Accessible Design on your Library's Website," presented at the 16th Distance Library Services conference. The suggestions below, based on the final section of the article, provide practical advice, and are intended as one possible roadmap for the creation of an actual web page, or series of web pages. More information is available at the conference website, http://libguides.cmich.edu/dls2014.

Start with Content

As Steve Champeon says, one of the key benefits of using responsive web design is that it forces you to make sure your content is in place before adding design features (2003). Since you'll be adding presentational effects through CSS and Javascript later on, the earliest part of your web design process should be to simply take a look at what your website will contain. (Or, if you're redesigning an existing website, to strip the content of its pretty layout and examine what it should contain.)

Before you even open up your web browser and design software, then, you'll need to figure out what's going on your website, where it's going, and how all of its parts relate to one another. A website is nothing, after all, without the information it contains. If you have a complicated website, the content creation process may take some time, as you determine everything from what needs to go on any given web page, to how your various pages connect to one another, to what your menus will look like. On a streamlined informational website, it may be as simple as typing up or otherwise inputting all the information that the page will contain and making sure it is arranged in a straightforward, intuitive manner (Figure 1).

Remember that you don't want to apply any style information, like italics or bold face, at this point. All you want is text, images, and other content in its simplest possible form.

Add Semantic Markup

Once you have the content arranged, it's time to add basic HTML markup so that the browser knows how to interpret and display your document.

If you use a powerful web development suite like Dreamweaver, make sure you're looking at the code while you edit, and not at a graphical "What You See is What You Get" (WYSIWYG) representation of your website. WYSIWYG can be a wonderful tool, but what it appears to be doing and what it actually does are often quite different. Especially if accessibility is a big concern, you will want to make sure that every edit you apply to your content really does what it's supposed to.

Likewise, if you typed your content into a word processor like MS Word or Open Office, make sure you're not accidentally bringing in the word processor's styling information. Many word processors copy this information when you copy text, and it can quickly make what appears to be an accessible website into a horrible mess. You can copy your text into a plain-text program like Notepad and strip out all the styling, just to be sure. I chose to type up my content in Notepad and then copy it into Programmer's Notepad, an open source text editor with nifty programming options available at http://pnotepad.org. Of course, you can always just type your HTML right into Notepad, or your other word processor of choice.

This is also a good time to add in WAI-ARIA attributes to relevant areas of your website if you have menus, areas of the site which will be used for largely presentational purposes (e.g. banners), or intend to include heavy scripting on parts of your page.

Once you have everything marked up, you should be able to open your page in any browser and see it in its most basic form (Figure 2).

Style Your Site

Now that your content is arrayed and accessible, it's time to add a visual design. The best way to ensure that you can easily update your site in the future is to use an external CSS file, not to define individual styles in-line throughout your document (figure 3). Keeping your content and its layout separated will not only make adhering to the principles of progressive enhancement easier, but will mean that any future updates to your site's content or its design can be much more easily effected, as you will not have to worry about whether a change to content will break your layout, or vice-versa.

The most important thing to remember here is that not all users will interact with your website through visual stimuli, and that even among those who do there are different thresholds for access. Avoid low-contrast color choices like black on grey or grey on white, and make sure your fonts are legible regardless of the end user's device size (figure 4). You can use CSS media queries, described above, to make sure visitors to the site can experience it well on any device, and at any level of ability.

When you’re done with this step, you should have a static website which is accessible to any user, and which is (ideally) aesthetically pleasing regardless of format and device.

Add Scripting (if Necessary)

For a long time, Javascript and other technologies were seen as inimical to accessible web design, but as Connor (2012) points out, the problem lies more with “poor scripting practices” and developer apathy than any particular fault of the language itself (p. 70).  The good news here is that you can add scripts to your website to get all the bells and whistles without making it inaccessible to users with disabilities.  That doesn’t mean, however, you can add scripting without considering its effect on those users.

Connor lays out three principles for accessible Javascript, one of which is progressive enhancement (described above).  The second is that Javascript (or any other scripting language) should be unobtrusive, which means it should be integrated into a page’s functionality, and shouldn’t be implemented in ways which make site controls hard to use (Connor, 2012, p. 71).  The bottom line is that you should always be certain the added “functionality” of scripting won’t actually make your site less functional for users with disabilities or those on older browsers or devices.

If you do add scripting, remember that you can use WAI-ARIA attributes to help accessible technologies more easily parse your page. 

Test!

The importance of testing cannot be overstated, especially when it comes to accessibility.  As books and articles on the topic make clear, just because something is written into the specification or guidelines does not mean it will actually work.  As Power, Freire, Petrie, & Swallow (2012) show, WCAG 2.0 is far from easy to grasp.  Moreover, several of the problems it reports do not actually affect most users with disabilities, while several real accessibility problems are not caught by it ( Power et al., 2012, p. 434).  Indeed, the testing they carried out with a group of blind users suggested that there was no significant difference between websites written to conform to WCAG 2.0 and those which were not when it came to usability for blind users (Power et al., 2012, p. 440).  Although this does not mean we can safely ignore the guidelines, it does mean we cannot simply follow them and assume our websites are accessible.

Web design in general is best approached as an iterative process, so that a website is never really ‘finished’—it’s just in its latest version.  Likewise, a successful round of accessibility testing means that your website works well in its current incarnation and on current technologies; it doesn’t mean you can then mark your website as ‘finished’ and never revisit its accessibility.  Connor (2012) suggests that, in addition to making the accessible design process iterative, designers would do well to “include user involvement as early as possible in each stage of the build” (p. 293), so that you might get feedback on your content, and then on your markup, and then on your design, and so on.

The best part about testing your website like this—whether through software like JAWS or through consultations with real users—is that you’ll get a much better sense of what people actually want to use your website for, and how your design decisions affect real world use of your site, as well as whether or not it actually works.

Conclusion: Laziness, Accessibility, and Future-Proofing the Internet

Larry Wall, author of the Perl programming language, holds that one virtue of a good programmer is laziness, or “the avoidance of future work” (Christiansen, Foy, Wall, & Orwant, 2012, p. 756).  In other words, the more work you do now, the more work you save yourself—and others—later on. 

The ever-changing nature of the Internet, computing, and assistive technologies make a strong case for applying Wall’s virtue of laziness to accessible web design.  Instead of creating more work for yourself and others by building websites that are not accessible, and that will later need updating across the board, it makes more sense to take a pro-active approach by building a site which works from the start.  Although it is of course impossible to create a truly “future-proof” website, the techniques laid out above can help make sure your website is likely to be accessible (or at least easier to modify) for the foreseeable future.  More importantly, they can make your library’s website accessible today, for users of all ability levels and devices.