Drupal Accessibility Guide

There are digital accessibility features built-in to Drupal for creating and/or editing webpages. These features make accessibility easier to achieve. In layout builder the accessibility for color contrast and font selection have been taken care. On this page you will find guidelines for best practices, as well as highlights to some of the important features you can use within our Drupal implementation.

Learning the Basics

If you are a complete newcomer to web accessibility, there is a BuckeyeLearn Course, "Authoring Accessible Web Content", that covers many of the basics of the topic, and ETS highly recommends using it as a place to start your learning. BuckeyeLearn offers many courses on accessibility on various topics, and can be a great resource for you as you expand your knowledge.

For some more targeted information, the W3 Consortium Web Accessibility Initiative has excellent tutorials on their website for various topics:

Editora11y Accessibility Checker

One of the most powerful items provided in your accessibility toolbox, Editora11y is an accessibility checker specific to Drupal, created by Princeton that ETS has built-in to the interface of all ETS maintained sites. When creating a new page or editing an existing page, look for the Editora11y icon/panel in the lower right-hand corner

What does Editora11y check for?

Alternative Text

  • Do all images have alt text?
  • Redundant alt text
  • Images in links with alt text that appears to be describing the image instead of the link destination

Meaningful Links

  • Links with no text
  • Links titled with a filename
  • Links with URL text
  • Links with generic text: “click here,” “learn more,” “download,” etc.
  • Links that open in a new window without warning

Document Outline and Structure

  • Skipped heading levels
  • Empty headings
  • Table structure
  • Suspicious content structure that may need to be a list
  • Etc. 

General QA

  • Text in ALL CAPS
  • Embedded content (videos, audio, etc.)
  • Links to PDFs and other documents, reminding the user to test the download for accessibility or provide an alternate, accessible format

How to use Editora11y

Editora11y accessibility icons

  • If a page passes accessibility, the blue circular icon with a check will appear by itself. No further action is needed.
  • If a page requires manual checks, the a yellow circle icon will be visible with the number of manual checks required.
  • If a page has more severe issues, the red circle icon will be visible with the number of issues that need addressed.

 

A blue circle with a checkmark, a yellow circle with a number 1, and a red outlined circle with a red number 6

To address accessibility issues, click on the checks or issues icon and follow the prompts to correct any issues.

Accessibility checker window, showing one issue detected.

Editoria11y will provide you with guidance on how to address any issues it finds.

showing what an error message looks like in the drupal accessibility checker. This specific example shows to check link u r l

While Editora11y can catch some accessibility issues, it is not perfect and doesn’t catch everything, but it’s a great start to creating accessible content.

Marking things as "OK"

Many checks in Editoria11y will be so-called "Manual Checks". These are cases where the automatic checks want you as the content creator to verify that something is being handled in an accessible and compliant way. Accessibility is nuanced and can be highly situational, so these manual checks are important for you to take seriously. Editoria11y will do it's best to advise what to check and make sure you consider. Below are some of the most common manual checks:

  • Verifying a document you link to is accessible.
  • Verifying that a decorative Image is being used correctly - that it is not needed to understand content or links, or that if it relates information, the information is provided in the text.
  • Verifying header levels - Editoria11y builds out an outline of the page (see Advanced Features), and tries to make sure that the outline makes sense, and that pseudo-headers aren't being used.
  • Verifying lists - Editoria11y tries to guess if you meant to do something as a list and calls it out. Often this is lines that begin with a number.
    • You should always use actual lists if you are listing items.
    • Note that CoE sites do support the "reversed", "type", and "start" attributes on ordered lists, but they must be added in the source code of your rich text editor. 
  • See the Links section below for help on warnings about links. 

If you are sure that you are being compliant, you can mark a check as "OK", and Editoria11y will not bring it up again unless something in the part in question changes.

If you have any questions about Editoria11y, its use, or what it is telling you, please open a support ticket to Web Services directly via the ETS portal, or by contacting the ETS Service Desk using the contact information in the sidebar or footer.

Page and Content

Heading and Paragraph Structure

Heading structure and semantics are key to having an accessible webpage.

Screen reader users can search pages by heading structure (H1, H2, H3, etc.) to help them navigate a webpage. Having correct heading structure is critical to content layout. Think of it as the table of contents for your page, and screen readers will use it for navigating your content.

Drupal allows the ability to select heading and paragraph structure in the “Paragraph Format” dropdown. The page title will always be a Heading 1, any headings thereafter should follow Heading 2, Heading 3, etc.

There are six heading levels and they should always be used in the proper order. 

  • Heading 1 (H1) is always the page title. It will always be present, even if removed visually.
  • Heading 2 (H2) should be headings for the main sections on a page. Any Custom Block Title placed in Layout has this level. 
  • Heading 3 (H3) should be headings for subsections within an H2 section.
  • Heading 4 (H4) should be headings for subsections within an H3 section.
  • Heading 5 (H5) should be headings for subsections within an H4 section.
  • Heading 6 (H6) should be headings for subsections within an H5 section.

Try to keep heading levels in order (e.g. starting content with an H2 and moving to an H3 and so on). Skipping heading levels is not a best practice and will throw a warning in Editora11y (e.g. starting your content with a Heading 3, or going from a Heading 2 to a Heading 5). If you are in doubt as to what your heading structure is, Editoria11y can give you a page outline by clicking on its bubble to bring it up, then selecting the "Outline" tab in the control box.

A page outline in the accessibility checker.

 

Absolutely avoid creating your own pseudo-headings using text sizes, bolding, text color, etc. However, you can apply text styles to properly marked-up headings. Paragraph/Body text should be formatted as “normal.”

Please note that most Custom Blocks will add in a Heading 2 of their block title, even if the title is not displayed. If this warning is received in Editora11y, it is okay to manually mark this "OK for all users."


Tables

Tables are useful for presenting information and data, but care should be taken to make sure you follow best practices. 

Tables are for data, not structure

One key thing to remember is that tables should never be used for structure, or simply to section off separate parts of content. Tables were designed to present information and data, and when interpreted by the browser they are treated as such.

Table accessibility is a big topic

The topic of creating accessible tables is nuanced and extensive, beyond the scope of this document, and for simple tables not necessarily needed. If you have a complex table to implement, please reference the Web Accessibility Initiative Tables Tutorial


Links

When creating links, there are things you can do to make sure your link meets accessibility best practices.

Link Text

Informative link text is important, as many screen reader users navigate a page via links. So instead of "Click here" or "Read More", Consider "Click here to learn about X" or "Read more about Y". If you want to keep the short link text but want to be accessible, you can leverage the ARIA-label to provide more accessible text (see below). Use of ARIA-label is also your best tool for links that are around an image.

URLs as link text

It is considered best practice to not use a URL as the text of a link, unless you are trying to communicate what that URL is. If you are trying to communicate that information, you should leave off the protocol prefix (e.g. "https://") for websites in the link text.

Opening links in new tabs/windows

As you build out content, you may be inclined to have a link open in a new window. While this can be useful in many scenarios it is disorienting for visitors using assistive technology, such as screen readers, who often use the browser "back" button to try and return to the previous page only to find its behavior not working as expected. In general, have links open the the same tab/window. If there is a need for a link to open in a new window, make sure you indicate it, either in the link text or in the aria-label (see below).

ARIA-Label attribute

Throughout ETS managed Drupal websites, we provide an interface for specifying link properties and attributes. One of these attributes that is often overlooked is the "ARIA Label", a normally invisible but powerful element for links when considering accessibility. In short, ARIA Label lets you provide different link text than what is displayed. This label can include context such as, "My Awesome Website (opens in a new tab)" to warn of a link opening in a new tab; "My presentation poster (opens image)" to warn of an image which won't be interactable opening, or anything different from what you want to have displayed as the normal link text that may not be needed in the normal link text, but enhances links for visitors using screen readers. 

The ARIA-label can also be used to give better link text for screen readers, such as "Learn more about the awesome engineering club" when you want the visible link text to be something shorter. It is also the best way to give informative link text to a screen reader when putting a link on an image. 

Media

Images

When you create or upload images, take into consideration the role of the image, its content, and the context of how it is being used. We recommend the Web Accessibility Initiative's Images Tutorial for anyone working with images on the web. While some of its information, such as the CSS, will not be available to content creators on ETS managed sites, it is a good primer on the nuance of images in web and accessibility.

Alternative (Alt) Text

When uploading media into Drupal, you are required to enter Alternative (or Alt) text. This information is very important for screen readers, and should be filled out when appropriate. Check out our Alternative Text Guide for information on creating good Alt text for images. Alternative, or Alt, Text is text added to any images, graphs, charts, or non-text content that is read by screen readers as a hidden attribute not visible to normal visitors.

Note: Changes to alt text on the "Media" screen may not be reflected immediately in content, and you may still see a warning.

 


Documents

While Drupal websites have a lot of built-in technology to help with accessibility for their web pages, documents and uploaded files aren't part of that architecture and so need to be taken into consideration. One of the most widely circulated file types is the ubiquitous PDF, but these present a particular set of challenges for accessibility. This website does have more extensive overviews of PDF Accessibility Guidelines and Microsoft Word Accessibility Guidelines, but for our creators who are reviewing web pages, performing audits, or generating new content, PDFs need special handling.

For each document, consider the following:

Relevance: Determine if the information is needed on the website.
Accessibility: Assess whether the content is accessible, or can be made more accessible through refactoring, re-linking, or remediation.
Stakeholder Input: Consult with relevant stakeholders for their input and approval.

1. Retire:

Documents that are no longer relevant or necessary should be retired and removed from your website. However, the decision to retire a document should be made carefully and in consultation with relevant stakeholders.

2. Refactor/Re-link:

When the information within a document remains valuable but can be presented in a more accessible format, consider refactoring or re-linking to another source. This could involve creating a dedicated web page for the content, converting it into a read-only Word document, or linking to an external source where the information can be found. It's essential to ensure that the newly created content adheres to accessibility standards, and any links must be updated to reflect these changes. See Academic Papers below for specific advice in handling these.

3. Remediate:

If a PDF or other document must remain in its current format and is essential for your operations, it must be remediated to meet WCAG PDF Accessibility Guidelines. This process may involve making adjustments to text, images, and layout to ensure that the document is accessible to users with disabilities. Specialized software tools, such as Adobe Acrobat Pro or professional services, can help in this endeavor. Always remember to test the PDF's accessibility after remediation to ensure it complies with the guidelines. Ensure that any changes made align with accessibility guidelines.

Helpful Guides for remediation:

Academic Papers

As an academic institution, College websites may have many research information and articles they want to provide for visitors and colleagues. In general, best practice is to link to an original Journal website or an Article provider service, ideally a DOI, rather than hosting the PDF or other document locally. Some good options include:

OSU's office of Data Management has resources to help any faculty member with putting their research into repositories. You can find more information in their online guide. You can also contact them at datamanagement@osu.edu.

 


Multimedia

ETS Managed Drupal websites allow for both Audio and Remote Videos from Vimeo and Youtube. Please see our Creating Accessible Media guide for help making sure your media is compliant. 

Hero Banner Video Backgrounds are presented as decorative with integral pause/play controls and no audio, and so should ideally only be used for decorative purposes, or to enhance their provided information fields. 

Contact Us

Phone: (614) 688-2828

Email: etshelp@osu.edu

Virtual Helpdesk: 
  ets.osu.edu/vhd (opens Zoom)
  M-F 9:00 A.M.-12:00 P.M.
  M-F 1:00 P.M.-4:00 P.M.

Service Desk Locations:
  1012 Smith Lab
  244 Hitchcock Hall

Business Hours:
  M-F 8:00 A.M.-5:00 P.M.

View My Tickets & Requests:
  go.osu.edu/etsportal (external site)

Looking for something specific?
  
Check our Service Catalog Quick Reference Guide