We aim to make (and keep) the site as accessible as possible, following WCAG 2.0 level AA. Audited components are tagged as such.

While accessibility can mean many things to different people, these are the primary goals:

  • HTML-first. Enhance with CSS. All core features need to work without JavaScript, but may be progressively enhanced with JavaScript. Images, JS enhancements, or even CSS styling may not be seen, so make sure things make sense without those things, so think about the underlying semantics.
  • Consider alternative means of consuming content/interaction. Don’t assume a mouse, it might be a finger, keyboard, or other types of assistive tech.
  • Alt tags, labels, placeholders, etc.
  • Use ARIA attributes as seasoning (such as aria-hidden on purely visual elements like icons, and aria-roles for specific uses).

Common Mistakes

None of the components in the library should fall into these common whoopsies, but there will be times when you use something that isn’t in the library, so keep these in mind.

  • Applying styling or functionality with :hover - don’t forget :focus and that keyboards may interact differently with certain types of markup.
  • Images without descriptive alt tags for non-visual users.
  • <a href="javascript:void();"> should be <button> - when enhancing with JavaScript, consider catching submit rather than click and keydown.
  • <button onclick="location.href = foo.html"> should be <a href="foo.html">. When enhancing link clicks, check for the use of ctrl/cmd indicating the user wants a new tab/window and your enhancement should halt.
  • Using jargon or abbreviations that not everyone may know; add an <abbr title="Description"> tag to clarify them, at least the first time on a page.
  • Decreasing contrast on hover/focus. Such an action should increase the contrast, not lower it.

WCAG 2.0 Level AA

We strive for Level AA compliance with the Web Content Accessibility Guidelines (WCAG), promoted by the W3C.

These guidelines are split into 4 principles, with guidelines for each. At a glance, these are the principles and criteria:


  • Provide text alternatives for non-text content.
  • Provide captions and other alternatives for multimedia.
  • Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
  • Make it easier for users to see and hear content.


  • Make all functionality available from a keyboard.
  • Give users enough time to read and use content.
  • Do not use content that causes seizures.
  • Help users navigate and find content.


  • Make text readable and understandable.
  • Make content appear and operate in predictable ways.
  • Help users avoid and correct mistakes.


  • Maximize compatibility with current and future user tools.

Each of these principles and guidelines have success criteria in different levels. The goal for is to achieve at least all level A and AA success criteria. We will also be able of meeting some level AAA criteria, but most of these are not as critical.

The WCAG 2.0 Quick Reference is a useful resource containing a brief summary of each success criteria, along with links for more information and examples.

Testing Accessibility

There are different tools and methods to testing for accessibility. Here’s a few.

  1. The “tab test” is simply trying to go from one place (say, the homepage) to another to accomplish a task (for example, create a new api key) with just the keyboard. Can you navigate the menu to get to a page? Does a form submit properly with the keyboard?
  2. Use a screen reader to see if a page makes sense when read aloud. Mac’s built-in VoiceOver can be enabled with the shortcut Cmd + F5.
  3. Deque’s aXe browser extension is useful for analysing a page’s accessibility. It doesn’t catch everything, but will help you find potential errors.


While not the end goal of making the site accessible, we might try to get certified by Drempelvrij or another accessibility certification so we can showcase our commitment to accessibility.