Accessibilty

Accessibility on Mozilla.org

"We are committed to an internet that includes all the peoples of the earth — where a person’s demographic characteristics do not determine their online access, opportunities, or quality of experience." – Mozilla Manifesto Addendum

People of diverse abilities can be visually impaired, hearing impaired, mobility impaired, cognitively impaired, or any permutation of diverse ability states. Not only required by regulation by many governments and other authorities, accessibility (often written “a11y”) for people of diverse abilities on Mozilla.org is one of the most visible public expressions of our Mozillian values. For many web creators, we set the example.

Many accessibility best practices — such as accessible color contrast ratios and clear page content hierarchies — are also best practices for user-centered design. While these user-centered and a11y best practices may feel constraining, one can safely assume the needs of all users are met when the needs of people of diverse abilities are met.

We’ve included guidelines and several resources here, but please reach out to the Mozilla.org team if you have any questions about web accessibility.

Overall Guidelines

Just like HTML, CSS, and other web standards, web accessibility guidelines are developed by the World Wide Web Consortium (W3C), of which Mozilla is a member. These guidelines are developed by a W3C working group called the Web Accessibility Initiative (WAI), which proposed updated accessibility guidelines in April 2018. It is highly likely that the European Union will codify these guidelines as required by law, similar to GDPR for privacy.

The W3C/WAI Web Content Accessibility Guidelines (WCAG) are generated from 4 principles:

• Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
• Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
• Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
• Operable: User interface components and navigation must be operable.

While we will outline the most important W3C a11y guidelines as it pertains to our work for Mozilla.org, they are by no means exhaustive. We recommend you read the guidelines and see our Accessibility Resource section for complete information, training, diagnostics, and assistance.

Selected specific practice guidelines based on the four principles for copy and visual design are below.

Guidelines for Copy

The WAI has provided tips for writing for accessibility, and we recommend all writers read that page. However, here's some selected guidelines to follow:

• Use the active voice. Avoid using "be" verbs in copy. This is also a best practice for usability, as it creates an economy of words and also provides clear direction for user actions and interactions.
• Avoid using interaction terms that are literal like "click" or "tap", as users of diverse abilities have diverse interaction methods based on their needs. Use terms like "choose" or "select".
• Put the most important information first. Long introductions means more work for screen readers, and oftentimes users with diverse abilities will listen to text several times.
• Write for clarity. Aim to write at an eighth grade (Age 12-14) reading level, and avoid jargon, sarcasm, idioms, or far-reaching metaphors.
• Ensure your content follows a recognizable hierarchical structure. The Mozilla.org design system should take care of this, but please let the Mozilla.org team know if you feel this structural hierarchy is missing or lacking in any way.
• Inline link text should be descriptive. Avoid phrases like 'To learn more about Mozilla, click here.', but do use phrases like 'Learn more about Mozilla. '.
• To serve all users, audiovisual content should have a transcript or captioning.

The best way to test your text for accessibility is to listen to the screen reader announce your text. You can turn your screen reader on in any of your devices' preferences. Please ask the Mozilla.org team if you need help.

Guidelines for Visual Design

TK

Alternative Text (alt text) for Images and Illustrations

The alt attribute provides a text alternative for display when an image or illustration isn’t available, and also provides text for screen readers to announce for users of diverse abilities who use them. To hear how alt text is read on a screen reader, we recommend turning on screen readers for any of your devices. Please see the Mozilla.org team for assistance.

Guidelines for Alternative Text (alt text)

• Write the alt text as if it was being read aloud, fitting in the overall text and object flow of the page. Your alt text should adhere to the Mozilla.org voice and tone guidelines as much as possible, but always put the needs of the user first.
• If your title attribute matches your alt text attribute, omit the title attribute.
• Sometimes, alt text may be redundant or otherwise unnecessary. While every image should have an alt text attribute, alt text attributes can be "empty". Please make the decision to have empty alt text attributes collaboratively with the Mozilla.org team.
• Avoid unhelpful alt texts such as “a picture of my cat”. "Cat that points to the Firefox download button" is an example of more helpful text. Think about the function of the image or what the image is demonstrating. If you conclude that the image is decoration only, please see the Mozilla.org team to discuss adding it using CSS.
• Never use the image file name as alt text: “mycat.jpg” is meaningless.
• Keep alt text to 256 characters or fewer. If you are having trouble with this, please ask the Mozilla.org team for assistance.
• For consistency, convenience, and efficiency, The Mozilla.org team has created an alternative text table for all reusable icons and pictograms.

Universal Alternative Text Table for Reusable Mozilla.org Iconography and Pictograms

**Table TK **