Preventing accessibility problems in WYSIWYG editors

Rarely do you get to choose which content editor your company uses. It’s usually baked into whatever CMS your company chose (e.g., WordPress, Wix, Squarespace, or some enterprise system). However, your content team uses the WYSIWYG editor every day to publish blog posts, landing pages, and help docs. And that’s where many accessibility problems get introduced. The good news is you can prevent the most common failures without switching platforms.

The three problems to watch for:

1. Missing alt text on images: When uploading images, the alt text field is usually optional. Users skip it because they’re in a hurry or don’t understand why it matters.
   If you have admin access, configure the editor to require alt text before images can be inserted. Train your team on how to write descriptions, not keywords.
2. Fake headings (bold text instead of proper headings): Users want text to look like a heading, so they select it, make it bold, and maybe increase the font size. It looks like a heading visually, but screen readers don’t recognize it as one.
   Show your team where the heading dropdown is (usually labeled “Paragraph” or “Normal” by default). If default heading styles don’t match your design, fix the CSS. Don’t let users work around it with bold text.
3. Meaningless link text: Links with text like “click here” and “read more” are easy to create but useless out of context. Screen reader users navigate by pulling up a list of all links on a page. Clarity matters here.
   Train your team to write descriptive link text. The link text should tell you where you’re going before you click.

Making it stick

Look for accessibility checker plugins for your CMS. For WordPress, try the Accessibility Checker plugin. It helps flag these issues before the content goes live.

You probably can’t change your CMS, but you can change how your team uses it. These three problems are preventable with basic training and better defaults.