Amara's story
Hearing the web through a screen reader, and the silence where information should be.
Barriers encountered
Form inputs without labels
The barrier
Amara is filling out a university application form. VoiceOver announces: "Edit text, blank." Then: "Edit text, blank." Then: "Edit text, blank." Three input fields, no labels. She has no idea what information to enter. Is the first field her name? Email? Student ID? She tries typing her name in the first field and her email in the second, but it turns out the first field was for her student ID. She has to start over.
Jeikin catches it
Jeikin flags form inputs that have no associated label element. Screen readers cannot tell users what information each field expects.
The fix
Associate a label element with each input using the for/id pattern. The label text should describe what the field is for, not just placeholder text that disappears on focus.
<label for="student-id">Student ID</label>After the fix
VoiceOver announces: "Student ID, edit text." Then: "Full name, edit text." Amara fills in each field confidently on the first try and moves to the next section.
No heading hierarchy
The barrier
Amara tries to navigate the university's course catalog by headings, her fastest way to scan a long page. She presses VO+Command+H to jump to the next heading. Nothing happens. The entire page is styled with bold text and font sizes, but there are no semantic headings. To Amara, the page is one long undifferentiated block of text. She has to listen to everything from the top to find the law courses section.
Jeikin catches it
Jeikin detects that the page has no heading elements despite having visually distinct sections. Screen reader users cannot navigate by headings, which is their **primary scanning method**.
The fix
Use semantic heading elements (h1, h2, h3) instead of styled paragraphs. Headings should form a logical outline of the page content.
After the fix
Amara presses VO+Command+H twice and lands directly on "Law". She explores the courses, finds Criminal Law 201, and registers. **30 seconds** instead of 10 minutes.
Decorative images announced by screen reader
The barrier
Amara is reading a blog post about study tips. Between every paragraph, VoiceOver announces: "Image, decorative-border-blue-wave-pattern-dot-png." Then: "Image, stock-photo-student-studying-twelve-hundred-by-eight-hundred-dot-jpeg." These verbose announcements interrupt her reading flow. Each one takes 3-4 seconds. After the fifth unnecessary image description, she loses her place in the article and gives up.
Jeikin catches it
Jeikin flags images that appear decorative but lack an empty alt attribute. Screen readers fall back to reading the filename, which is always unhelpful and often very long.
The fix
Set alt="" on decorative images so screen readers skip them entirely. If an image carries meaning, give it a useful description. If it's decoration, make it invisible to assistive technology.
<img src="border.png" alt="" role="presentation" />After the fix
Amara reads the blog post smoothly. VoiceOver moves from paragraph to paragraph without interruption. She finishes the article, bookmarks the useful tips, and doesn't even notice the decorative images. Which is exactly the point.
What changed for Amara
- Form inputs have labels. Amara knows what each field expects on the first try.
- Headings create a navigable outline. She jumps directly to the section she needs.
- Decorative images are hidden from screen readers. No more filename interruptions.
WCAG criteria addressed
Catch barriers like these automatically
Jeikin finds accessibility issues and explains them in plain language, so your team can fix what matters.
npx jeikin initStart for freeBy signing up, you agree to our Terms of Service and Privacy Policy.