Skip to Digital Accessibility at Ramapo College site navigationSkip to main content

Creating Accessible Webpages

Below are common accessibility issues and guidance on creating web content that meets WCAG 2.1 AA standards.

Headings

Use Headings in Order

Screen reader users often navigate by headings. A clear, consistent heading structure:

  • Improves usability
  • Supports assistive technology
  • Helps all users scan content more easily

Follow a clear hierarchy

Headings should reflect the logical structure of the content — like an outline.

  • Start with H1 for the main page title (only one per page)
  • Use H2 for major sections
  • Use H3 for subsections under H2
  • Use H4 for subsections under H3

Don’t skip levels

Skipping levels can confuse screen reader users who rely on heading navigation.

  • Do not jump from H2 to H4
  • Do not go from H1 directly to H3
  • Correct: H1 → H2 → H3
  • Incorrect: H1 → H3 → H2

Don’t use headings just to make text larger

  • Headings are for structure, not styling.
  • If you want bigger or bold text, use CSS styles — not heading tags.
  • Misusing headings can disrupt accessibility navigation.
Writing

Write clearly and keep content simple

Clear writing benefits users with cognitive disabilities, users reading in a non-native language, and anyone scanning content quickly.

  • Use plain language.
  • Keep paragraphs short.
  • Use bulleted or numbered lists for scannable content.
    • Use built-in list formatting tools — do not manually type dashes or numbers.
  • Avoid jargon and overly complex sentence structures.
Alt Text

Add Meaningful Alt Text for Images

Alt text ensures users who cannot see images still receive the same information using a screen reader.

  • Provide concise alt text that communicates the purpose or message of the image. (125-150 characters)
  • Do not use file names or generic descriptions.
  • If an image is purely decorative and conveys no information, leave the alt attribute empty (alt=””) so assistive technology can skip it.
PDFs on the Web

Make PDFs and Documents Accessible

Tagged PDFs allow screen readers to interpret and navigate content correctly.

  • Do not publish scanned, image-only PDFs.
  • Export documents as tagged PDFs from tools like Word or InDesign.
  • Ensure documents preserve:
    • Logical reading order
    • Proper heading structure
    • Selectable text

View more information on creating accessible PDFs >

Flyers

Flyers on Webpages

We don’t recommend placing flyers on webpages. But if the need arises, flyers and promotional graphics posted on webpages must NOT be image-only. Any information conveyed in a flyer—such as event title, date, time, location, description, and registration details—must also be provided as accessible, real text on the page or through a fully accessible alternative.

Images may be used for visual design, but they cannot be the sole way users access information. This ensures compliance with WCAG 2.1 Level AA and allows all users, including those using screen readers or text-resizing tools, to access the content.

Quick checklist for posting flyers on webpages

Before publishing, confirm:

  • The event details are written as real text on the webpage (not just in an image)
  • The flyer image is optional or supplemental, not the only source of information
  • Headings and lists are used where appropriate (for readability and screen readers)
  • The image has brief, meaningful alt text (e.g., “Event flyer for…”)
  • Any linked PDF is fully accessible (tagged, searchable text, correct reading order)
  • The page makes sense if the image does not load or cannot be seen
Videos

Provide Accurate Captions and Transcripts for Video

Captions and transcripts support users who are deaf or hard of hearing and improve overall usability.

  • All videos with spoken content must include synchronized captions.
  • Captions must be accurate and properly timed.
  • For longer media, provide a full transcript to support navigation and flexible consumption.
  • Live events must include real-time captioning when speech is present.

View more information on creating accessible videos >

Forms

Web vs. PDF Form

Web forms are more accessible, easier to maintain, and work better across devices and assistive technologies. The best practice is to, when possible, provide an accessible web form and offer an accessible PDF only as a secondary option if necessary.

When to use a Web Form (Preferred)

  • Users need to complete and submit the form online
  • The form collects structured data (applications, registrations, requests)
  • Accessibility, mobile usability, and ease of updates are priorities
  • The form will be used frequently

When to use a PDF Form

  • A downloadable/printable version is legally or operationally required
  • A signed copy must be submitted offline
  • The form must match an official printed document

If using a PDF form, it must be:

  • Tagged for accessibility
  • Fully fillable
  • Keyboard navigable
  • Not scanned or image-only

Ensure Forms Are Fully Keyboard Accessible

Keyboard accessibility is essential for users with motor disabilities and screen reader users.

  • All form elements must be operable using only the keyboard (Tab, Shift+Tab, Enter, and Space).
  • Every input field must have a clear, programmatically associated label.
  • Interactive elements must have visible focus indicators.

View more information on creating accessible forms >

Color Contrast

Maintain High Color Contrast

Adequate contrast supports users with low vision, color blindness, and users viewing screens in bright environments.

Our website theme and CSS already use accessible, high-contrast brand colors. If you use the default WordPress styles, buttons, and text options, you don’t need to worry about contrast compliance.

That said, it’s still helpful to understand color accessibility—particularly if you’re adding custom graphics, colored text, or special design elements.

Tables

Use tables only for data, not layout

Screen readers rely on header associations to interpret data correctly.

  • Use tables only for data, not layout.
  • Include header rows (and header columns where appropriate).
  • Avoid merged/split cells when possible.
  • Provide captions if the table needs explanation

View a Tables Tutorial (W3C.org) >

Example. Table with data

<table width=”100%”><caption>Projects Report 2024</caption>
<thead>
<tr>
<th scope=”col”>PROJECT</th>
<th scope=”col”>CORE</th>
<th scope=”col”>STATUS</th>
</tr>
</thead>
<tbody>
<tr>
<th style=”text-align: center;” scope=”row”>Digital Accessibility</th>
<td style=”text-align: center;”>All</td>
<td style=”text-align: center;”>Ongoing</td>
</tr>
</tbody>
</table>

 

Projects Report 2024
PROJECT CORE STATUS
Digital Accessibility All Ongoing
Avoid Auto-Play

Avoid Auto-Playing Media

Unexpected audio interferes with screen readers and can be disorienting.

  • Do not autoplay audio or video.
  • Provide controls to pause, stop, or adjust volume.
Ramapo

Digital Accessibility Skill-Building

By File Type

icons filetype - webpage, document, video, email

By Role

icons role - writer, instructor, designer, developer, manager

Self-Paced Training

icon self paced training

Live Training

icon live training