Physical library spaces are designed to comply with the Americans with Disabilities Act (ADA), hence the wide aisles, low checkout stations, and ramps. In contrast, alt tag awareness is low and web accessibility not a priority for most librarians. Yet for visually or otherwise impaired users, an improperly coded website can be like wandering into a maze and hitting a brick wall of frustration.
With accessibility in mind, I’ve been teaching myself to assess and retrofit webpages, aligning my library’s website with the W3C’s Web Content Accessibility Guidelines (WCAG), the U.S. Rehabilitation Act’s Section 508, and this WebAIM Infographic aimed at accessible design as well as code. For best practices, these are your first stops.
Design for Users
Crucially, designing with accessibility in mind makes for websites that are more usable for everyone, not just for disabled users. Questioning trendy design elements can pay off too. Do image-heavy carousels and page-spanning images really enhance UX enough to justify the space they fill and the accessibility problems they may engender?
Out-of-the-box products may come with their own access problems. WordPress themes often provide low contrast. LibGuides omits the HTML lang attribute on some templates. Developers forget alt tags and form labels. Sometimes it’s easier just to fix stuff yourself.
And I use the word “easier” advisedly. 🙂
W3C Markup Validator
First, copy and paste your webpage’s URL into the free W3C Markup Validation Service to check the HTML for conformance to W3C web standards. Optimally, your code would be up to HTML5 (and CSS3) standards. This makes for cleaner aesthetics, no deprecated elements, and fewer errors when you run accessibility evaluation tools in the next stages of this process. The Validator will tell you which lines of code need correcting, and lead you to relevant documentation. Once your code is sound (imperfections are ok), break out the WAVE tool.
Plug in a URL, and the WAVE web accessibility evaluation tool from WebAIM will scan your code, flagging errors, marking structural elements, and alerting you to potential issues. WAVE will flag link texts that say “Click here” or “More,” redundant or empty links, PDFs that may or may not be optimized for accessibility, missing alternative text and form elements, and other problems. WAVE also says what the page does right (for example, WAI-ARIA features, helpful alternative text, and the like).
Browser Developer Tools
To dig deeper into your code, I suggest using a browser developer tool (Bryan Brown wrote an excellent LITA Blog post on such tools). Google Chrome’s Accessibility Developer Tools are particularly good at auditing for color contrast and recognizable links. Add these to your browser and you can test any page for accessibility and discover exactly what could be improved. Note that these tools can be really nitpicky, and again, functionality rather than perfection is our goal.
Can you turn off the CSS and still make sense of the page design? Did nothing disappear? Can you manually resize the font to at least 150% without spectacularly messing up the design? Can you navigate using only the keyboard? Are any videos close captioned and any audio files accompanied by transcripts? Can you run pages or sections of pages through a screen reader and still make sense of the content? Try it, and congratulations! You just became a web accessibility guru.
You’re not a web developer, you say? Neither am I. But even if your job has nothing to do with digital services, librarians need to know about these technical matters so as to make the case for prioritizing web accessibility and to be able to speak the language of colleagues (often the IT department) who do engage in web development. Web accessibility builds equal access and diverse communities. These are enduring values for librarians, and why I joined the profession.
What about you? How do you “do” web accessibility?