{"id":24663,"date":"2026-04-17T09:36:46","date_gmt":"2026-04-17T04:06:46","guid":{"rendered":"https:\/\/lollypop.terralogic.com\/?p=24663"},"modified":"2026-04-21T10:08:13","modified_gmt":"2026-04-21T04:38:13","slug":"screen-reader-testing-a-practical-guide-for-designers-developers","status":"publish","type":"post","link":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/","title":{"rendered":"Screen Reader Testing: A Practical Guide for Designers &#038; Developers"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Many websites can pass an accessibility scan and still fail real users!<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Automated reports may show no critical errors and a clean bill of health, but that does not guarantee the experience works with assistive technologies. Yet when the same product is used with a screen reader, navigation can break down quickly. Buttons may not be announced correctly, form fields may lack context, and entire sections can become difficult to interpret without visual cues.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The gap comes from how <strong><a href=\"https:\/\/lollypop.design\/blog\/2026\/april\/web-accessibility-guidelines-a-complete-guide-to-wcag-compliance-in-2026\/\" target=\"_blank\" rel=\"noopener\">accessibility<\/a> <\/strong>is evaluated. Automated tools can flag missing attributes or contrast issues, but they cannot replicate how users actually navigate content using a screen reader. These users move through headings, links, landmarks, and interactive elements in a structured, non-visual way. When the underlying semantics or interaction logic is flawed, the experience becomes fragmented, even if the interface appears correct.<\/span><\/p>\n<p><b>Screen reader testing<\/b><span style=\"font-weight: 400;\"> addresses this gap by focusing on real user interaction rather than surface-level checks. It helps teams understand whether a product is truly usable, not just technically compliant. Instead of checking for isolated issues, it reveals how content is read, how interactions flow, and whether users can complete real tasks without friction.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This guide breaks down the tools, workflows, and practical steps needed to conduct effective <\/span><a href=\"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/\"><b>screen reader testing<\/b><\/a><span style=\"font-weight: 400;\">. It also highlights the most common accessibility failures that only surface when you test with real screen reader behaviour, not just automated reports.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Let\u2019s dive into what effective screen reader testing really looks like!<\/span><\/p>\n<h2><b>Key Takeaways<\/b><\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Screen readers interpret digital interfaces by converting structured content into speech or Braille, making semantic accuracy critical.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Automated accessibility tools identify surface-level issues, but manual <\/span><b>screen reader testing<\/b><span style=\"font-weight: 400;\"> is required to evaluate real usability.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Effective testing typically involves four primary tools: <strong>NVDA, JAWS, VoiceOver, and TalkBack<\/strong>, each offering different interaction behaviours.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A reliable testing approach includes two passes: first, understanding content structure, then completing tasks using keyboard-only navigation.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Common accessibility failures include missing or unclear labels, inconsistent heading hierarchy, and broken or mismanaged keyboard focus.<\/span><\/li>\n<\/ul>\n<h2><b>What Is a Screen Reader &amp; Who Uses It?<\/b><\/h2>\n<p><span style=\"font-weight: 400;\"><strong>A screen reader<\/strong> is a tool that reads digital content aloud or converts it into Braille, a system of raised dots that can be felt with the fingers, allowing users to navigate websites and applications without relying on sight. This makes <\/span>screen reader accessibility<span style=\"font-weight: 400;\"> fundamentally dependent on how well the interface is structured beneath the surface.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The sections below explain how screen readers work in practice, who relies on them, and why implementation details directly impact usability:<\/span><\/p>\n<h3><b>What does a screen reader do?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Screen readers interpret the underlying code of a page and convert it into spoken output. They do not rely on layout, color, or visual hierarchy, but on semantic meaning and document structure.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This means a screen reader user can:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Navigate through headings to understand page structure<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Jump between links, buttons, or form fields<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Access lists, tables, and landmarks to orient themselves<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Interact with components using keyboard commands<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">For example, imagine a \u201cSubmit\u201d button that looks correct on the screen but is built using a generic <\/span><span style=\"font-weight: 400;\">&lt;div&gt;<\/span><span style=\"font-weight: 400;\"> instead of a real button. A screen reader may not recognize it as something clickable. Instead of hearing \u201cSubmit button,\u201d the user might just hear \u201cSubmit\u201d or nothing at all, making it unclear that an action is possible.<\/span><\/p>\n<h3><b>Who uses screen readers?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Screen readers are used by a wide range of people, each interacting with content differently depending on their needs and context.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Blind users<\/b><span style=\"font-weight: 400;\"> rely on screen readers as their primary way to navigate digital products<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Low-vision users<\/b><span style=\"font-weight: 400;\"> may combine screen readers with magnification or high-contrast settings<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Users with motor impairments<\/b><span style=\"font-weight: 400;\"> often depend on keyboard navigation alongside screen readers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Users with certain cognitive disabilities<\/b><span style=\"font-weight: 400;\"> may use screen readers to simplify and linearize content<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">This diversity is important. Screen reader usage is not limited to a single user group or scenario. The same interface must support different navigation patterns, speeds, and expectations.<\/span><\/p>\n<h3><b>Why semantic HTML and ARIA matter<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Screen readers rely on code, not visuals. They need clear signals to understand what each element is and how users can interact with it.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><strong><a href=\"https:\/\/web.dev\/learn\/html\/semantic-html\" target=\"_blank\" rel=\"noopener\">Semantic HTML<\/a><\/strong> provides these signals. Elements like <\/span><span style=\"font-weight: 400;\">&lt;button&gt;<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">&lt;nav&gt;<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">&lt;form&gt;<\/span><span style=\"font-weight: 400;\">, and headings tell the screen reader exactly what something is. When used correctly, users hear clear, actionable information.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><strong><a href=\"https:\/\/www.w3.org\/WAI\/standards-guidelines\/aria\/\" target=\"_blank\" rel=\"noopener\">ARIA<\/a> <\/strong>is used only when standard HTML is not enough, such as in custom components like modals or dropdowns. It helps define roles and states, but it should not replace proper structure.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If the structure is unclear or incorrect, the screen reader cannot interpret the interface properly. As a result, users may miss actions, lose context, or be unable to complete tasks, even if everything looks correct visually.<\/span><\/p>\n<h2><b>Why Screen Reader Testing Matters<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Accessibility issues are often treated as isolated checks. Teams run automated scans, fix flagged errors, and assume the experience is usable. In reality, passing these checks does not guarantee that a user can navigate or complete tasks with a screen reader.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The difference lies in what is being evaluated. Automated tools focus on code-level compliance, while <\/span><b>screen reader testing<\/b><span style=\"font-weight: 400;\"> reveals how the product actually behaves in use.<\/span><\/p>\n<h3><b>1. It reveals real usability issues, not just technical errors<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Automated tools can detect missing alt text, labels, or contrast issues, but they cannot determine whether users can understand the content or complete a task. Screen reader testing exposes problems such as confusing reading order, unclear link text, or broken navigation flows that only become apparent during real interaction.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For example, a page may pass all checks, but a screen reader reads content in the wrong order, causing instructions to appear after the form fields.<\/span><\/p>\n<h3><b>2. It validates whether users can complete critical tasks<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Accessibility is not only about content being readable. Users need to perform actions such as filling out forms, navigating menus, or completing a checkout. Screen reader testing ensures these flows work end-to-end using keyboard navigation and assistive technology, not just visually.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For example, a checkout form may look complete, but without proper labels, a user hears \u201cEdit, blank\u201d instead of \u201cEmail address,\u201d making it impossible to proceed confidently.<\/span><\/p>\n<h3><b>3. It ensures accessibility works in practice, not just in code<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">A product can be technically compliant with accessibility guidelines and still fail users. Screen reader testing bridges this gap by evaluating the actual experience. It confirms that structure, semantics, and interactions work together to create a usable interface.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For example, a dropdown menu may meet code standards, but if keyboard focus does not move correctly, a user cannot access all options.<\/span><\/p>\n<h2><b>The 4 Main Screen Readers to Test With<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Choosing the right tools is a key part of effective <\/span><b>screen reader testing<\/b><span style=\"font-weight: 400;\">. Different screen readers interpret the same interface in slightly different ways, which means relying on a single tool can leave gaps in your testing coverage.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The tools below represent the most widely used screen readers across desktop and mobile environments:<\/span><br>\n<img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/5de78a59-artwork-1-1-1.webp\" alt=\"The 4 Main Screen Readers to Test With\" width=\"1440\" height=\"710\" style=\"aspect-ratio:1440\/710;\"><\/p>\n<h2><b>How to Conduct Screen Reader Testing Step by Step<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Using a screen reader is fundamentally different from using a visual interface. Instead of scanning layouts or clicking with a mouse, users rely entirely on what is announced through audio.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">During <\/span><b>screen reader testing<\/b><span style=\"font-weight: 400;\">, do not use a mouse. Rely only on what you hear. If something is not announced, it does not exist for the user.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Testing typically follows two passes:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\"><strong>Pass 1:<\/strong> Read and understand all content<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\"><strong>Pass 2:<\/strong> Navigate and interact with elements to complete tasks<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Use a real screen reader such as NVDA (Windows), JAWS, or VoiceOver. The steps below use NVDA for accessibility testing:<\/span><br>\n<img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/9a808747-artwork-2-1-1.webp\" alt=\"Screen Reader Testing Step by Step\" width=\"1440\" height=\"650\" style=\"aspect-ratio:1440\/650;\"><\/p>\n<h3><b>Step 0: Launch and prepare the screen reader<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Before testing, you need to set up the environment exactly as a screen reader user would experience it. This step ensures that NVDA is running correctly, the page is loaded fresh, and your starting point is consistent.<\/span><\/p>\n<p><strong>Start NVDA:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NVDA: Ctrl + Alt + N<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Adjust speech rate to a comfortable level (fast enough to scan, slow enough to understand)<\/span><\/li>\n<\/ul>\n<p><strong>Prepare the page:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Open the page you want to test in the browser<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Click into the browser address bar and press Enter to reload the page<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Do not use the mouse after this point<\/span><\/li>\n<\/ul>\n<p><strong>Set the correct starting position:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Press Ctrl + Home to move to the top of the page<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure NVDA starts reading from the beginning<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">This setup is important because screen reader testing depends on a consistent starting state. If the page is not reloaded or focus is not at the top, the reading order and behavior may not reflect the real user experience.<\/span><\/p>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Is the screen reader starting from the very beginning of the page, with no leftover focus or interaction state?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, reload the page and reset focus before continuing, as an incorrect starting point can invalidate the entire test.<\/span><\/p>\n<h3><b>Step 1: First pass \u2014 read through content<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">This step focuses on understanding how the page is presented to a screen reader user without interaction. The goal is to evaluate whether the content, when read linearly, forms a clear and complete experience. At this stage, you are not trying to use the interface, only to understand it as a continuous flow of information.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Use the Down Arrow key in NVDA to read line by line, starting from the top of the page. Listen carefully to how each piece of content is announced and how it connects to the next.<\/span><\/p>\n<p><strong>Check:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Page title is announced clearly<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">All visible text is read<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Headings are announced with correct levels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Lists are announced as lists<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Images have meaningful alt text (or are skipped if decorative)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Tables are announced with a structure<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Content is read in a logical order<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Can I clearly understand the page without seeing it?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Check heading tags (H1\u2013H6) and fix incorrect hierarchy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure all visible text exists in the DOM (not hidden visually only)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add or correct semantic HTML so content is announced properly<\/span><\/li>\n<\/ul>\n<h3><b>Step 2: Explore structure and navigation<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Once the content is readable, the next step is to evaluate how users move through it. Screen reader users rarely read everything sequentially. Instead, they rely on headings, landmarks, and shortcuts to scan and jump between sections.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Using NVDA, navigate the page using structural shortcuts rather than reading line by line. This helps simulate how users quickly orient themselves and locate relevant content.<\/span><\/p>\n<p><strong>Use NVDA shortcuts:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">H \u2192 jump through headings<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">D \u2192 move between landmarks<\/span><\/li>\n<\/ul>\n<p><strong>Check:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Headings form a clear hierarchy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Landmarks (navigation, main, footer) exist<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Links make sense out of context<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Can I quickly understand how the page is organized and move between sections?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add or fix heading levels to create a clear hierarchy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Define landmarks using semantic tags (nav, main, footer)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Rewrite unclear link text to be meaningful out of context<\/span><\/li>\n<\/ul>\n<h3><b>Step 3: Second pass \u2014 navigate interactive elements<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">After understanding content and structure, shift to interaction. This step evaluates whether users can operate the interface using keyboard navigation and whether each element communicates its purpose clearly.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Return to the top of the page and begin navigating using the Tab key while NVDA is running. As you move through each element, focus on how it is announced and whether its purpose is clear without visual support.<\/span><\/p>\n<p><strong>Check:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">All links and buttons are reachable<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Elements are announced with role and label<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Focus order is logical<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">No keyboard traps<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Do I know what each interactive element does just from what I hear?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add accessible labels (aria-label or visible text)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure correct roles are applied (button, link, etc.)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Fix focus order using proper DOM structure and tabindex where needed<\/span><\/li>\n<\/ul>\n<h3><b>Step 4: Test forms and inputs<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Forms are one of the most common points of failure in accessibility. This step focuses on whether users can understand what is required, input information correctly, and receive feedback at the right time.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Navigate through form fields using the keyboard and listen carefully to how each field is announced in NVDA. Pay attention to whether the label, role, and state are communicated clearly before interaction.<\/span><\/p>\n<p><strong>Check:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Labels are announced before fields<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Required fields are indicated<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Input types are clear<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Errors are announced<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">In NVDA, a correct field should sound like:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u201cEmail, edit field\u201d<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Can I complete this form confidently without guessing?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Associate labels with inputs using or aria-labelledby<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add clear instructions and required indicators<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure error messages are programmatically linked and announced<\/span><\/li>\n<\/ul>\n<h3><b>Step 5: Test dynamic and interactive components<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Modern interfaces rely heavily on dynamic behavior such as modals, dropdowns, and real-time updates. This step checks whether these interactions are properly communicated through the screen reader, especially when content changes without a full page reload.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Trigger interactive components using the keyboard and observe how NVDA responds. Focus on how state changes, focus movement, and updates are announced.<\/span><\/p>\n<p><strong>Check:<\/strong><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Focus moves into modals when opened<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">You can navigate inside components<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Escape closes components<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Updates (errors, alerts) are announced<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Do I know when something changes on the screen?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Use ARIA live regions (aria-live) for dynamic updates<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure focus moves to newly opened components<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add proper roles and states for interactive elements<\/span><\/li>\n<\/ul>\n<h3><b>Step 6: Complete real user tasks<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">After validating individual elements, test complete user journeys. This step ensures that the experience works end-to-end, not just in isolated parts. It reflects how real users interact with the product to achieve specific goals.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Using NVDA, attempt realistic tasks from start to finish without relying on visual cues. Pay attention to where the flow slows down, becomes confusing, or breaks entirely.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Examples:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Submit a form<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Search and view results<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add items to cart<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Can I complete this task from start to finish without getting lost?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Trace the exact step where the task fails<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Fix labels, feedback, or navigation at that step<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Retest the full flow to ensure continuity<\/span><\/li>\n<\/ul>\n<h3><b>Step 7: Retest after fixes<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Accessibility testing is not a one-time activity. Fixing one issue can impact other parts of the experience, especially in complex interfaces where components are interconnected.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">After making updates, repeat the same testing steps using NVDA to ensure that the original issue is resolved and that no new issues have been introduced.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">After fixes:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repeat all steps<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Confirm issues are resolved<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ensure no new issues appear<\/span><\/li>\n<\/ul>\n<p><b>Ask yourself:<\/b><span style=\"font-weight: 400;\"> Is the experience now consistent and predictable after the fix?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If not, take these actions:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Re-run each step systematically to isolate the issue<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Compare the before and after behaviour in NVDA<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Fix regressions before moving forward<\/span><\/li>\n<\/ul>\n<h2><b>Automated vs Manual Screen Reader Testing<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Accessibility testing often combines both automated tools and manual validation. While they are frequently used together, they serve very different purposes. Understanding this distinction helps teams avoid over-relying on automated reports and missing critical usability issues.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The comparison below highlights how each approach contributes to screen reader accessibility testing:<\/span><\/p>\n<p><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/37fa8b58-artwork-3-1.webp\" alt=\"Automated vs Manual Screen Reader Testing\" width=\"1440\" height=\"950\" style=\"aspect-ratio:1440\/950;\"><\/p>\n<h2><b>Most Common Screen Reader Accessibility Failures<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Many accessibility issues are not caused by complex interactions, but by small implementation gaps that break how content is announced. These failures often go unnoticed in visual reviews but become immediately apparent when tested with a screen reader.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The issues below represent the most common patterns that impact <\/span><b>screen reader accessibility<\/b><span style=\"font-weight: 400;\"> and prevent users from navigating or completing tasks effectively:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Missing or meaningless alt text<\/b><span style=\"font-weight: 400;\">: Images without alt text are either skipped or announced as \u201cgraphic\u201d with no context. If the alt text exists but is vague, users still cannot understand what the image conveys.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Form fields without labels<\/b><span style=\"font-weight: 400;\">: When inputs are not properly labelled, screen readers cannot associate them with their purpose. Users may hear \u201cEdit, blank\u201d instead of a meaningful label like \u201cEmail address.\u201d<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Broken heading structure<\/b><span style=\"font-weight: 400;\">: Headings define how users navigate a page. Skipping levels or using them inconsistently makes it difficult to scan and understand content.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Non-descriptive links<\/b><span style=\"font-weight: 400;\">: Links such as \u201cClick here\u201d or \u201cLearn more\u201d lack context when read in isolation. Screen reader users often navigate via link lists, so each link must clearly describe its destination.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Keyboard focus traps in menus and modals<\/b><span style=\"font-weight: 400;\">: Users can get stuck when focus does not move correctly. This prevents them from exiting components or accessing other parts of the page.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Custom controls without semantic roles or ARIA<\/b><span style=\"font-weight: 400;\">: Custom components without proper roles or ARIA attributes are not announced correctly. Users may not know if an element is interactive or how to use it.<\/span><\/li>\n<\/ul>\n<h2><b>Conclusion<\/b><\/h2>\n<p><span style=\"font-weight: 400;\"><strong>Screen reader testing<\/strong> is not an optional layer added at the end of development. It is a critical part of evaluating whether a product actually works for users who rely on assistive technologies. While automated tools help identify surface-level issues, they cannot determine whether users can successfully navigate, understand, and complete tasks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">By incorporating screen reader testing into regular workflows, teams can identify structural issues early, validate interaction patterns, and ensure that accessibility is built into the product rather than fixed later. Testing with tools like NVDA or VoiceOver enables a non-visual experience of the interface and helps uncover issues that would otherwise go unnoticed.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For product teams, this shifts accessibility from a checklist to a design and engineering practice. It influences how components are structured, how interactions are defined, and how quality is validated before release.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As a UI\/UX design agency,<\/span><a href=\"https:\/\/lollypop.design\/ui-ux-design-agency-vietnam-vie\/\" target=\"_blank\" rel=\"noopener\"><b> Lollypop Design Studio<\/b><\/a><span style=\"font-weight: 400;\"> focuses on creating products that are usable, scalable, and aligned with accessibility best practices. By considering accessibility early in the design process, teams can build interfaces that are easier to navigate, more consistent across platforms, and better suited to real user needs.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If you are evaluating your product\u2019s accessibility or planning improvements, you can <\/span><a href=\"https:\/\/lollypop.design\/project-enquiry\/\" target=\"_blank\" rel=\"noopener\"><b>schedule a consultation<\/b><\/a><span style=\"font-weight: 400;\"> with our team to identify gaps and define a clear path forward.<\/span><\/p>\n<h2><b>Frequently Asked Questions (FAQs)<\/b><\/h2>\n<h3><b>1. What is screen reader testing?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Screen reader testing is the process of using a screen reader to test website with screen reader to evaluate how a website or application is announced and navigated without visual cues.\u00a0 It focuses on whether users can understand content, navigate structure, and complete tasks using audio feedback.<\/span><\/p>\n<h3><b>2. Which screen reader is best for accessibility testing?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">There is no single best tool. NVDA is widely used for Windows and is a strong starting point because it is free and reliable. VoiceOver is essential for testing Apple devices, while JAWS is commonly used in enterprise environments. Testing with at least one desktop and one mobile screen reader is recommended.<\/span><\/p>\n<h3><b>3. What is the difference between NVDA and JAWS?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">NVDA is a free, open-source screen reader for Windows, while JAWS is a paid tool with advanced features and strong adoption in enterprise and compliance-driven environments. Both are widely used, but JAWS is often required in regulated industries.<\/span><\/p>\n<h3><b>4. How can I test my website with a screen reader online?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Some platforms offer remote testing environments, but the most effective testing is done locally using tools like NVDA or VoiceOver. This allows you to interact with your product directly and evaluate real user behaviour.<\/span><\/p>\n<h3><b>5. How often should screen reader testing be performed?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Screen reader testing should be performed during key stages such as design validation, development, and QA. It is especially important before major releases, redesigns, or when introducing new features.<\/span><\/p>\n<h3><b>6. Can automated accessibility tools replace manual screen reader testing?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">No, automated tools are effective for identifying code-level issues such as missing labels or contrast problems, but they do not reflect how users actually experience a product. Manual screen reader testing is necessary to evaluate navigation, comprehension, and task completion in real use. In practice, both approaches should be used together: automated testing for coverage and efficiency, and manual testing to validate real usability.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Many websites can pass an accessibility scan and still fail real users! Automated reports may show no critical errors and a clean bill of health, but that does not guarantee the experience works with assistive technologies. Yet when the same product is used with a screen reader, navigation can break down quickly. Buttons may not [&hellip;]<\/p>\n","protected":false},"author":9,"featured_media":24665,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[16,5],"tags":[],"blogs_category":[26,27,25],"class_list":["post-24663","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-april","category-blogs","blogs_category-banner-blog","blogs_category-blogs","blogs_category-top-blogs"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v25.9 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Screen Reader Testing: A Practical Guide for Designers &amp; Developers - Lollypop<\/title>\n<meta name=\"description\" content=\"Learn how to conduct effective screen reader testing with NVDA, VoiceOver, and more. Discover tools, step-by-step workflows, and common accessibility issues to fix.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Screen Reader Testing: A Practical Guide for Designers &amp; Developers - Lollypop\" \/>\n<meta property=\"og:description\" content=\"Learn how to conduct effective screen reader testing with NVDA, VoiceOver, and more. Discover tools, step-by-step workflows, and common accessibility issues to fix.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/\" \/>\n<meta property=\"og:site_name\" content=\"Lollypop\" \/>\n<meta property=\"article:published_time\" content=\"2026-04-17T04:06:46+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-04-21T04:38:13+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp\" \/>\n\t<meta property=\"og:image:width\" content=\"1461\" \/>\n\t<meta property=\"og:image:height\" content=\"942\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/webp\" \/>\n<meta name=\"author\" content=\"Charishma Singh\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Charishma Singh\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"16 minutes\" \/>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Screen Reader Testing: A Practical Guide for Designers & Developers - Lollypop","description":"Learn how to conduct effective screen reader testing with NVDA, VoiceOver, and more. Discover tools, step-by-step workflows, and common accessibility issues to fix.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/","og_locale":"en_US","og_type":"article","og_title":"Screen Reader Testing: A Practical Guide for Designers & Developers - Lollypop","og_description":"Learn how to conduct effective screen reader testing with NVDA, VoiceOver, and more. Discover tools, step-by-step workflows, and common accessibility issues to fix.","og_url":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/","og_site_name":"Lollypop","article_published_time":"2026-04-17T04:06:46+00:00","article_modified_time":"2026-04-21T04:38:13+00:00","og_image":[{"width":1461,"height":942,"url":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp","type":"image\/webp"}],"author":"Charishma Singh","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Charishma Singh","Est. reading time":"16 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#article","isPartOf":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/"},"author":{"name":"Charishma Singh","@id":"https:\/\/lollypop.design\/#\/schema\/person\/1ad57f626111d7fa07a44fc397ea62c7"},"headline":"Screen Reader Testing: A Practical Guide for Designers &#038; Developers","datePublished":"2026-04-17T04:06:46+00:00","dateModified":"2026-04-21T04:38:13+00:00","mainEntityOfPage":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/"},"wordCount":3262,"publisher":{"@id":"https:\/\/lollypop.design\/#organization"},"image":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#primaryimage"},"thumbnailUrl":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp","articleSection":["april","blogs"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/","url":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/","name":"Screen Reader Testing: A Practical Guide for Designers & Developers - Lollypop","isPartOf":{"@id":"https:\/\/lollypop.design\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#primaryimage"},"image":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#primaryimage"},"thumbnailUrl":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp","datePublished":"2026-04-17T04:06:46+00:00","dateModified":"2026-04-21T04:38:13+00:00","description":"Learn how to conduct effective screen reader testing with NVDA, VoiceOver, and more. Discover tools, step-by-step workflows, and common accessibility issues to fix.","breadcrumb":{"@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#primaryimage","url":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp","contentUrl":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/4fe33a7d-banner-3-1-1.webp","width":1461,"height":942},{"@type":"BreadcrumbList","@id":"https:\/\/lollypop.design\/blog\/2026\/april\/screen-reader-testing-a-practical-guide-for-designers-developers\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lollypop.design\/"},{"@type":"ListItem","position":2,"name":"Screen Reader Testing: A Practical Guide for Designers &#038; Developers"}]},{"@type":"WebSite","@id":"https:\/\/lollypop.design\/#website","url":"https:\/\/lollypop.design\/","name":"Lollypop","description":"Designing Human-Centered Digital Experiences.","publisher":{"@id":"https:\/\/lollypop.design\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/lollypop.design\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/lollypop.design\/#organization","name":"lollypop","url":"https:\/\/lollypop.design\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lollypop.design\/#\/schema\/logo\/image\/","url":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/2022\/01\/lollypop-new-logo-2.jpg","contentUrl":"https:\/\/storage.googleapis.com\/websiteasset\/uploads\/2022\/01\/lollypop-new-logo-2.jpg","width":350,"height":226,"caption":"lollypop"},"image":{"@id":"https:\/\/lollypop.design\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/lollypop.design\/#\/schema\/person\/1ad57f626111d7fa07a44fc397ea62c7","name":"Charishma Singh","sameAs":["https:\/\/lollypop.design\/"],"url":"https:\/\/lollypop.design\/author\/charishma\/"}]}},"_links":{"self":[{"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/posts\/24663","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/comments?post=24663"}],"version-history":[{"count":0,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/posts\/24663\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/media\/24665"}],"wp:attachment":[{"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/media?parent=24663"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/categories?post=24663"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/tags?post=24663"},{"taxonomy":"blogs_category","embeddable":true,"href":"https:\/\/lollypop.design\/wp-json\/wp\/v2\/blogs_category?post=24663"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}