RESEARCH SUPPORT OFFICE

Font choice and size:

• Use sans serif fonts when you choose custom fonts — Arial and Calibri are examples. Using the default font is often preferable.
• Keep text size large. “Point” is not a standard measurement of size and can vary by font, so use good judgment. Usually, 12 is a good minimum point size.
• Don’t mix and match fonts too much, as this can be hard to read. Use a maximum of three fonts, and preferably fewer.
• Avoid all caps text. When all of the letters are the same height, it can be harder to distinguish them.

Color and contrast:

• When possible, keep body text the default dark color (black or dark gray) on light backgrounds.
• If choosing other text or background colors, ensure that they meet the 4.5:1 contrast ratio requirement using the Accessible Web or WebAIM contrast checkers.

Alternative text (“alt text”) describes non-text elements like photos, icons, logos, and illustrations so screen readers can convey them to blind and low-vision users. People whose internet connections may not load an image may also read the alt text to understand what is being shown. Photographs, pictures, icons, logos, and any pictorial elements should have alt text.

Alt text is not the same thing as a caption. Screen readers read out captions, so alt text should communicate information that is only available in the image so as to not create a repetitive experience for people using screen readers. When writing alt text, try to think about what the purpose of your image is — why is it here, and what information does it offer that would be helpful for someone who can’t see it?

Best practices to follow:

• Keep alt text 150 characters or fewer to avoid overwhelming users with screen readers.
• Don’t start alt text with “image of,” “photograph of,” or “screenshot of” unless that detail is essential. Screen readers inform users that they are reading alt text for an image before doing so, and low-vision users or those with poor internet connections can often tell that they are looking at an image, so this information is redundant. However, if showing, for example, a satellite image, starting with “satellite image” may communicate important context.
• Images used as links should have alt text that describes the destination page or action, not the visual. For example, alt text might say “Geostationary satellites page” if it is attached to an image leading to that page.

For an example of alt text, consider the following image:

For this post, I wrote the following alt text: “Verner Suomi and four other white men in suits stand in a cornfield around a scientific instrument.” However, many other contexts are possible. In a post about Verner Suomi’s scientific accomplishments, I might say “Verner Suomi, Robert Parent, and other scientists stand with the net-flux radiometer in a cornfield.” In a post about corn, maybe I would write “Five white men with scientific equipment stand in a field of dent corn slightly taller than their heads. Tassles are visible on corn heads.” Consider what each alt text conveys, and when you might use each one.

In WordPress, add alt text to images either by selecting the image and then “edit” or by navigating to the WordPress media library and adding the alt text to the box labeled “alternative text”.

For more information, check out the UW “Make it Accessible” Alternative Text page.

Headings are used to organize information on a page. There are six levels of heading. These are hard-coded into the HTML of a page, and screen reader users can skip from one heading to the next of the same or different levels in order to more efficiently find information on a page. For this reason, it is important to follow best practices:

• There should always be one level 1 heading (h1) on a page (and only one). In our WordPress theme, this is actually the name of the entire site, so no individual page should have an h1.
• If you use additional levels (h2, h3, etc.), use them in order – don’t skip. In our WordPress theme, the page title (not the site title) is automatically an h2, so there should be no other h2s on the page — any additional headings should start with h3 (if you need another h2, that should be a separate page, organizationally).
• Headings should not be used for styling, as this is very confusing if you’re using a screen reader. Image if you were trying to go through section headings to find the “methods” section of an article, and for some reason you had to hear someone read out any emphasized text in a section first. If you want to emphasize text, consider bolding.

Best practices to follow when inserting links on pages:

• Do not leave bare links (ex: https://www.library.wisc.edu/). A screen reader will read this out letter by letter. Instead, link text should describe the link (ex: library homepage). 
• Avoid making link text things like “here” or “click here” (ex. click here for the library website). Some screen readers can jump from link to link for users looking for a particular link, and so links should be distinct from one another without context.
• Links should be differentiated from other text in ways beyond just color – for example, with underlining. The default link formatting on most sites (including WordPress) should really just be left as is.
• Images should not have unlabelled links attached to them. If you are attaching a link to an image, make sure to give the image alt text describing where the link will take the user. There is no need to say “link” in the alt text —  a screen reader will inform the user that it is a link.

Lists are a great way to improve the usability and accessibility of a site by making information clear and organized. However, there are a few best practices to follow to maintain accessibility:

• If using unordered lists (like this one), do not make nested lists. Some screen readers do not distinguish between “levels” of list indentation/nesting, so this can be confusing. This can be acceptable if the list is ordered (has numbers instead of bullet points), as users with screen readers will be able to hear the letter before the nested line and understand its ordering.
  • This is a nested bullet point.

Tables are invaluable means of conveying data, and are often good alternatives for inaccessible data displays like graphs. However, this means that tables should only be used to display data that can actually be described by a table — do not use tables to arrange elements on a page, such as to make an image sit next to a block of text. There are WordPress block elements specifically designed to do this, such as the “row” block or the “column” block.

Screen readers communicate table information by reading out the column header, the row header, and then the value in the intersecting box. Because of this, it is important to make sure any table has the following characteristics:

• It has a heading row and column to label values. Screen readers will read off the heading for each before reading the values sequentially.
• No cells are combined or split to show multiple values. Screen readers may have difficulty interpreting and communicating these.

This also helps with general table hygiene and clarity.

When possible, make graphs more accessible by:

• Labelling near elements, not using keys.
• Using texture, symbols, or patterning, in addition to color, to distinguish elements.
• Presenting information in a table in addition to graphically.
• Using whitespace between elements to help those with low vision distinguish elements.
• Describing the takeaways in the main text.

You don’t need to use all of these techniques in every single graph! A good fail safe is to always include the data in the graph (or at least a summary of the main takeaways) textually elsewhere.

If the information in the graph is conveyed in detail elsewhere in your text, you do not need to give your graph an alt text — this would be redundant.

Google Sheets is not usually a good tool for creating accessible graphs. However, Excel has many options for adding textures and patterns to colors.

Harvard’s accessible graphs guide is also a great tool.

PDFs are not accessible “by default” – any PDFs that currently exist on SSEC/CIMSS sites are unlikely to be accessible. Adobe Acrobat cannot automatically recognize and differentiate between headings, body copy, tables, etc., which leads to the difficulties with PDF accessibility.

Microsoft Word’s accessibility checker is a simple way to check a document before turning it into a PDF. Old PDFs can also be converted to Word Docs, edited, then re-converted to PDF. If you go this route, you should still run basic accessibility checks on the PDF once it is converted.

If you need to make a PDF accessible, you can remediate it. PDF remediation is a lengthy process — if you expect to have to do it more than once, it is worthwhile to go through the Section 508 videos and learn how to do it. If you don’t expect to remediate more than one PDF, though, it might make more sense to try to convert the document to an accessible Word document or HTML.

Adobe Acrobat has a built-in Optical Character Recognition (OCR) tool. This allows you to change a scanned document or an image into a digital file. You can then save it as a text document and search, save, and edit all the text in the image. OCR is an automatic and simple-to-use function in Adobe Acrobat — just click on the “edit” button in the left-hand toolbar. OCR provides better access to PDFs for blind and visually impaired users because it enables them to read PDFs with a screen reader. Once you have performed OCR on a PDF, you will likely still need to remediate the PDF in order to make sure it recognizes headers, tables, etc.

Adobe Acrobat also has a built-in accessibility checker.

Generally speaking, all of the criteria above apply to any web document you might create.

In Google Docs, there are various practices you can use to make your documents accessible. In documents, Google allows you to designate a header row for tables, and you should always do this.

Both Google and Microsoft have built-in accessibility checkers you can use to help check your work.

Both Google Slides and PowerPoint allow for the accessibility guidelines listed above, and you should strive to make these changes.

To add alt text in Google Slides or PowerPoint, right click on the image and select “alternative text” (Google Slides) or “edit alt text” (PowerPoint).

Both slides platforms automatically make heading slide text into the appropriate heading, so in order to keep headings consistent, make sure that you are using slide templates as intended, with a title slide at the start (and only used once), and appropriate subsection headings for subsections, etc.

In PowerPoint, you can make sure that tables have a header row by checking the “header row” box in the upper toolbar while the table is selected. Google Slides does not allow for table headers, so if your presentation requires tables, choose PowerPoint over Google Slides.

If presenting data in graphs, make sure to follow the accessibility tips for the graphs, and also to put the data presented in the graph elsewhere in text or in a table. If the data is too long or complex to be written out in full, provide a textual summary somewhere on the slide.

Both Google Slides and PowerPoint have built-in accessibility checkers you can use to help check your work.

In Google Slides, live captioning is available with some browsers.

All of the above best practices also apply to emails. Here are some Outlook-specific tips:

• In order to add headings to emails, open your email, select the body area, and then navigate to “format text” in the upper toolbar. From there, choose the “text styles” button (an “A” with a pencil).
• You can run accessibility checks in Outlook prior to sending emails. Do this by choosing the “more” (an ellipsis) option in the upper toolbar, then “check accessibility”.
• Make sure to add alt text to any images included in the body of your email (including any logos or images in your signature). This can be done by right-clicking on the image.
• Include a subject that is brief but contains useful keywords about the contents of the email. This helps both with accessibility and with searchability for anyone who might want to find your email in the future.

More information can be found on the Section 508 webpage.

Images: 

• Add clear, descriptive alt text (what’s happening, who’s in it, key context).
• Tip: Some platforms don’t support alt text (Instagram Stories, for example). If that is the case, you should add image descriptions in image captions.
• Avoid excessive text on graphics; if needed, repeat it in the caption or alt text.
• Ensure color contrast meets accessibility guidelines (use this tool to check).
• Avoid images with rapid flashing (>3 times per second).

Video and audio: 

• Ensure captions are accurate — review auto‑captions before posting.
• Include transcripts for longer audio or video content.
• Use plain, concise language.
• If using hashtags, use UpperCamelCase (also known as TitleCase or PascalCase) for multiword hashtags (for example: #DisabilityAdvocacy).
• Minimize emoji use; if using, place them at the end of sentences.
• If the platform allows you to hyperlink text, use descriptive text so that a screen reader user gets an accurate idea about the destination or purpose of the link they’re clicking.

For more guidelines, see Social Media Accessibility page.

How does WordPress support accessibility?

• WordPress does most of the work for you — it makes managing accessible web content easier.
• The SSEC Communications Team strongly recommends migrating your websites to WordPress — there are other benefits besides accessibility.

Tools to use

• Browser extension: axe DevTools – Web Accessibility Testing available on Chrome and on Firefox.
• UW’s Make It Accessible basic checklist.