Accessibility Deep Dive: Screen Reader Optimization

Color contrast and type size, covered in part two of this series, handle what your visitors see. This post covers what they hear.

Screen readers transform your markup into an audio experience. A site that looks polished can be completely unusable for someone navigating by keyboard and earphones if the underlying structure is wrong. Building a screen reader friendly website comes down to a handful of concrete patterns, and most of them improve SEO at the same time.

How screen reader users actually navigate

Before touching any code, it helps to understand how screen reader users move through a page. According to WebAIM’s 2024 Screen Reader User Survey (n=1,539), 71.6% of respondents navigate long pages by heading. That single number should change how you think about heading structure. Your H2s and H3s are not decorative text sizing; they are the table of contents your visitors rely on to get around.

A growing share, 31.8% (up from 25.6% in 2021), use landmark regions to jump between major page areas. Landmarks are the programmatic equivalent of “skip to content” functionality, and they map directly to the information architecture of your site: a well-structured site is navigable both visually and audibly.

The same survey has tracked the most problematic elements for screen reader users for over 14 years. CAPTCHA remains the top barrier, followed by interactive elements that do not behave as expected, then links or buttons that do not make sense. Missing or improper headings rank eighth on the list. These are the areas where small business sites consistently fall short.

Semantic HTML first, ARIA second

The W3C’s first rule of ARIA use states: if you can use a native HTML element or attribute that has the semantics and behavior you need, use it. A <button> is better than a <div role="button"> because the browser automatically handles keyboard interaction, focus management, and the screen reader announcement. Add ARIA only when native HTML has no equivalent.

This is also the most practical advice for small teams. Native HTML does a lot of work for free. A page built with <nav>, <main>, <article>, <header>, and <footer> already exposes landmark regions without a single ARIA attribute. Each page should have exactly one <h1> that describes the page’s main content, placed at the start of the <main> element. H2 through H6 should create a logical outline that makes sense when read in order, out of context.

Where ARIA earns its keep: interactive components that have no HTML equivalent. Tabs, accordions, modals, and auto-complete inputs all need ARIA roles and properties to communicate state to screen readers. For these, follow the W3C WAI ARIA Authoring Practices Guide patterns rather than inventing your own.

Three practical fixes most sites need

Alt text: meaningful versus decorative

Every <img> needs an alt attribute. The value depends on the image’s purpose.

• Informative images get a description of what the image communicates, not what it looks like. A photo of your Houston storefront on a contact page: alt="Desque studio entrance on Main Street, Houston".
• Decorative images (background textures, purely aesthetic dividers) get an empty alt="". This tells the screen reader to skip the image entirely. A missing attribute is not the same thing; without alt, some screen readers announce the file name.
• Functional images (icons used as buttons, linked images) describe the action, not the image. A search icon button: alt="Search".

The 2026 WebAIM Million report found that 83.9% of home pages contain low-contrast text, the most common WCAG failure for seven consecutive years. Problematic alt text is similarly pervasive. Both are quick wins during a development review.

Accessible forms

Forms are where screen reader users face the most friction. The pattern is simple but non-negotiable:

1. Every input gets a <label> with a for attribute matching the input’s id.
2. Placeholder text supplements a label; it never replaces one.
3. Error messages connect to their fields via aria-describedby so the error is read when the user focuses the invalid field.
4. Group related inputs (radio buttons, checkboxes) with <fieldset> and <legend>.

A contact form without proper labels is inaccessible to screen reader users regardless of how it looks visually. For a Houston contractor or medical office whose phone and email fields are the primary conversion point, a broken form is lost revenue.

Focus management and skip links

Keyboard users (including screen reader users) navigate sequentially. Two patterns help them skip repetitive content:

Skip links are <a> elements at the very top of the page that link to #main-content. They are visually hidden by default and revealed on focus. Every major screen reader supports them, and they are required for WCAG 2.1 AA compliance under Success Criterion 2.4.1.

Focus management matters whenever your interface changes state: a modal opens, an alert appears, a single-page route changes. When a modal opens, focus should move to the first interactive element inside it. When it closes, focus should return to the element that triggered it. Without this, keyboard users get lost in the page.

The business case is clear

Accessibility is not a niche concern. Federal court filings in 2025 included 3,117 ADA Title III website accessibility lawsuits, a 27% increase over 2024, according to Seyfarth Shaw LLP. These cases target businesses of all sizes, including small and mid-market companies in industries like retail, hospitality, and professional services.

Houston businesses serving the Energy Corridor, Medical Center, or Midtown are subject to the same federal accessibility standards as any national brand. The cost of remediation after a demand letter is nearly always higher than building correctly in the first place.

Accessible HTML also benefits SEO. Search engine crawlers share characteristics with screen readers: they read headings as document structure, follow keyboard-navigable links, and parse alt text as image context. A site built for screen reader users is easier for crawlers to understand, which reinforces your search engine optimization signals.

The combination of legal exposure, broader reach, and SEO alignment makes screen reader optimization one of the highest-ROI improvements a small business site can make. The fundamentals, semantic HTML, meaningful alt text, labeled forms, and a logical heading hierarchy, do not require an accessibility consultant or a large budget. They require attention during the build.

This is the final part of the Accessibility Deep Dive series. If you are picking up here, start with understanding WCAG guidelines for the compliance framework, then work through accessible color and typography before applying the patterns above.

To see these principles applied to a real site, take a look at work like Delta Security Force and Detail Exchange, both built to semantic HTML and WCAG standards. For web design projects that include accessibility baked in from the start, get in touch.

Frequently asked questions

What is the first rule of ARIA?

Use native HTML elements first. A button element is better than a div with role="button" because the browser handles keyboard interaction, focus, and announcement automatically. Add ARIA only when no HTML element conveys the meaning you need.

How do screen reader users navigate a web page?

Most use headings. WebAIM’s 2024 Screen Reader User Survey found that 71.6% of respondents navigate by heading when exploring a long page. A smaller but growing share (31.8%) use landmark regions. This is why heading order and ARIA landmarks matter far more than most visual designers realize.

What alt text should a decorative image have?

An empty alt attribute (alt=""). This tells screen readers to skip the image entirely. A missing alt attribute is different: the screen reader may announce the file name instead, which creates noise. Every image needs an alt attribute; decorative images get an empty one.

What makes a form accessible to screen readers?

Each input must have a visible label element associated via the for/id pairing, or an aria-label when a visible label is not practical. Placeholder text alone does not substitute for a label: it disappears when the user starts typing and is not reliably announced by all screen readers. Error messages should be linked to their fields via aria-describedby.