Mozilla Foundation Design

Mozilla Foundation Design

Accessibility Guidelines

Design websites for everyone

Everyone should be able to navigate, understand, and use our websites. Proper accessibility improves the user experience for everyone including people with:

  • Visual disabilities (e.g. blindness, color blindness)
  • Mobility disabilities (e.g. broken arm, muscle control, arthritis, functional movement disorders)
  • Auditory disabilities (e.g. hearing loss, auditory processing disorder)
  • Seizure risk (those with photosensitive epilepsy)
  • Cognitive and learning disabilities (e.g. dyslexia, processing disorders, impaired memory)
  • As well as people using assistive technologies, people with poor internet connections, people with environmental concerns, and more.
  • Also ensure all images are culturally and age (e.g youth) appropriate

Accessibility is a fundamental part of Mozilla’s mission to ensure the internet is "open and accessible to all" and it is one of our key Diversity, Equity & Inclusion pillars at the Mozilla Foundation.

These accessibility guidelines and resources are meant to help you ensure all our websites are designed with accessibility in mind. This list is not exhaustive. If you have any questions or would like a webpage reviewed by the Web Platforms team, please ping in #mofo-websites or #mofo-design. Also feel free to ping Kristina, Tyler, or Genevieve.


The Basics

  • Industry standards are the Web Content Accessibility Guidelines (WCAG), which is part of W3’s Web Accessibility Initiative (WAI).
  • WCAG provides a rating system ranging from the minimum acceptable Level A and the optimal Level AAA - all our sites must adhere to at least Level AA.
  • When designing, be sure to follow basic design principles to create a strong visual hierarchy using layout, font sizes, contrast, repetition, spacing, and scale. Following our [Figma Design System / Style Guide] (coming soon) will help ensure this as it has already considered and tested these factors.


Tips when creating content in a CMS

  • Add alt text for every important image: Images should have helpful and descriptive alt text for screen readers (note this will also help with SEO). If an image is only for decorative purposes, then use “alt=""” so screen readers know to ignore it.
  • Avoid embedding meaningful text in an image: Text in images cannot be read by screen readers, can't be translated to other languages, and text will be too small to read on mobile devices. It should be used very cautiously and the image cannot be the only place where the information is conveyed (i.e. it should also be explained in the caption etc).
  • Color contrast: Ensure sufficient contrast between text and its background. For example, do not use light gray text on a white background. Be sure to test the color contrast. If text must be used over an image then less busy images with sufficient color contrast with the text works best.
  • Optimize images: Make sure your images aren’t excessively large. Images should be compressed before uploading them by using tools like Tiny png, ImageOptim, or compressor.io but should still look high-quality. Examples of image sizes to aim for based on their dimensions: [need to add these]. (In the future, upload the highest quality images as possible and our CMS will serve users the size they need.)
  • Videos: Avoid autoplay in videos or animations. Provide pause/play buttons. Avoid large flashing and large panning shots. If text must be over a video then offer transcripts and captions.
  • Language local: Remove the language identifiers like /en from urls when adding a link to the site. We do not want to override the language if someone has already selected a different one.
  • Copywriting: When appreciated, use plain and accessible language that is concise.


Things to keep in mind when designing

  • Don’t use color as the only visual means of conveying information.
  • Ensure interactive elements are easy to identify by styling links and hover states differently.
  • Indicate which links are external links
  • Indicate the size of downloadable files
  • Design mobile first
  • Form / input
    • Provides a way for users to undo their action
    • Form validation should clearly indicate what needs to be fixed
  • Design with globalization / localization in mind
  • Design fallbacks that will work when JavaScript is not available or fails to load.


Tools and checkers

For engineering guidelines, please read https://wiki.mozilla.org/Accessibility/Guidelines


Resources and links to learn more