Best Practices

Making your Work Accessible

Web accessibility means that people with disabilities can use the Web. More specifically, it means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.  Web accessibility also benefits others, including older people with changing abilities due to aging (from Web Accessibility Initiative).  Implementing accessible design standards will often improve the experience of everyone using your site.

The post below outlines what you should do to improve accessibility on your own Course, Project, Club, and Portfolio sites.  You can find out more information about accessibility, and improvements the OpenLab has been making, in our post on Summary of Accessibility on the OpenLab.  CUNY’s site on accessibility standards also has helpful information on making digital content accessible.


It is important that documents, such as PDF and Microsoft Word files, that you upload to the OpenLab, are accessible.  These  include documents on a Site, or in the Files section of a Course, Project, or Club Profile.  CUNY’s guide to creating accessible PDF and Microsoft Office documents provides detailed instructions for how to do this, but a few key points are emphasized below.

  1. PDF files are the most difficult file format to make accessible, and properly-structured HTML tends to be the most accessible.
    • Use or link to a PDF only when you cannot use HTML or Microsoft Office files.
    • Ensuring searchable text and tagging a PDF with hidden labels (tags) that describe the structure of the document are the minimum requirements for PDF document accessibility, in order to be correctly read by a screen reader.
  2. If it is necessary to use a PDF, please follow CUNY’s guidelines for:


It is important that PowerPoint and other slideshow documents you include on the OpenLab are accessible.  These include documents on a Site, or in the Files section of a Course, Project, or Club Profile. CUNY’s guide to creating an accessible PowerPoint provides detailed instructions for how to do this.  More specifically for faculty, using PowerPoint to live caption lectures walks you through how to live caption your PowerPoint lectures so students can read along.


  1. Include alternative text for all images.  Whenever you add a new image to a Post or Page using the Classic editor, include short text in the Alt Text field in the Insert Media pop-up box (shown in the screenshot below). In the Block editor, when you add a new image or select an image block, include short text in the Alt Text field in the block settings sidebar panel. (Both editors shown in screenshots below.)
    • Do not include the words “photo of” or “image of” because the screen reader will already signal that it is an image file. Keep the description short and informative.
    • For images that represent concepts and information, such as photos and illustrations, include alt text that briefly conveys the essential information presented by the image. For more on alt text for different types of images, see CUNY’s guide to image accessibility.
    • Rationale: Alternative text, or “alt text” for short, refers to a short description for images that will be read aloud by screen readers, and is required for accessibility.
  2. Remove any text in the Title field.
    • Rationale: WordPress automatically creates an image title that is the same as the image file name. Usually this results in a meaningless title, such as “IMG_5981.” Titles are optional and some browsers  or devices may not support them, so it is better to include only alt text and avoid the screen reader either missing the title or reading the same information twice.
  3. Prevent images from opening in their own tab after being clicked, by selecting none in the Link To dropdown menu.
    • Rationale: Images will not have any alt text or other accessibility controls when they open in the new window.
Screenshot showing title, alt text, and link to settings.
Classic editor
Where to add alt text in the block settings panel.
Block editor

Video and Animation

  1. Do not autoplay video and animated gifs with flashing visual content.
    • Rationale: People using screen readers may have difficulty hearing the reader’s output if other audio is playing at the same time.
    • Rationale: Quickly blinking or flashing images  can trigger seizures in people with certain types of seizure disorders.
    • Rationale: Animations can be disorienting to many people, especially those with certain types of cognitive disorders.
  2. Include captions for video.  Captions provide text versions of the words spoken in a video.  It is essential for people who cannot hear the audio, and can be helpful for all users of your site, including people not fluent in the language used in the video/audio, or people who are working in a quiet space.

Site Organization

  1. Use informative and specific wording for the text that the user will click on, to describe where the link will take them.  For example, if you are linking to an accessibility article, use descriptive text such as “Article on Accessibility.”
    • Avoid vague phrases like “Click here.”
    • Avoid using the word “link” because screen readers will already alert the user that the text is a link.
    • Avoid using URLs in the link text, because they are cumbersome when read aloud.  E.g. Use “W3C Tutorial on Functional Images” rather than “”.
    • Rationale: If someone is using a screen reader, which will read the links out loud, the user will be able to know where a link will take them before clicking.
Headings and Fonts
  1. Organize content in a Post or Page using Headings to structure the information you present to create a clear visual hierarchy.
    • Rationale: using a logical structure will benefit everyone who visits your site. The information is easier to scan for sighted users. People using screen readers can use headings to navigate among the different sections.
  2. In the Classic editor, use the Heading styles in the Post or Page editor dropdown, rather than bold or italics to indicate a heading. In the Block editor, use the Heading block, rather than bold or italics in a Paragraph block to indicate a heading. (See screenshots below.)
    • The Heading 1 style should only be used once per page. Don’t use Heading 2 styles too often; they should be reserved just for sub-section titles.
  3. Use common, recognizable fonts that provide a strong contrast with the background color of the page.  This will not be an issue for most OpenLab members if you stick to the default fonts and colors for your theme.  However, if you’re using one of our font plugins, such as Easy Google Fonts, or changing the text or background colors, you can find more information about contrast in WebAim: Visual Disabilities: High Contrast.
    • Avoid using colors that create a low contrast; for example, light color fonts on a white background.
    • Avoid script fonts, which can be difficult to read for everyone; and especially people with visual impairments.
    • Try viewing your site while zoomed in, which is a common practice to increase readability.  You can do this by pressing the ctrl and + keys together, or command + on a Mac.
Screenshot showing heading styles
Classic editor
Block editor heading block.
Block editor

It’s best to avoid using tables to display information if they’re not necessary. Tables may not display well on mobile, especially if the cells contain a lot of text. While tables in WordPress have some accessibility options, such as defining a header row, there are some table accessibility functions that aren’t possible without editing the HTML, such as tables with two headers.

If it is necessary to use a table, be sure to indicate which row is a header row, if applicable. This is required for screen readers to navigate the table correctly. 

You can add this in the settings for the table block in the post or page editor. You can also add a caption for the table.

Adding a header section for a table

Additional Resources

Below are some more helpful resources on how to make your site more accessible: