Open Educational Resources

This OER guide is for EMU faculty and lecturers who want to find, adopt, adapt, or create no-cost, openly licensed course materials.

Why Accessibility Matters

Accessible OER ensures that all students—including those with disabilities—can fully use course materials.

Tips for Faculty

Structure & Text

  • Use real headings (H1 once per page; then H2 → H3). Don’t skip levels.

  • Keep paragraphs short; use lists for steps or criteria.

  • Left-align text; avoid full justification. Aim for ≥16px (≈12pt) body text and 1.4–1.6 line spacing.

  • Expand acronyms on first use (e.g., “Open Educational Resources (OER)”).Quick self-check

  • Run a page check (e.g., the LMS checker or WAVE), fix headings/alt/contrast flags.

  • Tab through the page without a mouse—can you reach everything?

  • Spot-test with a screen reader (even 1–2 minutes with VoiceOver for Macs or NVDA for Windows) to catch obvious issues.

File Size & Formats

  • Offer lightweight, mobile-friendly versions (PDF/EPUB/HTML).

  • Compress large images/video where feasible; note approximate file sizes next to links.

Keyboard & Focus

  • You should be able to complete all tasks using only the keyboard.

  • Ensure the tab order follows the visual order and that focus is clearly visible at every step.

Interactive Content (quizzes, H5P, embeds)

  • Choose content types marked accessible and test with keyboard only (Tab/Shift+Tab/Enter/Space).

  • Ensure visible focus outlines and adequate contrast for controls.

  • Provide an alternative path (e.g., downloadable worksheet) if an interaction isn’t fully accessible.

Documents & Files

  • Whenever possible, present content as an HTML page in the LMS.

  • If sharing files, provide accessible versions: tagged PDF + DOCX/EPUB.

  • Word/PowerPoint: use built-in styles, slide titles, and check reading order before exporting to tagged PDF.

  • OCR any scanned PDFs and verify selectable text and logical reading order.

Math, Chemistry, and Code

  • Prefer accessible formats (MathML or LaTeX rendered by MathJax); avoid screenshots of equations.

  • If you must use an image, include alt text that conveys the expression (or provide a nearby textual equivalent).

  • Ensure code blocks have semantic <code>/<pre> markup and sufficient contrast.

Tables & Data

  • Use tables only for data (not layout).

  • Mark header cells and set scope (scope="col"/scope="row"); avoid merged/split cells where possible.

  • Provide a brief caption/summary and consider a CSV/Excel download for large datasets.

Video & Audio

  • Provide captions for video and transcripts for audio.

  • If visuals convey information not spoken, add audio description or include the info in surrounding text.

  • No autoplay; ensure users can control playback.

 

Color & Contrast

  • Maintain contrast ratios: normal text ≥4.5:1; large text (18pt/14pt bold) ≥3:1.

  • Don’t use color alone to convey meaning; pair color with labels, patterns, or icons.

  • Avoid placing text directly over images; use a solid or semi-opaque background.

Images & Figures

  • Write concise, purpose-driven alt text (usually ≤125 characters).
    Example: “Bar chart showing 2019–2024 enrollment rising from 2,100 to 3,400.”

  • Decorative images: set empty alt (alt="") so screen readers skip them.

  • Complex visuals (charts, infographics): add a short caption plus a longer description or linked data table.

  • Avoid text baked into images; provide the text in HTML.

Links & Buttons

  • Make link text descriptive: “Download Chapter 3 (PDF)” not “click here.”

  • Don’t rely on color alone—keep the underline or another non-color cue.

  • If a link opens a new tab/window, say so: “(opens in a new window).”

  • For actions inside pages (e.g., “Submit,” “Start quiz”), use buttons—not bare links.

Tips gathered from W3C: How to Meet WCAG (Quick Reference)the authoritative checklist for WCAG 2.2.