Skip to content

Google accessibility

For more details, see https://developers.google.com/style/accessibility

General dos and don'ts

  • Don't use ableist language. Avoid bias and harm when discussing disability and accessibility. For more information, see Writing inclusive documentation.
  • Ensure that readers can reach all parts of the document (including tabs, form-submission buttons, and interactive elements) by using only a keyboard, without a mouse or trackpad.
  • Use a screen reader to test your documentation. This test can help you find accessibility issues in your content and is a good way to self-edit your content. To try out a screen reader, see List of screen readers.
  • In HTML, use semantic tagging. For example, use the <em> element only to indicate emphasis, not to indicate italics.
  • In HTML, prefer native elements over custom styles.
  • Avoid unnecessary font formatting. (Screen readers explicitly describe text modifications.)
  • If you're documenting a product that includes specialized accessibility features, then explicitly document those features. For example, the Google Cloud CLI (gcloud CLI) includes togglable accessibility features such as percentage progress bars and ASCII box rendering.
  • Don't force line breaks (hard returns) within sentences and paragraphs. Line breaks might not work well in resized windows or with enlarged text.
  • Avoid when possible camel case and all caps. Some screen readers read capitalized letters individually, and some languages are unicase. Follow capitalization guidelines.
  • Depending on the screen reader (or personal settings), not all punctuation marks are read. Make sure that the same meaning is conveyed to the reader without punctuation marks. For that reason, avoid when possible the use of exclamation marks, question marks, and semicolons.
  • Don't use & instead of and in headings, text, navigation, or tables of contents. However, it's OK to use & when referencing UI elements that use &, or in table headings and diagram labels where space constraints require abbreviation. Of course, it's fine to use & for technical purposes in code.