RESEARCH SUPPORT OFFICE

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.

Websites and guides for getting started

• UW-Madison’s Digital Accessibility Fundamentals.
• Creating accessible documents in Microsoft Word guide.
• Creating accessible spreadsheets in Microsoft Excel guide.

Tools

• UW-Madison’s Make It Accessible basic checklist.
• Grackle Workspace, a free accessibility checker extension for Google Docs, Google Slides, and Google Sheets available to all at UW-Madison.
• axe DevTools – Web Accessibility Testing: browser extension available on Chrome and on Firefox.

Font choice and size

• Use sans serif fonts when you choose custom fonts. Arial and Calibri are good examples of sans serif fonts. 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. In presentations, use larger font sizes to allow visibility from a distance.
• 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.

Further reading

• UW-Madison’s Make It Accessible Text Styling guide.
• UW-Madison’s Make It Accessible Color Contrast guide.

What is alt text?

Alternative text (“alt text”) is a short written description of non-text elements. Its purpose is to communicate the “what” and the “why” of images. Adaptive technology, like screen readers, read alt text aloud to blind and low-vision users as they navigate websites. Alt text is also displayed when an image fails to load. All pictorial elements, including photographs, pictures, icons, logos, graphs, infographics, and more should have alt text.

Alt text or caption?

Alt text is not the same as a caption. Captions provide information about an image to all users; it can be read visually, and is read aloud by adaptive technology. Alt text, on the other hand, describes the contents of visual elements to users who cannot see them. Therefore, 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.

Interactive images

When using an image as an interactive “button” to link to another page, the image should have alt text that describes the destination page or action, not the visual.

For interactive visuals like mapping tools or satellite information that changes quickly, it may not be possible to make the visual totally acceptable. Make a statement somewhere on the page or linked to the page acknowledging that the page is inaccessible, explaining why it is not possible to make it so, and providing a contact for users to reach out to if they need to discuss accessibility options (for example, receiving the raw data files leading to the interactive visual).

Best practices

• When writing alt text, 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?
• Keep alt text to 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 describing, for example, a satellite image, beginning your alt text with “satellite image of” may communicate important context.

Alt text example related to SSEC work

Consider the following image:

For this post, I wrote the following alt text: “In a cornfield, Verner Suomi and four other white men in suits huddle around a large, boxy 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 three unidentified scientists stand in a cornfield with the net-flux radiometer, a boxy instrument connected to smaller electronic components with wires.” In a post about corn, I could write “Five white men stand around scientific equipment in a field of dent corn slightly taller than their heads. Tassles are visible on corn heads.” Consider the unique context that each alt text conveys, and when you might use each one.

Note on using the names of scientific instruments

When describing images of scientific instruments, such as the net-flux radiometer pictured above, context is especially important. If your intended audience has a frame of reference for what the scientific instrument is (for example, if they know what materials or components it is made of), using the exact name of the instrument could be appropriate. However, a more general audience may not glean any new information or context from hearing the name of the instrument.

A good rule of thumb is to use the exact name of the scientific instrument in the caption, and to describe the visual appearance of the instrument in the alt text.

Adding alt text in WordPress

In WordPress, alt text can be added to images in two ways.

First, you can edit an image directly in a post:

1. Click on the image.
2. Select the “edit” icon.
3. Type your alt text in the box labeled “Alternative Text”.

Alternatively, you can add alt text to images in the WordPress media library.

1. In the WordPress sidebar, navigate to the “Media” tab and click “Library”.
2. Click on the image you want to edit.
3. Type your alt text in the box labeled “Alternative Text”.

Further reading

For more information, check out the UW-Madison Make It Accessible Alternative Text page.

What are headings?

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.

Best practices

• There should always be one, and only one, level 1 heading (h1) on a page. 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 from h2 to h4, for example. 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 results in a very confusing navigational experience if you’re using a screen reader. If you want to emphasize text, consider bolding, using italics, or underlining.

Further reading

• UW-Madison’s Make It Accessible Titles and Headings guide.
• W3C’s Web Accessibility Initiative Headings guide.

Best practices

• 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, so links should be distinct from one another and provide context as to where they lead.
• 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 which describes 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.

Further reading

• UW-Madison’s Make It Accessible Links and Buttons guide.
• W3C’s Web Accessibility Initiative Link Context guide.
• WebAIM’s Links and Hypertext guide.

Best practices

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.

• Use an unordered or bulleted list to show a list of related items.
• Use a numbered list to describe steps in a process or a number of parts in a whole.
• Use the standard bullet points provided by the word processor or software you are using (e.g. circles and squares).
• Do not make nested lists. Most screen readers do not distinguish between “levels” of list indentation/nesting, so this can be confusing. Instead of using nested lists, separate long lists into smaller lists separated by headings.
• Do not create lists with only one item. Rather than using a single bullet point to emphasize a point, consider bolding it instead.
• Do not create lists manually by using the Tab key or using hyphens, numbers, or symbols as bullet points.

Further reading

• UW-Madison’s Make It Accessible Readability guide.
• Penn State’s Lists in HTML guide, with examples of what lists look like visually versus how they sound when read by a screen reader.

Best practices

Tables are invaluable means of conveying data, and are often good alternatives to inaccessible data displays like graphs. Screen readers communicate table information by reading out the column header, the row header, and then the value in the intersecting box.

• Ensure that your table has one heading row and one column header, formatted using the table formatting tools.
• Provide contextual information in the caption or alt text.
• Do not use tables to visually align or 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.
• Do not indicate table header rows and columns using font size or color alone. If you do not indicate table headers using the table formatting tools, screen readers will not read your tables properly.
• Do not merge or split cells. Screen readers have difficulty interpreting and communicating these changes. If your table has multiple header rows, merged cells, or another table embedded in it, split it into multiple, simpler tables.
• Do not leave table cells empty, especially the top-left cell.

Further reading

• UW-Madison’s Make It Accessible Table Structure guide.
• W3C’s Web Accessibility Initiative Tables tutorial.
• Creating accessible spreadsheets in Microsoft Excel guide.

Best practices

• Use direct labeling: position text labels directly next to elements (e.g. lines or bars), rather than placing labels in keys.
• Use texture, symbols, or patterning, in addition to color, to distinguish elements.
• Present information in a table in addition to graphically.
• Using whitespace between elements to help those with low vision distinguish between different elements.
• Describe the takeaways in the main text. A good fail safe is to always include the data in the graph (or at least a summary of the main takeaways) elsewhere in plain text. 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, as this would be redundant.

Further reading

• UW-Madison’s Accessible Complex Images guide.
• Harvard University’s Data Visualizations, Charts, and Graphs guide.
• Google Sheets is not usually a good tool for creating accessible graphs. However, Excel has many options for adding textures and patterns to colors.

PDFs and accessibility

PDFs are not accessible “by default”. Any PDFs that currently exist on SSEC and 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 on remediating PDFs 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.

Optical Character Recognition

Adobe Acrobat has a built-in Optical Character Recognition (OCR) tool. This allows you to change a scanned document 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.

Further reading

• UW-Madison’s Make It Accessible Document Accessibility guide.
• WebAIM’s PDF Accessibility guide.

Web documents

Generally speaking, the content outlined in each of the previous sections apply to any web document you might create. Depending on which word processor or web document editor you use, there are various services and functions that can help you make your documents more accessible.

Google Docs

• There are various practices you can use to make your Google Documents more accessible.
• In tables, Google allows you to designate a header row for tables, and you should always do this.
• Google has built-in accessibility checkers you can use to help check your work.
• There are also third-party accessibility checkers available through the Google Workspace Marketplace. For example, Accessibility Checker for Docs checks your documents against Web Content Accessibility Guidelines (WCAG).

Microsoft Word

• There are various ways to make your Microsoft Word documents more accessible.
• Microsoft has built-in accessibility checkers you can use to help check your work in Word and PowerPoint.
• For more information about creating accessible documents with Microsoft Word, see WebAIM’s Microsoft Word guides.

Further reading

• UW-Madison’s Make It Accessible Document Accessibility guide.
• Grackle Workspace, a free accessibility checker extension for Google Docs, Google Slides, and Google Sheets available to all at UW-Madison.

Accessibility tips for Google Slides and PowerPoint

Both Google Slides and PowerPoint contain functions which allow you to implement the accessibility guidelines outlined in the sections above, and you should strive to make these changes. Both Google Slides and PowerPoint have built-in accessibility checkers you can use to help check your work.

Keep in mind that slideshows need to be accessible in more than one setting: they must be accessible as a visual aid for the audience that you’re presenting them to, but also accessible as a document that people will directly engage with.

• To add alt text, right click on an image and select “alternative text” (Google Slides) or “edit alt text” (PowerPoint).
• Both slides platforms automatically format slide text as the appropriate heading. In order to keep headings consistent, make sure that you are using slide templates as intended, with a single main title slide at the start, followed by appropriate subsection slides.
• 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.
• In Google Slides, live captioning is available with some browsers.

Further reading

• UW-Madison’s Make It Accessible Document Accessibility guide.
• Grackle Workspace, a free accessibility checker extension for Google Docs, Google Slides, and Google Sheets available to all at UW-Madison.

Best practices

The best practices outlined in each of the sections above also apply to emails. In addition:

• 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.

Further reading

• UW-Madison Make It Accessible Email Accessibility guide.
• Section 508 Accessible Email Messages guide.

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 the WebAIM contrast checker tool to check).
• Avoid images with rapid flashing (>3 times per second).

Video and audio

• Ensure captions are present and 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 navigating to.

Further reading

For more guidelines, see the UW-Madison Make It Accessible Social Media Accessibility guide.