Posted by on August 13, 2014 in Accessibility, CSS/HTML/JavaScript

How do you ensure accessibility on a website that is worked on by several hundred web developers?

That is the question we are continually asking ourselves and have made great steps towards answering. The approach we took was to document our core guidelines and deliver presentations and trainings to all involved. This included our small team of dedicated front-end web developers but also the dozens of back-end developer teams that also work within the front-end. This article will be the first in a series going in-depth on a variety of web accessibility practices.

Our following core guidelines, though encompassing hundreds of specific rules, have helped focus our accessibility efforts.

A website should:

  • Be Built on Semantic HTML
  • Be Keyboard Accessible
  • Utilize HTML5 Landmarks and ARIA Attributes
  • Provide Sufficient Contrast

Our internal documentation goes into detail as to why these guidelines are important and how to fulfill each requirement. For example, semantic HTML is important because it allows screen readers and browsers to properly interpret your page and helps with keyboard accessibility. Landmarks are important for they allows users with screen readers to navigate over blocks of content. Contrast is important because people need to be able to see your content!

Do our current pages meet all of these requirements? Nope. That’s why we’ve documented them so that we can provide structure to this effort and have measurable levels of success.

We have been learning a lot about accessibility during the past few months. The breadth of this topic is amazing. Lots of good people in the web community have made tremendous efforts in helping others learn. W3C’s Web Accessibility Initiative documentation and WebAIM’s explanations are definitely worth the time to study.

In my following posts, I will outline many of the rules with practical examples for each of our core guidelines. Some of the items that I’ll describe are:

  • Benefits of Semantic HTML
    Should all form elements be wrapped in a form element? Do I need to use the role attribute on HTML5 semantic elements? How do decide between these: <a> elements vs <button> elements, input[type="number"] vs input[type="text"], <img> elements vs CSS backgrounds, and more.
  • Keyboard Accessibility 101
    Should I ever use [tabindex]? Why/when? How should you handle showing hidden or dynamically loaded content? Should the focus be moved to popup menus?
  • HTML5 Landmarks
    Why I wish landmarks were available outside of screen reader software. Which landmarks should I use? How do I properly label them?

Web accessibility is the reason semantic HTML exists. Take the time to learn how to make your HTML, CSS, and JavaScript accessible. If you’re going to take the time to create an HTML page, may as well do it correctly.

About Jason Boyer

I'm a front-end web developer on Ancestry's web standards team. My team and I work closely with our UX department to create site standards for various widgets and design patterns which provide a consistent, easy-to-use experience for our users. I've been doing front-end development for over 6 years now and love improving websites through semantic markup, progressive enhancement, and responsive web design.


We really do appreciate your feedback, and ask that you please be respectful to other commenters and authors. Any abusive comments may be moderated.

Commenting is open until Wednesday, 27 August 2014