Before & After Examples

See common accessibility issues and their fixes. Learn by example.

Images & Alt Text

Missing alt textWCAG 1.1.1

Screen readers announce images without alt text as "image" or read the filename, which is unhelpful or confusing.

Before (Inaccessible)
<img src="IMG_2847.jpg">

Screen reader announces:"IMG underscore 2847 dot jpg, image"

After (Accessible)
<img src="IMG_2847.jpg" 
 alt="Students studying together 
 in the Main Library atrium">

Screen reader announces:"Students studying together in the Main Library atrium, image"

How to fix

  • Addalt=""attribute to every image
  • Describe thepurposeor content of the image
  • Keep it concise (usually 1-2 sentences)
  • Don't start with "Image of..." or "Picture of..."

Decorative images not marked as decorativeWCAG 1.1.1

Decorative images (dividers, backgrounds) should have empty alt text so screen readers skip them.

Before
<img src="divider-line.png" 
 alt="decorative line divider">

Problem:Screen reader reads "decorative line divider" which adds no value and interrupts the flow.

After
<img src="divider-line.png" alt="">

Result:Screen reader skips the image entirely, improving the reading experience.

Headings & Structure

Bold text instead of real headingsWCAG 1.3.1

Screen reader users navigate by headings. Bold text looks like a heading but isn't announced as one.

Before
<p><strong>Course Requirements</strong></p>
<p>Students must complete...</p>

Problem:Visually looks like a heading but screen readers don't recognize it. Users can't jump to this section.

After
<h2>Course Requirements</h2>
<p>Students must complete...</p>

Result:Screen readers announce "Course Requirements, heading level 2" and users can navigate directly to it.

How to fix in Word

  • Select the text Home tab Styles panel Choose "Heading 1", "Heading 2", etc.
  • Never use bold + larger font as a fake heading

Skipped heading levelsWCAG 1.3.1

Headings should follow a logical hierarchy without skipping levels.

Before
<h1>University Policies</h1>
<h4>Academic Integrity</h4> <!-- Skipped h2, h3 -->
<h2>Attendance</h2>

Problem:Jumping from h1 to h4 confuses screen reader users about the document structure.

After
<h1>University Policies</h1>
<h2>Academic Integrity</h2>
<h2>Attendance</h2>

Result:Clear, logical hierarchy. Users understand Academic Integrity and Attendance are equal sections under Policies.

Color & Contrast

Insufficient color contrastWCAG 1.4.3

Text must have at least 4.5:1 contrast ratio against its background (3:1 for large text).

Before
This light gray text on light background is hard to read. Contrast ratio: 2.5:1

Problem:Fails WCAG. Difficult for users with low vision, in bright light, or on low-quality monitors.

After
This darker text is easy to read. Contrast ratio: 10:1

Result:Passes WCAG AA. Readable in more conditions.

Tool

UseWebAIM Contrast Checkerto test your colors.

Color as the only indicatorWCAG 1.4.1

Don't rely on color alone to convey information—some users can't perceive color differences.

Before

"Required fields are shown inred."

Problem:Users who are colorblind can't identify required fields.

After

"Required fields are marked with*(asterisk)."

Result:Color + symbol = accessible to everyone.

Forms

Missing form labelsWCAG 1.3.1, 3.3.2

Every form input needs a programmatic label so screen readers can announce what to enter.

Before
Email: <input type="email">

Screen reader announces:"Edit text" (no indication of what field this is)

After
<label for="email">Email:</label>
<input type="email" id="email">

Screen reader announces:"Email, edit text"

Placeholder text as labelsWCAG 3.3.2

Placeholder text disappears when typing, leaving users without context.

Before
<input type="text" placeholder="Enter your name">

Problems:

  • Disappears once user starts typing
  • Often has poor contrast
  • Not reliably announced by screen readers
After
<label for="name">Full name</label>
<input type="text" id="name" 
 placeholder="e.g., Jane Smith">

Result:Permanent label + helpful example placeholder.

Tables

Data tables without headersWCAG 1.3.1

Screen readers need header cells to announce context for each data cell.

Before
<table>
 <tr>
 <td>Course</td>
 <td>Credits</td>
 <td>Grade</td>
 </tr>
 <tr>
 <td>ENG 101</td>
 <td>3</td>
 <td>A</td>
 </tr>
</table>

Screen reader:"ENG 101, 3, A" (no context)

After
<table>
 <tr>
 <th scope="col">Course</th>
 <th scope="col">Credits</th>
 <th scope="col">Grade</th>
 </tr>
 <tr>
 <td>ENG 101</td>
 <td>3</td>
 <td>A</td>
 </tr>
</table>

Screen reader:"Course: ENG 101, Credits: 3, Grade: A"

Documents

Scanned PDF (image-only)WCAG 1.4.5

Scanned documents are just images—screen readers see nothing but "image".

Before

What happens:

  • Screen reader: "Image. Page 1 of 5."
  • No text to read
  • Can't search or copy text
  • Can't adjust font size
After (OCR + tagging)

What happens:

  • Screen reader reads all text
  • Searchable and selectable
  • Can reflow at larger sizes
  • Properly tagged for structure

How:Use Acrobat's "Recognize Text" (OCR), then add tags.

Want more examples?

W3C Tutorials

Official tutorials from the standards body.

WAI Tutorials

Deque Patterns

Accessible component patterns with code.

Deque Library

Back to top