Half way into building the new Healthcare.gov, a site to help Americans learn about and find affordable health insurance, we want to update you on an important aspect of designing a government website. Especially given the content of this site is about access to health care, it’s incredibly important that it be accessible to all people.

Section 508 is a legal requirement that federal government websites have certain features to help people with disabilities understand them, sometimes while using assistive technology like screen readers.

We’ve been focusing on 508 testing and compliance from the start. With each code sprint, we’re reviewing and addressing accessibility issues as the come up. This process is not native to developing a static website, but it’s easy to do, because we’re working with such a flexible and simple architecture. There is no rooting around modules and multiple layers of themes to find erroneous markup.

Accessibility as guidelines and law

Providing persons with disabilities access to content on the web or within an application is many times glossed over by developers and designers. A number of organizations and governing bodies, including the U.S. government, have created guidelines and standards in an effort to help ensure that nobody is discriminated when trying to access content on the web.

Section 508 is one standard that is U.S. law and guides much of the public sector content on the web. The World Wide Web Consortium (W3C) is another body that has developed guidelines for web content accessibility, which corresponds to much of what Section 508 states. While slight differences exist, overall any guideline states that accessible web content include: text alternatives, keyboard-navigable layouts, meaningful page titles, logical header and sub header progression, and readable content.

In general this is a matter of applying standard HTML syntax — include alt tags, make sure your page is structured, and make sure you label elements.

But as Austin Seraphin writes, in a powerful blog post, “The blind have gotten so used to lofty promises of a dream platform, only to receive some slapped together set of software with a minimally functional screen reader running on overpriced hardware which can’t take a beating.”

Auditing ourselves

Our first review using several in-browser accessibility tools, including WAVE from WebAIM, revealed that our initial site development had several issues. We had over 24 accessibility violations and 12 warnings. Most of the errors were due to missing alt text or unlabeled form elements. The warnings mostly dealt with dropdown menus, header items, and javascript interactions — items that some screen readers and accessibility software can't handle.

Take for example a search form element at the top of your page. A quick implementation would look something like this:

`<form>
	<input id='footer-email' type='text' placeholder='Email Address' />
</form>`

This is one of the most common errors when trying to provide accessible content. A visually-impaired person using a screen-reader will not be able to understand this element because it lacks not only a label element attached to the form element, there is not a title to the form element.

To fix it, a label and/or title can be added as for descriptions of the elements.

`<form>
	<label for='footer-email'>Get Email Updates</label>
	<input title='Email Signup Text Box' id='footer-email' type='text' placeholder='Email Address' />
</form>`

Putting a focus on accessibility through simplicity

As we’ve discussed before, going back to the basics and using static site development can help improve accessibility. Our initial audit was the first step in reviewing how we can make the new Healthcare.gov 100% accessible regardless of disability.

Ensuring accessibility can be difficult. A number of considerations must be integrated during original development to ensure that standards are met.

Many times, large CMS-driven sites miss the mark. I audited several large government sites and have consistently found anything from 1 to 16 errors. In general, the most common offense is missing alt text or label for a form. But poor structure, confusing titles, or poor text contrast are also very common warnings that are not necessarily in violation of compliance but decrease access to certain users.

Managing these issues up front and with the simplicity of site templating features from Jekyll, we’re seeing how easy it can be to make sure that the new Healthcare.gov is 100% accessible.

Next up

Later this week, we’ll dive into another topic about access to content: how to set up a multi-lingual Jekyll site.