Why EdTech WYSIWYG Editors Still Fail Screen Reader Users

Imagine a student with visual impairment, excited to join an online course. But the moment they open the text editor, their screen reader can't understand anything.

The toolbar buttons have no labels. The formatting options can't be found. Even simple things like making text bold or adding a list become impossible.

This happens more often than we think. Many education platforms say they are "accessible," but students with visual impairments still struggle. And the main problem usually comes from one place: the WYSIWYG editor (the tool you use to write and format text).

In this article, we'll explore why WYSIWYG editors create hidden accessibility problems, what makes a text editor truly accessible, and how modern tools are fixing these issues with minimal effort.

Key Takeaways

• Many EdTech platforms still don't work well with screen readers, especially in their text editors, making learning harder for visually impaired students.
• Building accessible WYSIWYG editors from scratch is complex and requires expertise in ARIA, keyboard navigation, and semantic HTML.
• WYSIWYG editors must have clear ARIA labels and use correct HTML so screen readers can understand what's happening.
• Just saying a platform is "accessible" doesn't mean it actually works well; many fail simple screen reader tests.
• Modern text editors already solve most accessibility problems, so developers can focus on education features instead of fixing editor issues.

Understanding the Problem: Why EdTech Falls Short

To understand why these problems appear so often, let's look at what actually goes wrong in most platforms.

The Reality for Students with Visual Impairments

Many families say that online learning platforms promise accessibility, but their children with visual impairments still can't use them easily on their own. This is a common and very real problem.

Students often face issues like websites that don't work well with screen readers, videos without captions, and platforms that can't be used properly with just a keyboard. But the biggest struggle often happens inside the text editor, the WYSIWYG editor.

You can see a detailed breakdown of common screen reader barriers in the WebAIM reports.

What Makes WYSIWYG Editors So Challenging?

WYSIWYG editors allow users to format text just like in Microsoft Word. But because these editors depend heavily on JavaScript, they can be hard to make accessible.

Here are the main issues:

• Buttons without labels, so screen readers don't know what they do.
• Features that require a mouse make them unusable for keyboard-only users.
• Complicated menus that don't have proper navigation.
• Changing content that isn't announced leaves users confused.
• Poor focus management leaves users lost in the interface.

So if editors are this complex, what does an accessible one actually need? Let's break it down.

The Building Blocks of Accessible WYSIWYG Editors

Now, let's look at what every editor needs to be usable for students with visual impairments.

1. Semantic HTML: The Foundation

Before adding anything advanced, the first step is to use semantic HTML. This simply means using the correct HTML tags so screen readers, browsers, and search engines understand the meaning and structure of your content.

Bad Example (Non-Semantic):

<div class="heading-big">Welcome to Our Course</div><div class="text-content">This is the first paragraph.</div><div class="text-content">This is the second paragraph.</div>

Good Example (Semantic):

<h1>Welcome to Our Course</h1><p>This is the first paragraph.</p><p>This is the second paragraph.</p>

Why does this matter?

Screen readers use these meaningful tags to understand how the content is organised. Simply making text bold to look like a heading won't give any real information to assistive technologies.

For more guidance on using proper semantic structure, MDN provides an excellent reference on accessible HTML.

Common Semantic Elements for Editors:

<!-- Headings for structure --><h1>Main Title</h1><h2>Section Heading</h2><h3>Subsection</h3><!-- Lists for organization --><ul> <li>Unordered list item</li></ul><ol> <li>Ordered list item</li></ol><!-- Emphasis and importance --><strong>Important text</strong><em>Emphasized text</em><!-- Links with context --><a href="/resources">View Learning Resources</a>

Once you have the basic structure, the next step is making sure assistive tools can understand what each button and control is meant to do.

2. ARIA Labels: Filling in the Missing Information

ARIA (Accessible Rich Internet Applications) helps screen readers understand parts of a website that HTML alone can't explain. It's especially useful for buttons or icons that don't have visible text.

The aria-label attribute gives a clear name to an element so a screen reader can tell the user what it does.

Simple Button Example:

<!-- Without ARIA: Screen reader only says "Button" --><button> <svg><!-- Bold icon --></svg></button><!-- With ARIA: Screen reader says "Make text bold, Button" --><button aria-label="Make text bold"> <svg aria-hidden="true"><!-- Bold icon --></svg></button>

The aria-hidden="true" on the icon tells the screen reader to ignore the decorative graphic so it doesn't confuse the user.

You can check the official WCAG 2.1 recommendations for naming, labeling, and roles here.

3. Keyboard Navigation: A Must-Have

Users should be able to use the entire editor with just a keyboard. They need to move around, open menus, and use features without touching a mouse.

Basic Keyboard Support Checklist:

• Tab: Move to the next button or control
• Shift + Tab: Move back to the previous control
• Enter / Space: Click or activate a button
• Arrow keys: Move through items inside a dropdown menu
• Escape: Close any open menu or dialog box

For real-world testing advice, WebAIM's keyboard accessibility guide is extremely helpful.

Finally, editors must communicate changes clearly, especially when things update on the fly.

4. Live Regions: Telling Screen Readers About Changes

When something on the page updates automatically, like a message, alert, or formatting change, screen readers need a way to know. Live regions help announce these updates so users aren't left confused.

Types of Live Regions:

• aria-live="polite": Announces the change when the screen reader finishes what it's currently reading (good for most updates).
• aria-live="assertive": Interrupts right away to announce the change (only for important warnings or errors).

When you put all these requirements together, it becomes clear why so many editors fall short.

The Challenge of Building Accessible Editors From Scratch

Building an accessible WYSIWYG editor yourself is a huge job. You would have to handle all the accessibility features on your own, and each one takes time, testing, and deep knowledge. Here's what you'd need to build manually:

ARIA Implementation

You would need to set up all the ARIA roles and labels so screen readers understand the editor properly. This includes:

• Correct roles for toolbars, buttons, menus, and menu items.
• aria-label for every icon button.
• aria-pressed for toggle buttons (like bold or italic).
• aria-expanded for dropdowns.
• aria-controls to link buttons to the sections they affect.
• aria-describedby for extra help text.
• Live regions for announcing updates.

Keyboard Navigation System

You must make sure the entire editor works without a mouse. This means:

• Managing the order of elements users move through.
• Use arrow keys to move inside menus and toolbars.
• Making Escape close dialogs and menus.
• Keeping focus inside a dialog until it's closed.
• Returning focus to the right place afterwards.
• Adding shortcuts like Ctrl+B or Ctrl+I.

Dynamic Content Management

The editor has to respond to changes smoothly and clearly:

• Announce formatting changes.
• Update button states based on where the cursor is.
• Handle focus when content moves or changes.
• Support accessible paste behaviour.
• Announce errors and success messages.

Cross-Browser Compatibility

Different setups behave differently, so you must handle:

• Screen readers interpret ARIA in different ways.
• Browser-specific quirks in keyboard navigation.
• Accessibility on mobile and touch devices.

Building all of this correctly can take months. It also needs constant updates as accessibility standards change. For most EdTech teams, this pulls time away from their main goal: creating strong learning experiences.

The Modern Solution: Using Froala Editor

Instead of building everything from scratch, many platforms now use editors like Froala, TinyMCE that already include strong accessibility support. This saves a huge amount of time and makes the experience better for all students.

You can read Froala's full accessibility documentation here.

Here's how to set up a fully accessible editor in just a few lines of code:

<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>WYSIWYG Editors</title> <!-- Froala CSS --> <link rel="stylesheet" href="<https://cdn.jsdelivr.net/npm/froala-editor@latest/css/froala_editor.pkgd.min.css>" /> <!-- Froala JS --> <script src="<https://cdn.jsdelivr.net/npm/froala-editor@latest/js/froala_editor.pkgd.min.js>"></script> <style> body { font-family: Arial, sans-serif; margin: 20px; } h2 { margin-top: 40px; } .editor-container { margin-bottom: 50px; } textarea { width: 100%; min-height: 200px; } </style> </head> <body> <h1>WYSIWYG Editors for Accessibility</h1> <!-- Froala Editor Container --> <div class="editor-container"> <textarea id="froala-editor"> </textarea> </div> <!-- Froala Initialization Script --> <script> new FroalaEditor("#froala-editor", { // --- Keyboard Shortcuts --- shortcutsEnabled: [ "bold", "italic", "underline", "strikeThrough", "indent", "outdent", "undo", "redo", ], shortcutsHint: true, // Shows hints for available keyboard shortcuts // --- Toolbar Buttons --- toolbarButtons: [ "bold", "italic", "underline", "strikeThrough", "subscript", "superscript", "fontFamily", "fontSize", "textColor", "backgroundColor", "inlineClass", "inlineStyle", "clearFormatting", ], // --- Keyboard Navigation & Editing --- tabSpaces: 4, // Number of spaces when pressing Tab tabIndex: 1, // Makes the editor focusable using Tab key // --- Accessibility & Usability --- tooltips: true, // Show tooltips on toolbar buttons placeholderText: "Start typing here... (Press Tab to navigate toolbar)", // --- Editor Appearance --- theme: "royal", heightMin: 200, heightMax: 400, // --- Character Counter --- charCounterCount: true, // Show live character count charCounterMax: 1000, // Max characters allowed // --- General Settings --- language: "en_us", toolbarInline: false, // Use standard toolbar (not inline) toolbarSticky: false, // Toolbar doesn't stick when scrolling // --- Events for debugging/keyboard handling --- events: { initialized: function () { console.log("Froala initialized with keyboard navigation"); }, focus: function () { console.log("Editor focused"); }, }, }); </script> </body></html>

That's it! With just a few lines of code, you get:

• A fully accessible WYSIWYG editor.
• Built-in keyboard shortcuts (like Ctrl+B, Ctrl+I).
• Easy keyboard navigation for all toolbar buttons.
• Clear tooltips and ARIA labels for screen readers.

Even with a powerful editor like Froala, there are still a few things you should keep in mind to ensure the experience stays accessible.

Best Practices for Building Accessible WYSIWYG Experiences

Here are some simple tips to ensure your editor works well for every learner.

• Use the correct HTML tags for headings, paragraphs, lists, and links. This helps screen readers understand the page structure.
• ARIA is there to fill in missing information, not to replace semantic HTML. Use aria-label for buttons with only icons and aria-hidden for decorative icons.
• Make sure every part of the editor can be used with a keyboard. Users should be able to reach controls with Tab, activate them with Enter/Space, and move through menus with arrow keys.
• Keep the keyboard focus visible at all times. Users should always know where they are on the screen.
• Announce important updates, like formatting changes or error messages, using live regions, depending on how urgent the message is.
• Keep your toolbar simple and well-organised. Complicated, deep menus are harder for screen reader and keyboard users.
• Update toggle buttons (like Bold or Italic) so they correctly show their aria-pressed state based on where the cursor is.
• Test with popular screen readers like NVDA, JAWS, and VoiceOver, and check different browsers because each works a bit differently.
• Revisit your editor regularly. Standards, browsers, and user needs change over time, so ongoing updates are important.

Common Pitfalls to Avoid

Here are some dimple mistakes that can harm accessibility and how to avoid them.

Not Testing with Real Screen Readers

Even if you're using a tool like Froala, you still need to check how it feels for real users.

How to Test:

• Install NVDA (free for Windows) or use the built-in VoiceOver on Mac.
• Try using the entire editor with only your keyboard.
• Create a small piece of content from start to finish.
• Make sure every button is announced clearly by the screen reader.

Forgetting About Color Contrast

If you add custom styles, make sure the text and button colors still have enough contrast. Low-contrast colors make the editor hard to see for many users.

Overriding Froala's Accessibility Features

Don't disable features that help accessibility:

// Avoid doing thisnew FroalaEditor('#editor', { accessibility: false, // Don't disable this! shortcutsEnabled: [] // Don't remove all shortcuts});

Not Providing Context for Images

Students using screen readers rely on helpful alt text. Always encourage clear descriptions.

// Bad: Generic promptsconst alt = prompt('Alt text:');// Good: Clear, helpful promptsconst alt = prompt( 'Describe what you see in this image.\\n' + 'This helps students using screen readers understand the content:');

Ignoring Mobile Accessibility

Test your editor on mobile devices too. Many learners use phones or tablets.

Check it with:

• iOS VoiceOver
• Android TalkBack
• Zoom/magnification features

These help you spot issues that only appear on touch devices.

By putting these principles into practice, you can ensure your editor supports every learner from the very beginning.

Conclusion

Making online learning accessible isn't just a "nice to have"; it's essential. For many students with visual impairments, the text editor is the biggest barrier in their learning journey. If buttons don't have labels, the keyboard doesn't work properly, or changes aren't announced, the whole experience becomes confusing and frustrating.

The good news is that accessibility doesn't have to be hard. By using proper HTML, adding clear ARIA labels, supporting full keyboard use, and announcing updates in the right way, you can create an editor that everyone can use. And with modern tools like Froala already handling most of the difficult parts, building an accessible platform becomes much simpler.

In the end, accessibility isn't about following rules; it's about making sure every learner can take part. When your WYSIWYG editor is accessible, the whole platform becomes more welcoming, easier to use, and better for all students.

About the Author

Shefali Jangid is a web developer, technical writer, and content creator with a love for building intuitive tools and resources for developers.

She writes about web development, shares practical coding tips on her blog shefali.dev, and creates projects that make developers' lives easier.

Resources for Further Reading

• Froala Editor Accessibility Documentation
• WCAG 2.1 Guidelines
• WebAIM: Articles on Accessibility
• MDN Web Docs: ARIA
• WebAIM Keyboard Accessibility