Help
Write or import a document, and Ada Editor checks it against WCAG 2.1 AA and Section 508 as you go. This page explains every check in plain words, and how to fix what it finds.
Prefer to be shown? The tour points out each part of your desk and the editor.
Every finding has a label, a shape and an underline style, so you never need to tell colours apart.
No findings doesn’t mean a document is accessible. Automated checks cover only part of WCAG; whether alt text is accurate, or headings match the real structure, still needs a person. More in our guide to what “ADA compliant PDF” can and can’t mean, and, for each WCAG 2.1 AA criterion, in what software can decide in a meeting document.
WCAG 1.1.1 Non-text Content (Level A)
An image with no alternative text tells a screen reader nothing (NVDA skips it, VoiceOver says only “image”): its content simply isn’t there for someone who can’t see it.
How to fix it: Select the image’s “Add alt text” and describe what it shows and why it matters here, in a sentence or two.
WCAG 1.1.1 Non-text Content (Level A)
Alt text that starts “Image of…” is read twice (screen readers already say it’s an image), and very short or file-name-like alt text often doesn’t describe the picture. Only a person can judge that.
How to fix it: Remove the “Image of” prefix, then read the description beside the picture and ask: would someone who can’t see it learn what they need?
WCAG 1.1.1 Non-text Content (Level A)
Charts, maps, diagrams, site and floor plans, plats, elevations and technical drawings usually carry more than a sentence of alt text can hold.
How to fix it: If the picture holds data or detail the text around it doesn’t, add a long description: a paragraph or table nearby that says the same thing in words.
WCAG 2.4.4 Link Purpose (In Context) (Level A)
People using screen readers often jump from link to link, hearing only the link text. “Click here” or “read more” tells them nothing about where it goes. WCAG accepts it when the sentence around the link says where it goes, so this asks rather than fails.
How to fix it: Rewrite the link so its words name the destination, for example “the full meeting agenda” instead of “click here”. Go to text selects the link’s words: type the new ones, and the link keeps its address. If the sentence already names the destination, you can dismiss this.
WCAG 2.4.4 Link Purpose (In Context) (Level A)
A bare web address is read out piece by piece (NVDA says “https slash slash example dot org slash…”), and rarely says what the page is. WCAG accepts it when the address or the sentence around it makes the destination clear, so this asks rather than fails.
How to fix it: Select the address and type words that say where it goes, such as “the parks department’s events page”. The link keeps its address. If people need to read or type the address, as on a printed notice, keep it and dismiss this.
WCAG 2.4.4 Link Purpose (In Context) (Level A)
The same link text going to different places is confusing when links are listed out of context.
How to fix it: Give each link words that tell its destinations apart, or confirm the surrounding text makes the difference clear.
WCAG 2.4.2 Page Titled (Level A)
The title is what a PDF viewer, a browser tab and a screen reader announce first, before anything in the document. A default like “Document1” or “Untitled” doesn’t say what the document is.
How to fix it: Make the main heading (H1) say what the document is, such as the board and the meeting date, or add one at the top. The title follows it.
WCAG 1.3.1 Info and Relationships (Level A)
With no headings, screen reader users can only read from top to bottom; they can’t skim or jump to a section.
How to fix it: Mark section titles as headings (H1, H2) instead of making them bold or bigger.
WCAG 1.3.1 Info and Relationships (Level A)
A short line in bold or large type that starts a section looks like a heading. Unless it is marked as one, screen reader users can’t jump to it, and the PDF has no outline to move through. Agenda section titles are the usual case.
How to fix it: If the line starts a section, choose Apply fix (or Heading 1 or Heading 2 in the toolbar) to make it a heading. If it’s only emphasis, dismiss the finding.
WCAG 2.4.10 Section Headings (Level AAA)
A top-level heading (H1) is the document’s title in its structure, the first thing a screen reader user can jump to.
How to fix it: Make the title the one H1, and use H2 and below for sections.
WCAG 1.3.1 Info and Relationships (Level A)
Headings are how many readers move through a document. Jumping a level (say, from a main heading straight to a third-level one) suggests a section that isn’t there. WCAG doesn’t forbid a skip, so this asks rather than fails, but a tagged PDF with one fails PDF/UA-1, the standard Export PDF follows.
How to fix it: Use the next level down: H2 under H1, H3 under H2. Apply fix changes the level for you.
WCAG 1.3.1 Info and Relationships (Level A)
An empty heading names nothing: NVDA skips it altogether, so the section under it has no heading anyone can jump to.
How to fix it: Type the heading’s text, or turn the line back into a paragraph.
WCAG 3.1.1 Language of Page (Level A)
The document’s language tells screen readers how to pronounce everything in it. Set wrong, the whole document is read in the wrong accent.
How to fix it: Choose the right language under More (…) → Document language, or apply the suggested fix.
WCAG 3.1.2 Language of Parts (Level AA)
A passage in another language is read with the wrong pronunciation unless it’s marked, and may be unintelligible.
How to fix it: Select the passage and choose its language from the Language menu in the toolbar.
WCAG 3.1.5 Reading Level (Level AAA)
Dense, technical prose is hard for many readers, and plain language is expected of much public-sector writing. This is an AAA check, so it advises rather than fails.
How to fix it: Use shorter words and sentences, put the main point first, and explain terms readers may not know.
WCAG 3.1.5 Reading Level (Level AAA)
Long sentences are hard to follow, especially when heard rather than read.
How to fix it: Split it into two or three sentences, one idea each.
WCAG 1.4.3 Contrast (Minimum) (Level AA)
Text needs enough contrast with its background to be read by people with low vision: 4.5:1 for body text, 3:1 for large text.
How to fix it: Use the default text colour, or pick a darker one. Apply fix switches the text back to the default.
WCAG 1.4.1 Use of Color (Level A)
“The items in red” leaves out everyone who can’t see the colour, including many people with colour blindness and anyone who prints in black and white.
How to fix it: Say it in words as well: name the items, or mark them with a symbol or label as well as a colour.
WCAG 1.3.1 Info and Relationships (Level A)
Without header cells, a screen reader can’t say which column or row a value belongs to.
How to fix it: If the table holds data, choose Apply fix, or turn on Header row (and Header column if the first column labels the rows) from the Table menu. If it only lays text out side by side, such as names or contact details, choose Turn into text.
WCAG 1.3.1 Info and Relationships (Level A)
Tables of sentences, or of labels beside empty cells like a form, usually lay text out rather than hold data. A screen reader reads a table row by row, and announces header cells with every cell below them.
How to fix it: If it only lays text out, choose Turn into text, or check it reads in order row by row and has no header cells. If it holds data, turn on Header row and dismiss this.
WCAG 1.3.1 Info and Relationships (Level A)
Merged cells make it hard for screen readers to work out which header a cell belongs to.
How to fix it: Split merged cells where you can, or break the table into simpler tables. If you keep them, check the table with a screen reader.
WCAG 1.3.1 Info and Relationships (Level A)
Underscores for people to fill in are read as a run of lines, or not at all, and can’t be filled in on screen.
How to fix it: If people will fill it in on paper, this can stay. If they’ll complete it digitally, the final file needs real labelled form fields.
Everything in Ada Editor works from the keyboard. These save time:
| Keys | What they do |
|---|---|
| Ctrl/⌘ B, I, U | Bold, italic, underline |
| Ctrl/⌘ Z | Undo |
| Ctrl/⌘ Shift Z, or Ctrl/⌘ Y | Redo |
| Ctrl/⌘ ] and [ | Indent and outdent |
| F6 | Move between the toolbar, the document and the findings |
| Tab (in a table) | Next cell. Press Escape, then Tab, to leave the table |
| Ctrl/⌘ K (on your desk) | Find a document |
Export HTML saves a standalone web page: the language, headings, links, tables and images with their alt text. Export PDF saves a tagged PDF (PDF/UA-1) built from the same structure.
Hear it as a screen reader, in the same menu, lists what NVDA or VoiceOver says reading the exported web page, step by step, and can play it aloud. It’s a simulation built from recordings of the two, not a screen reader: use it to hear the order and what gets announced, and a real one (VoiceOver on a Mac, Narrator on Windows) to be sure.
An export’s title, the first thing a screen reader announces, is the document’s main heading: change the heading and the title follows. An imported Word file takes its title from its main heading too, not from the file’s hidden properties.
Exports keep the document as it is. Whatever the checker flags is still wrong in the export: an image without alt text is exported without it. The PDF’s font covers Latin scripts only; a document with Greek, Cyrillic, Hebrew, Arabic or CJK text is refused for PDF (with the characters listed), and Export HTML keeps every script.
Agenda systems change files as they publish them. We tested seven that Florida towns use, and the tags a screen reader relies on survived on some paths and not others. What we found on each platform.
If your website can publish pages, post the agenda as a page too, and link the PDF from it: why the web page comes first.
Want to know whether a posted copy kept its structure? Signed in, you can ask us to check a posted copy against the original.
Choose a light or dark theme, or match your device, and one of four text sizes: Display in the account menu, or at the top of these pages. Signed in, your choice follows you to your other devices. The document page stays white in the dark theme, because colours in a document are checked against white. Exports aren’t affected.
Signed in, you can send us a message from the contact form. If something in Ada Editor itself gets in your way, the accessibility statement says how to report it.