Accessibility in EdTech: Building Software Every Student Can Use

Trust me, nobody sets out to build an EdTech platform that excludes students with disabilities. But I've audited enough educational software to know that it happens constantly — and usually not because anyone made a malicious decision. It happens because accessibility gets treated as a "nice to have" that'll get addressed in "the next sprint." Then the next sprint comes, and there's a new feature to ship.

Here's the thing: roughly 15% of K-12 students receive special education services. In higher ed, the number of students with registered disabilities has been climbing every year. If your platform doesn't work for these students, you're not just failing a compliance requirement — you're failing actual kids who deserve the same educational opportunities as their peers.

Let me walk you through what accessibility looks like in practice for EdTech software, from WCAG requirements to code-level implementation.

Why This Isn't Optional

Before we get into the technical details, let's talk about the legal and business reality.

Legal Requirements

Section 508 of the Rehabilitation Act requires that all electronic technology developed, procured, or used by federal agencies — including federally funded schools — be accessible to people with disabilities.
ADA Title II applies to public schools and universities. Courts have consistently interpreted this to include digital platforms.
ADA Title III applies to private institutions that are "places of public accommodation." Multiple lawsuits have confirmed that websites and applications qualify.
State laws are increasingly specific. California, New York, and several other states have enacted digital accessibility requirements for educational institutions.

The practical result: if you're selling EdTech software to schools, districts, or universities, accessibility compliance will appear in your RFP requirements. It's not a differentiator — it's table stakes.

The Business Case

Beyond legal compliance, accessible software is better software for everyone:

Keyboard navigation benefits power users who are faster with keyboards than mice
High contrast modes help students using the platform in bright classrooms or on low-quality displays
Clear visual hierarchy improves comprehension for all users, not just those with cognitive disabilities
Captions and transcripts help ESL students and anyone learning in a noisy environment
Structured content improves SEO and platform searchability

I've seen this play out repeatedly: when we build for accessibility first, the entire user experience improves.

WCAG 2.1 AA: The Standard You Need to Meet

WCAG (Web Content Accessibility Guidelines) 2.1 at the AA conformance level is the standard most educational institutions require. It's organized around four principles — Perceivable, Operable, Understandable, and Robust (POUR).

Here's what each principle means for EdTech software specifically.

Perceivable: Students Can See and Hear Content

Color Contrast (Success Criterion 1.4.3)

All text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text, defined as 18pt or 14pt bold).

This one trips up more EdTech platforms than you'd think. That light gray placeholder text on a white input field? Fails. Your branded blue text on a dark blue hero section? Probably fails.

/* Failing: 2.8:1 contrast ratio */
.lesson-subtitle {
  color: #767676;
  background-color: #ffffff;
}

/* Passing: 4.6:1 contrast ratio */
.lesson-subtitle {
  color: #595959;
  background-color: #ffffff;
}

Important: Color can never be the only means of conveying information. If you use green for "correct" and red for "incorrect" on quizzes, add icons or text labels too. Approximately 8% of men have some form of color vision deficiency.

Text Alternatives (Success Criterion 1.1.1)

Every non-text element needs a text alternative. In EdTech, this means:

All images need descriptive alt text
Diagrams and charts need long descriptions
Mathematical equations need MathML or text alternatives
Interactive simulations need text-based alternatives or descriptions

{/* Bad: unhelpful alt text */}
<img src="/lessons/cell-division.png" alt="diagram" />

{/* Good: descriptive alt text */}
<img
  src="/lessons/cell-division.png"
  alt="Diagram showing the six stages of mitosis: prophase, prometaphase, metaphase, anaphase, telophase, and cytokinesis, with labeled illustrations of chromosome behavior at each stage"
/>

{/* Complex diagram: use aria-describedby for long descriptions */}
<figure>
  <img
    src="/lessons/water-cycle.png"
    alt="The water cycle"
    aria-describedby="water-cycle-description"
  />
  <figcaption id="water-cycle-description">
    The water cycle shows evaporation from oceans and lakes rising as water
    vapor, condensing into clouds, falling as precipitation over land and
    water, and collecting in rivers and groundwater before returning to the
    ocean. Arrows indicate the direction of flow at each stage.
  </figcaption>
</figure>

Captions and Audio Descriptions (Success Criteria 1.2.2, 1.2.5)

If your platform includes video content — and most EdTech platforms do — you need:

Synchronized captions for all pre-recorded video (not auto-generated garbage — actual reviewed captions)
Audio descriptions for video where important visual content isn't described in the existing audio track
Transcripts as a fallback for all audio and video content

Auto-generated captions from YouTube or similar services are a starting point, but they're not sufficient for WCAG compliance. Technical terms, proper nouns, and accented speech are frequently mangled. Budget for human review.

Operable: Students Can Navigate and Interact

This is where EdTech accessibility gets hard — especially for interactive learning activities.

Keyboard Navigation (Success Criterion 2.1.1)

Every interactive element must be operable with a keyboard alone. No exceptions. A student who uses a switch device, a screen reader, or a mouth stick needs to complete assignments, navigate lessons, and take assessments without touching a mouse.

// Bad: click-only interaction with no keyboard support
const LessonCard = ({ lesson, onSelect }) => (
  <div
    className="lesson-card"
    onClick={() => onSelect(lesson.id)}
  >
    <h3>{lesson.title}</h3>
    <p>{lesson.description}</p>
  </div>
);

// Good: keyboard accessible with proper semantics
const LessonCard = ({ lesson, onSelect }) => (
  <button
    className="lesson-card"
    onClick={() => onSelect(lesson.id)}
    onKeyDown={(e) => {
      if (e.key === 'Enter' || e.key === ' ') {
        e.preventDefault();
        onSelect(lesson.id);
      }
    }}
    aria-label={`Open lesson: ${lesson.title}`}
  >
    <h3>{lesson.title}</h3>
    <p>{lesson.description}</p>
  </button>
);

A common mistake I see: developers use <div> or <span> elements with click handlers instead of semantic <button> or <a> elements. This breaks keyboard navigation, screen reader interaction, and focus management all at once. Use the right HTML element and you get accessibility for free.

Focus Management (Success Criteria 2.4.3, 2.4.7)

Focus order must follow a logical sequence, and the currently focused element must be visually indicated. This is critical for multi-step interactions like:

Quiz flows (question 1 -> question 2 -> submit)
Module navigation (lesson -> activity -> assessment)
Modal dialogs (settings, help, submission confirmations)

// Managing focus when moving between quiz questions
const QuizQuestion = ({ questionNumber, totalQuestions }) => {
  const questionRef = useRef<HTMLHeadingElement>(null);

  useEffect(() => {
    // Move focus to the question heading when it renders
    questionRef.current?.focus();
  }, [questionNumber]);

  return (
    <div role="region" aria-label={`Question ${questionNumber} of ${totalQuestions}`}>
      <h2 ref={questionRef} tabIndex={-1}>
        Question {questionNumber} of {totalQuestions}
      </h2>
      {/* Question content */}
    </div>
  );
};

Never remove focus outlines without replacing them. I see outline: none in EdTech CSS all the time because designers think the blue ring is ugly. Replace it with a custom focus indicator — don't just delete it.

/* Bad: removes focus indicator entirely */
*:focus {
  outline: none;
}

/* Good: custom focus indicator that's visible and clear */
*:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
  border-radius: 2px;
}

Timing Controls (Success Criterion 2.2.1)

Timed assessments are a major accessibility issue. Students with certain disabilities are legally entitled to extended time accommodations. Your platform must support:

Configurable time limits per student (not just per assessment)
The ability to pause timers
Warnings before time expires (at least 20 seconds in advance)
The option to turn off time limits entirely for accommodated students

interface AssessmentTimerProps {
  baseDuration: number; // minutes
  accommodationMultiplier: number; // 1.0, 1.5, 2.0, or unlimited
  onTimeExpired: () => void;
  onWarning: () => void;
}

// The accommodation multiplier should be set per student
// based on their IEP/504 plan, not hardcoded

Understandable: Students Can Comprehend Content and Interfaces

Consistent Navigation (Success Criterion 3.2.3)

Navigation must appear in the same relative position on every page. This sounds obvious, but I've seen EdTech platforms where the sidebar menu disappears on certain content types, or the "next lesson" button moves from the bottom to the top depending on the template.

Error Identification and Suggestion (Success Criteria 3.3.1, 3.3.3)

When a student makes an error on a form or assessment, the error must be:

Identified in text (not just by a red border)
Described clearly (not just "invalid input")
Accompanied by a suggestion for correction when possible

// Bad: visual-only error indication
<input
  type="email"
  className={errors.email ? "border-red-500" : "border-gray-300"}
/>

// Good: accessible error handling
<div>
  <label htmlFor="student-email">Email Address</label>
  <input
    id="student-email"
    type="email"
    aria-invalid={!!errors.email}
    aria-describedby={errors.email ? "email-error" : undefined}
    className={errors.email ? "border-red-500" : "border-gray-300"}
  />
  {errors.email && (
    <p id="email-error" role="alert" className="text-red-700 text-sm mt-1">
      Please enter a valid email address (example: student@school.edu)
    </p>
  )}
</div>

Robust: Content Works with Assistive Technologies

ARIA Usage (Success Criterion 4.1.2)

ARIA (Accessible Rich Internet Applications) attributes help screen readers understand custom components. But here's my strong advice: use ARIA as a supplement, not a substitute for semantic HTML.

The first rule of ARIA is: don't use ARIA if a native HTML element already does what you need. A <button> is always better than <div role="button">.

When you do need ARIA — for custom components like drag-and-drop activities, interactive timelines, or custom dropdowns — follow these patterns:

// Accessible custom dropdown for selecting quiz answers
const AnswerSelect = ({ options, selectedAnswer, onSelect, questionId }) => (
  <div role="listbox" aria-labelledby={`question-${questionId}`}>
    {options.map((option, index) => (
      <div
        key={option.id}
        role="option"
        aria-selected={selectedAnswer === option.id}
        tabIndex={selectedAnswer === option.id ? 0 : -1}
        onClick={() => onSelect(option.id)}
        onKeyDown={(e) => {
          if (e.key === 'Enter' || e.key === ' ') {
            e.preventDefault();
            onSelect(option.id);
          }
          if (e.key === 'ArrowDown') {
            e.preventDefault();
            // Focus next option
          }
          if (e.key === 'ArrowUp') {
            e.preventDefault();
            // Focus previous option
          }
        }}
      >
        {option.label}
      </div>
    ))}
  </div>
);

Live Region Announcements

When content changes dynamically — a quiz score appearing, a new discussion post loading, a timer counting down — screen reader users need to be notified. Use ARIA live regions:

// Announce quiz results to screen readers
const QuizResults = ({ score, total, passed }) => (
  <div
    role="status"
    aria-live="polite"
    aria-atomic="true"
  >
    <h2>Quiz Complete</h2>
    <p>
      You scored {score} out of {total} ({Math.round((score/total) * 100)}%).
      {passed ? " You passed!" : " You did not pass. Review the material and try again."}
    </p>
  </div>
);

Accessibility in Specific EdTech Contexts

Interactive Assessments

Drag-and-drop activities are one of the hardest things to make accessible. Our approach:

Always provide a keyboard alternative (e.g., numbered list with arrow key reordering)
Use aria-grabbed and aria-dropeffect attributes for drag-and-drop
Announce drag operations with live regions ("Item 3 picked up. Use arrow keys to move.")
Provide a fully accessible fallback (dropdown select or radio button alternative)

Math and Science Content

Mathematical notation requires special attention:

Use MathML or MathJax with proper ARIA labels
Provide text alternatives for all equations ("the square root of x squared plus y squared")
Ensure chemical formulas, musical notation, and other domain-specific symbols have accessible representations
Test with JAWS, NVDA, and VoiceOver — each handles math differently

Video and Multimedia

Beyond captions and transcripts:

Provide keyboard controls for all video player functions (play, pause, volume, seek, playback speed, caption toggle)
Ensure the video player is navigable with a screen reader
Allow students to download captions as a text file for offline review
If content includes background music, provide a way to mute it independently of speech

Testing for Accessibility

Building accessible doesn't mean anything if you don't test it. Here's our testing protocol:

Automated Testing (Catches ~30% of Issues)

Tool	What It Catches	Integration
axe-core	WCAG violations in rendered HTML	Jest, Cypress, CI/CD pipeline
Lighthouse	Accessibility score and common issues	Chrome DevTools, CI/CD
eslint-plugin-jsx-a11y	Accessibility issues in JSX at build time	ESLint config
Pa11y	Full-page accessibility scans	CI/CD pipeline

Important: Automated tools miss the majority of accessibility issues. They can't tell you if alt text is meaningful, if focus order is logical, or if a custom component is usable with a screen reader. They're a first pass, not a final check.

Manual Testing (Catches ~70% of Issues)

Every feature we ship goes through this checklist:

Keyboard-only navigation — Can you complete every task without a mouse? Tab through the entire flow.
Screen reader testing — Test with VoiceOver (macOS/iOS), NVDA (Windows, free), and JAWS (Windows, paid). At minimum, test with one.
Zoom to 200% — Does the layout break at 200% browser zoom? Content must remain usable.
High contrast mode — Test with Windows High Contrast Mode and browser-based contrast extensions.
Reduced motion — Does the platform respect prefers-reduced-motion? Animations should pause or be removed.
Color-only communication — Turn your screen to grayscale. Can you still use the interface?

User Testing with Disabled Students

This is the gold standard and the step most teams skip. We strongly recommend conducting usability testing sessions with students who use assistive technologies. Their feedback will reveal issues no automated tool or sighted tester can find.

Common Accessibility Failures in EdTech

These are the issues I see most frequently when auditing educational platforms:

Inaccessible PDF assignments — PDFs exported from Word without proper tagging are unreadable by screen readers. Use tagged PDFs or provide HTML alternatives.
Auto-playing media — Video or audio that plays automatically is disorienting for screen reader users. Always require user-initiated playback.
Custom quiz components without keyboard support — If you built a custom matching activity or drag-and-drop, test it with keyboard only.
Missing skip navigation links — Students using screen readers shouldn't have to tab through 40 navigation links on every page. Add a "Skip to main content" link.
Form inputs without labels — Placeholder text is not a label. Screen readers don't reliably announce placeholder text.
Nested interactive elements — A clickable card with a clickable button inside it confuses both keyboard and screen reader users. Flatten the interaction.

Building an Accessibility-First Culture

The biggest accessibility wins aren't technical — they're cultural. Here's what we recommend to our EdTech clients:

Include accessibility in your Definition of Done. A feature isn't done until it passes keyboard and screen reader testing.
Add accessibility checks to code review. Reviewers should verify semantic HTML, ARIA usage, and focus management.
Budget for it upfront. Retrofitting accessibility into an existing platform costs 3-5x more than building it in from the start.
Hire or consult with disabled testers. People who use assistive technology daily will find issues you'll never catch.

Explore Our EdTech Development Services

Education Technology Development — Accessible EdTech platforms built to WCAG 2.1 AA
Custom LMS Development: Build vs Buy — When custom development ensures accessibility your way

The Bottom Line

Accessibility in EdTech isn't a compliance burden. It's the difference between software that educates every student and software that leaves students behind because of how they interact with technology.

The technical standards are clear. WCAG 2.1 AA gives you a concrete checklist. The tools are available. The testing methods are well-documented. What's required is the commitment to treat accessibility as a foundational requirement, not a punch-list item at the end of development.

Every student deserves software that works for them. If you're building an EdTech platform and want to get accessibility right from day one, reach out. We've built accessible educational software from the ground up, and we can help you do the same.