5 Accessibility Tips Before Launching a Website

Lessons from an Accessibility Audit of simons-rock.edu

April 15, 2018

At Bard College at Simon’s Rock, we fixed over 70,000 accessibility issues on simons-rock.edu. And it’s still a work in progress. The compliance issues largely fell into five areas and it would have been easier to address them prior to the 2015 launch of the site. The agency that designed and developed simons-rock.edu delivered what they described as an accessible site meeting Web Content Accessibility Guidelines (WCAG) standards, but many decisions during the design and development phase led to post-launch compliance issues. Here are some notes to consider when creating accessible web content.

Higher education institutions that receive federal funding are required to adhere to WCAG AA standards according to the Section 508 guidelines. But that’s not the only reason to be accessible. We have a moral obligation to make information available to as many people as possible, especially for institutions that serve the common good. And making content accessible means that it reaches more people, more effectively.

Accessibility Checklist

Color Contrast

When designing the color palette, consider what colors have enough contrast to be paired with each other. Contemporary design style often incorporates subtle color changes and/or subtle changes in gray scale and these are often not accessible. There are few colors that can be paired with both black and white. When using color type on a colored background, the contrast options are even more limited. Also, consider contrast when using color to demarcate links and hover states. These situations are challenging as there needs to be contrast between default text, link text, hover text, and background. When designing colors and patterns, accessibility needs to be considered. The color style guide should give clear direction on how to pair colors.

CMS Functionality for HTML5 and ARIA

There is a whole system for adding ARIA attributes, semantic language to help users with screen readers understand the content. Some of these tags should be coded directly into templates such as decorative elements as well as buttons that trigger a toggle.

However, some of the ARIA attributes will need to be added on a per-page basis related to page-specific content. Tables and iFrames need descriptions; vague or repetitive link text need title tags. Consider designing for the CMS and make sure the person adding content through the CMS has a way to easily add these content specific attributes. For example, when adding a table to a page, the content editor will need to add a table description with the appropriate attribute as well as the rows and columns of data.

There may also be ARIA attributes that the CMS can be programmed to automatically add based on content added by a content editor. For example, if a link text is “Read More,” and the title is set to be something that isn’t “Read More,” then maybe the CMS automatically uses the title to generate an aria-label tag.

For users who tab through the content rather than use a mouse, make sure links and buttons have a visible decoration when focused on. I would default to setting focus style the same as hover, then adjust for the edge cases.

Tab Focus Order

Consider the focus order. Be especially mindful of hidden and revealed elements.

Semantic Headers

Make sure all pages have one and only one h1. Even better, set up heading styles so that content editors can vary size of headings and still adhere to a semantic heading structure. If an h1 has a subheading that should be visibly small, make sure there is an option for a small h2 rather than having users use an h4. H4’s should only be used as a subhead of an h3.

Tools and Notes

Learn more about code audits, view "How To Audit a Website Before It Goes Public."