Post Image

Screen Reader-Friendly Code: Best Practices

By Andrew Martin on 3rd December, 2025

    Want your website to work for everyone? Start by making it screen reader-friendly. Screen readers convert on-screen text to speech or braille, helping visually impaired users interact with your site. But poorly structured code can create barriers. Here’s how you can fix that:

    • Use semantic HTML: Stick to native elements like <button> and <header> for better assistive tech support.
    • Organize headings properly: Only one <h1> per page, no skipped levels, and logical nesting.
    • Write effective alt text: Describe images and icons clearly without overloading details.
    • Enable keyboard navigation: Ensure all interactive elements are accessible with the Tab key and have visible focus indicators.
    • Test thoroughly: Use screen readers like NVDA, JAWS, or VoiceOver to catch issues automated tools might miss.

    These steps improve accessibility for screen reader users and benefit everyone by creating a smoother, more navigable experience. Accessibility isn’t just a feature – it’s a necessity.

    How to Check Web Accessibility with a Screen Reader and Keyboard

    Use Semantic HTML Elements

    Leverage native HTML elements before turning to ARIA.
    Whenever possible, stick to native HTML elements instead of relying on ARIA roles or attributes. Native elements are easier to implement, more reliable, and widely supported by assistive technologies.

    Organize your page with landmark elements.
    Incorporate elements like <header>, <nav>, <main>, and <footer> to define distinct regions of your page. These landmarks help users, especially those using assistive technologies, navigate efficiently by creating a clear map of the page’s structure.

    Opt for semantic form elements.
    When designing forms, use elements like <button> for actions instead of styling <div> or <span> elements to look clickable. Pair <label> elements with form inputs using the for attribute to ensure clear associations, and select input types like text, email, password, checkbox, or radio to communicate the expected data type.

    Follow a logical source order.
    Structure your HTML content in a logical sequence, even if CSS visually rearranges it. Screen readers process content in the order it appears in the HTML, so maintaining a logical flow ensures users receive information in a coherent manner.

    Stick to one <h1> per page.
    Use the <h1> element exclusively for the main page title. This helps establish a clear starting point for your page’s content hierarchy and makes navigation easier for users.

    Avoid skipping heading levels.
    When nesting headings, follow a sequential order. For example, place an <h3> under an <h2> rather than skipping directly to an <h4>. Skipping levels can confuse screen reader users and disrupt the logical flow of your content.

    Craft meaningful heading text.
    Headings should clearly describe the content that follows. Think of them as guideposts for users navigating through headings – they need to be specific and informative.

    Provide descriptive page titles.
    Include a clear and meaningful <title> element in your page’s <head> section. Screen readers announce this title when the page loads, immediately giving users context about the content and purpose of the page.

    Create Proper Heading Structure

    Organizing content with proper heading structure is essential for accessibility, especially for users relying on screen readers. Unlike visual readers who can quickly scan a page’s layout, screen reader users depend entirely on the underlying code structure to navigate and understand content. This is where heading hierarchy becomes crucial – it acts as a roadmap, allowing users to move between sections, grasp relationships between topics, and form a clear mental picture of the content’s organization.

    When headings are used correctly, screen readers announce both the heading level and its text. For example, a user might hear, "Heading level 2: Keyboard Navigation", followed by, "Heading level 3: Making Elements Keyboard Accessible." This instantly communicates that the second topic is a subtopic of the first, helping users understand the content’s flow. Problems arise when developers skip heading levels or use multiple <h1> elements, disrupting this logical flow and causing confusion.

    How to Structure Headings Correctly

    Start with a single <h1> that introduces the primary topic of your page. This heading serves as the entry point for screen reader users, clearly stating what the page is about. From there, ensure all headings follow a sequential order – an <h3> should always be nested under an <h2>, which in turn falls under an <h1>. Avoid skipping levels, such as jumping from <h2> to <h4> or <h1> to <h3>, as this breaks the logical structure and can leave users disoriented.

    Think of heading levels as a content outline. For instance, if your page covers web accessibility with sections on semantic HTML, heading structure, and keyboard navigation, the structure might look like this:

    • <h1>: Web Accessibility Best Practices
      • <h2>: Semantic HTML
        • <h3>: What Are Semantic Elements?
      • <h2>: Heading Structure
        • <h3>: How to Structure Headings Correctly
      • <h2>: Keyboard Navigation
        • <h3>: Making Elements Keyboard Accessible

    Headings should also be clear and descriptive, functioning as signposts for navigation. Screen reader users often skip between headings to locate specific information, so vague titles like "Details" or "Information" are unhelpful. Instead, opt for precise headings like "Screen Reader Compatibility Guidelines" or "Keyboard Navigation Requirements", which immediately inform users about the content of the section.

    It’s important to remember that screen readers follow the HTML order, not the visual layout created by CSS. This means your heading hierarchy must make sense when read in sequence, independent of the page’s visual design.

    Heading Structure Checklist

    • Use a single <h1> and maintain proper sequence: Ensure your page has exactly one <h1> that describes the main topic, with all subsequent headings progressing logically. For example, every <h3> should have an <h2> parent, and so on.
    • Make headings relevant: Each heading should clearly describe the content it introduces. If a heading is too vague, rewrite it to provide more context.
    • Test with a screen reader: Navigate your page using heading shortcuts (commonly the "H" key) to confirm that the structure is logical and easy to follow without relying on visual cues.
    • Ensure consistency across pages: If similar sections appear on multiple pages, use the same heading structure to create a consistent experience for users.
    • Avoid using headings for styling: Headings should only be used for semantic structure. For decorative text, use CSS on elements like <p> or <span>.
    • Review source order: Check your HTML source code to confirm that headings appear in a logical order when read sequentially, even if CSS visually rearranges elements on the page.

    Write Alt Text for Images and Icons

    Writing effective alt text is a crucial step in making visual content accessible for screen reader users.

    Alt text acts as a bridge, translating visual elements into descriptive text that screen readers can interpret. Without it, screen readers simply announce "image", leaving visually impaired users without context or understanding of what the image represents. This creates a gap in the experience, as sighted users gain immediate insights from visuals that others might miss.

    By adding alt text, you provide a meaningful description of the image’s content or purpose. For instance, if an image displays a search button with a magnifying glass icon, the alt text "Search" clearly communicates the button’s function to users relying on screen readers.

    Alt text goes beyond description – it ensures that everyone receives the same information, regardless of how they interact with the content. This is especially critical for functional images, like buttons or icons, where understanding their purpose is essential for navigation and usability. Below are practical guidelines for crafting effective alt text.

    How to Write Good Alt Text

    Follow these strategies to create alt text that meets accessibility standards:

    • Be specific but concise: Keep alt text between 100–125 characters, focusing on the image’s key details without unnecessary elaboration.
    • Provide relevant context: Describe the image’s content or purpose in a way that aligns with its role in the surrounding content. For example, instead of "photo of a person", write "Sarah Johnson, UX Designer at TechCorp" if that detail is relevant.
    • Include text from images: If an image contains text, such as a screenshot or poster, include that text verbatim if it’s essential. For example, an error message in a screenshot should be included in the alt text for clarity.
    • Summarize complex visuals: For charts or graphs, offer a brief summary in the alt text, such as "Quarterly sales increased 25% from Q1 to Q4 2025", and provide full details in a linked table or description.
    • Use proper punctuation: Add commas, periods, or other punctuation to improve how screen readers interpret and present the text.
    • Match descriptions to context: Tailor the alt text to the image’s purpose. For instance, for an e-commerce product, describe key features like color, size, and style: "Blue cotton t-shirt with crew neckline, size medium."
    • Avoid redundant phrases: Skip phrases like "image of" or "picture of", as screen readers already announce the element type.

    Alt Text Checklist

    To ensure your alt text is effective and accessible, use this quick checklist:

    • Add alt attributes to all images: Every image should have an alt attribute, even if left empty for decorative visuals.
    • Keep it concise: Limit descriptions to 100–125 characters while including essential details.
    • Focus on functionality for interactive elements: For buttons or icons, describe their purpose (e.g., "Search" instead of "magnifying glass icon").
    • Use punctuation for readability: Structure alt text with proper punctuation to make it easier for screen readers to interpret.
    • Skip decorative images: Use empty alt text (alt="") for purely decorative images to avoid cluttering the screen reader experience.
    • Test with screen readers: Tools like NVDA, JAWS, or VoiceOver can help you ensure your alt text works as intended.
    • Avoid keyword stuffing: Write for users, not search engines, prioritizing accessibility over SEO.
    • Provide detailed descriptions for complex visuals: Summarize charts or infographics in the alt text and link to additional resources for more in-depth information.

    Enable Keyboard Navigation and Focus

    After addressing semantic structure and alt text, the next step in creating a screen reader-friendly experience is ensuring proper keyboard navigation. This isn’t just about making elements accessible – it’s about ensuring users can navigate and interact with your site efficiently, especially those relying on keyboards due to visual or motor impairments.

    Keyboard navigation is a cornerstone of accessibility. It’s critical for users who depend on screen readers, individuals with motor disabilities, or even those who simply prefer using a keyboard for faster navigation. Poor focus management can leave users disoriented, making essential tasks like filling out forms or navigating menus frustrating or impossible.

    Make Elements Keyboard Accessible

    The key to effective keyboard navigation is ensuring the tab order aligns with the visual and reading flow, typically left-to-right and top-to-bottom. When the source code order doesn’t match the visual layout, screen reader users can face unnecessary confusion.

    Start by using semantic HTML elements like <button>, <a>, <input>, and <select>. These elements are naturally keyboard-accessible and included in the tab order by default. But if you’re working with custom components using <div> or <span>, you’ll need to add extra code to make them accessible.

    The tabindex attribute plays a vital role in managing focus and navigation. Here’s how to use it effectively:

    • Use tabindex="0" to include elements in the natural tab order.
    • Use tabindex="-1" for elements that need programmatic focus but shouldn’t be part of the regular tab sequence.
    • Avoid positive tabindex values, as they can disrupt the natural flow and confuse users.

    For dynamic content like modal dialogs or dropdown menus, focus management is especially important. When a modal or dropdown opens, shift focus to the first interactive element. When it closes, return focus to the element that triggered it. For components like dropdown menus or autocomplete fields, arrow keys should allow users to navigate through options.

    Each interactive component has specific keyboard conventions:

    • Buttons: Activate with Enter or Space.
    • Links: Activate with Enter.
    • Form inputs: Accept text and respond to Tab for navigation.
    • Checkboxes and radio buttons: Toggle with Space.
    • Dropdown menus: Open with Enter or Space, and navigate options using arrow keys.
    • Modal dialogs: Trap focus within the dialog and close with the Escape key.

    Visual focus indicators are another must-have. These outlines or highlights show users which element currently has focus, helping them navigate confidently. If you remove the default focus indicators, be sure to replace them with something equally visible.

    Lastly, avoid creating keyboard traps. Attributes like role="presentation" or aria-hidden="true" on focusable elements can block navigation. Make sure all ARIA controls remain fully functional with a keyboard.

    Keyboard Accessibility Checklist

    Use this checklist to verify that your site supports seamless keyboard navigation:

    • Navigate the entire website using only a keyboard (Tab to move forward, Shift+Tab to move backward).
    • Ensure the tab order mirrors the visual layout and reading flow.
    • Use semantic HTML elements like <button>, <a>, and <input> for built-in keyboard functionality.
    • Confirm all interactive elements have clear, visible focus indicators.
    • Test buttons, links, form fields, dropdowns, and custom controls to ensure they respond correctly to keyboard inputs.
    • Use tabindex="0" for custom interactive elements and avoid positive tabindex values.
    • Manage focus dynamically for modals, dropdowns, and other interactive elements.
    • Verify custom keyboard shortcuts don’t conflict with screen reader, browser, or operating system shortcuts.
    • Test your implementation with popular screen readers like NVDA, JAWS, or VoiceOver.
    • Allow users to control media playback and navigation instead of automating interactions.
    • Ensure no elements trap keyboard focus, allowing users to navigate freely.
    • For custom components, implement appropriate keyboard event handlers (e.g., Enter, Space, Arrow keys, and Escape).

    Test and Validate Your Code

    You’ve taken the time to implement semantic HTML, structure your headings, write alt text, and enable keyboard navigation. Now it’s time to validate your efforts using screen readers and accessibility tools.

    Automated tools can help pinpoint technical issues like missing alt text, incorrect heading levels, or poor color contrast. However, they only catch 30-40% of accessibility problems. These tools can’t assess whether your alt text is meaningful, your reading order makes sense, or your keyboard navigation feels natural. That’s why manual testing with real screen readers is an essential step to ensure your site delivers a truly accessible experience.

    Test with Actual Screen Readers

    Testing your site with screen readers ensures that your code provides a coherent and functional experience for users who rely on assistive technology. It’s important to test across multiple screen readers to cover a range of user environments.

    The most commonly used screen readers are JAWS (Job Access With Speech), NVDA (NonVisual Desktop Access), and VoiceOver. JAWS is widely used in enterprise settings and by experienced users, while NVDA is a free, open-source option that’s gaining traction. VoiceOver is built into all Apple devices, making it the default option for Mac, iPhone, and iPad users.

    For Windows testing, NVDA is a great starting point because it’s free and easy to access. On Apple devices, VoiceOver is readily available without extra cost. For Android devices, you can use TalkBack, which is also built-in. If you need to test JAWS, trial versions or educational licenses are often available, and some web accessibility services provide temporary access to JAWS for testing.

    When testing, navigate your website using only the keyboard while the screen reader is active. Check that every element is announced correctly and that navigation feels logical and efficient.

    Make sure to test in both browse mode and focus mode. Browse mode is used for scanning content like headings and links, while focus mode handles interactive elements like forms and custom controls. Both modes should function smoothly for a seamless user experience.

    Pay particular attention to your heading structure. Most screen readers allow users to navigate between headings using shortcuts. Try navigating through your headings without reading the body text – does the structure alone provide a clear outline of your content?

    For forms, use Tab and Shift+Tab to navigate through fields. Ensure each field has an associated label that the screen reader announces when the field is focused. Test error messages by submitting invalid data and confirm that required field indicators are announced audibly, not just visually.

    For images, verify that all alt text is concise and descriptive. Avoid redundant phrases like "image of" or "picture of", as screen readers already announce the presence of an image. Ensure the alt text effectively conveys the image’s purpose in context.

    Accessibility Testing Checklist

    Here’s a checklist to guide your final testing phase:

    • Run automated accessibility audits with tools like WAVE, Axe DevTools, or Lighthouse to identify technical issues and establish a baseline.
    • Test with multiple screen readers, including NVDA (Windows), VoiceOver (Mac/iOS), and TalkBack (Android), to ensure compatibility across platforms.
    • Confirm semantic HTML, using proper tags like <header>, <nav>, <main>, <article>, and <button> instead of generic <div> elements.
    • Validate heading structure, ensuring one <h1>, no skipped levels, and clear, descriptive headings.
    • Check alt text for all images, ensuring it is concise and meaningful without redundant phrases.
    • Test keyboard navigation by navigating the site entirely with Tab, Shift+Tab, Enter, Space, Arrow keys, and Escape, ensuring all interactive elements are operable.
    • Verify focus indicators are visible and follow a logical order that matches the visual layout.
    • Test forms to confirm labels, error messages, and instructions are properly announced by screen readers.
    • Ensure language declarations are set in the HTML and that any multilingual content has the correct language tags.
    • Review ARIA usage, ensuring attributes are applied only when native HTML elements can’t achieve the same result.
    • Check source order, ensuring content reads logically when accessed sequentially.
    • Eliminate keyboard traps, ensuring users can enter and exit all elements without getting stuck.
    • Disable autoplaying media, giving users control over navigation and interactions.
    • Test in browse and focus modes to ensure smooth functionality in both contexts.
    • Conduct real user testing with screen reader users to uncover issues that automated tools and manual testing might miss.

    While automated tools are a great starting point, they’re not enough on their own. Manual testing with actual screen readers is critical to uncovering contextual and usability issues. Make accessibility testing a regular part of your development process to maintain an inclusive experience throughout your project.

    Key Takeaways

    When it comes to making your code accessible, every decision matters – especially when it comes to ensuring compatibility with screen readers. Thoughtful coding not only improves usability for screen reader users but also enhances the overall experience for everyone.

    Start with semantic HTML. Elements like <header>, <nav>, <main>, <article>, and <button> are more than just tags – they provide essential context for screen readers. For example, a <button> is inherently interactive, while a styled <div> lacks that functionality. Using the right elements ensures assistive technologies can interpret your content effectively.

    Organize with proper headings. A single <h1> followed by logically nested headings acts like a roadmap for users. Think of headings as signposts – they should clearly describe the content they introduce, helping users navigate your site with ease.

    Alt text matters. Every image needs descriptive alt text that conveys its purpose. For functional elements like buttons or icons, focus on explaining their action rather than their appearance. The goal is to provide visually impaired users with the same context and information that sighted users gain from visuals.

    Keyboard accessibility is key. Many screen reader users rely on keyboards to navigate. This means all interactive elements must be accessible via keyboard, with a logical tab order that mirrors the visual layout. Avoid hover-only actions, ensure users can enter and exit elements freely, and stick to native HTML elements like <button> and <a> for built-in keyboard functionality.

    Test thoroughly. While automated tools can catch some issues, manual testing with screen readers is essential. This ensures alt text is concise, the reading order makes sense, and keyboard navigation works smoothly. Testing across different screen readers and platforms helps confirm your code is usable for all assistive technology users.

    These strategies don’t just help screen reader users – they lead to cleaner, higher-quality code and make your content more accessible for users with cognitive disabilities or those on mobile devices. Accessibility is about breaking down barriers, and creating screen reader-friendly code is one of the most impactful steps you can take to ensure your digital content is inclusive.

    FAQs

    How can I create a heading structure that works well for both visual users and screen readers?

    To make your website’s heading structure both accessible and visually pleasing, it’s essential to maintain a clear and logical hierarchy. Use HTML heading tags like <h1>, <h2>, and <h3> in the correct order to mirror the structure of your content. This ensures screen readers can effectively communicate the page’s layout to users.

    Don’t skip heading levels or use headings just for their visual style. Instead, use CSS to adjust elements like font size or weight for design purposes. A properly organized heading structure not only boosts accessibility but also creates a smoother, more enjoyable experience for all users.

    What mistakes should I avoid when writing alt text to ensure images are accessible for screen readers?

    When crafting alt text for images, steer clear of being too vague or overly detailed. The goal is to provide a brief description that highlights the image’s purpose within the content. For instance, instead of writing "Image of a dog", a more helpful description would be "Golden retriever playing in a park", as it adds relevant context.

    Avoid starting with phrases like "image of" or "picture of", since screen readers already indicate that the content is an image. If the image is purely decorative, it’s best to leave the alt text blank by using a null alt attribute (alt=""). This ensures screen readers skip over it, allowing users to concentrate on the essential content without unnecessary interruptions.

    Why is keyboard navigation important for accessibility, and how can I test it on my website?

    Keyboard navigation plays an important role in making websites accessible. Many individuals, including those with motor disabilities or visual impairments, depend on keyboards or assistive tools like screen readers to move through online content. Ensuring your website works seamlessly with just a keyboard not only enhances usability but also aligns with accessibility guidelines.

    Want to test your site? Start by navigating it without a mouse. Use the Tab key to jump between interactive elements like links, buttons, and form fields. Check that the focus indicator (the visual cue showing where you are on the page) is easy to spot. Also, confirm that all key actions – like submitting a form or accessing a menu – can be completed using only the keyboard. For deeper insights, try using a screen reader to experience firsthand how accessible your navigation truly is.

    Related Blog Posts

    Still hungry for the design?

    UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and present from low-fidelity wireframes to fully-interactive prototypes.

    Start your free trial

    These e-Books might interest you