Screen Reader Compatibility

A quiet win worth naming: Anthropic has shipped real accessibility improvements to the Claude desktop app, and as a screen reader user, I noticed them within minutes. The message history now has a proper heading structure, so I can jump between messages the way I'd navigate any well-built page — instead of arrowing line by line through a wall of text. Streaming responses now announce as complete messages rather than firing off partial, half-formed chunks. Anyone who's used a chat interface where JAWS reads "The quick brown—" and then re-reads "The quick brown fox jumps over—" every time a new token lands knows exactly how much friction that removes. The detail that really landed for me, though: I'd previously set up a custom instruction asking Claude to manually inject a "Claude Says" heading at the top of every response, just to have some way to navigate between messages. Today I had to go turn that off — because the app now provides proper headings natively, and my old workaround was producing duplicates. That's the mark of a real fix: when the scaffolding you built to cope is no longer necessary. Thank you to whoever championed this work internally at Anthropic. One friendly suggestion: consider calling out accessibility improvements in your release notes, or standing up a dedicated accessibility changelog. I couldn't find these specific changes documented anywhere. When improvements are invisible — as most screen reader improvements tend to be — users benefit from knowing they exist. Has anyone else noticed recent accessibility improvements in Claude, or any other AI tools you use? #Accessibility #A11y #ScreenReaders #InclusiveDesign #AI

Inaccessibility is all around us - but sometimes we’re doing it without even realising. I’ve made every one of these mistakes in the past. It wasn’t until someone took the time to point them out that I learned how inaccessible I was being - despite having good intentions. Here are 5 ways you might be being inaccessible, without even knowing: 1. Long LinkedIn headlines or overuse of emojis. Screen reader users hear your full headline every single time you post or comment. Every. Single. Time. Even when it’s truncated visually. That can mean hearing your full job title, emojis, and taglines multiple times before even reaching your post content. Try to keep your headline under 100 characters or two lines max - it makes a huge difference. 2. Long email signatures, HTTP links, and unlabelled images. Screen readers will read out every line - including things like “H-T-T-P-colon-slash-slash…” for full URLs. Images without alt text are completely invisible to screen reader users. Keep it short and simple, and use alt text wherever you can. Put only essential info in your email signature and put two dashes at the top to signal your signature is starting. And remember, it’s not your marketing tool. When was the last time you actually bought something from an email signature?! 3. Not running documents through the accessibility checker. You run a spell check, so why not an acceeeibility check? It’s a quick step, but it can flag things like heading structures, contrast issues, and missing image descriptions. It takes seconds and makes a big impact. 4. Using colour alone to convey meaning. For example, “I’ve marked the important cells in green” doesn’t help if someone can’t perceive colour easily. Neither does “I’ve shaded the cells for our RAG status”. Always add a label, icon, or another indicator. 5. Using all lowercase hashtags. #thisisnotaccessible - screen readers can’t parse where one word ends and another begins. Use camel case instead - #ThisIsAccessible - so screen readers pronounce the words correctly. Small changes, big impact. If you’ve made some of these mistakes before - welcome to the club. We learn, we improve, we do better. #DisabilityInclusion #Disability #DisabilityEmployment #Adjustments #DiversityAndInclusion #Content #A11y

Use Skip Links For Accessibility. What they are and why they matter for better accessibility and screen reader UX ↓ 🤔 Keyboard users struggle with long, complex pages. 🤔 It can take minutes to tab through to relevant content. ✅ “Skip links” help people bypass repetitive sections. ✅ They can be visible at all times (e.g. top of the page). ✅ But must be visible when a user hits “Tab” first time. 🤔 30.2% of screen reader users use skip links frequently. ✅ First, find main content areas that users navigate to. ✅ Use “Skip to main content” to hint where they jump to. ✅ Consider keyboard shortcuts to jump to critical areas. ✅ You still need HTML landmarks for accessible navigation. Many products have complex navigation, filters and language selectors that usually come before any useful content on the page. It’s manageable for people who can visually skim the page and navigate with a mouse. In fact, that’s why people often scroll down immediately after entering a page. But for people who rely on keyboard or use a screen reader, it’s a slow, repetitive and frustrating experience. With a keyboard alone, you need to tab through every individual link, one by one, before you get to the content of the page. And it’s especially disorienting for people who have poor vision. A simple way to fix it is to design “skip links”. They allow people to skip repetitive content and navigate directly to the content they want to interact with. To do that, we place a skip link as the first focusable element on the page, and make it visible on keyboard focus — when a user hits the “Tab” key for the first time. In fact, WCAG 2.1 (referenced by European Accessibility Act) requires a way to bypass repetitive content on a page. It can either be always visible, or become visible when it receives keyboard focus. “Skip links” achieve just that. They are very underrated, but very helpful — for everyone, but especially for people who rely on them every day to navigate complex pages faster. Skip Links in Design Systems: Axa: https://lnkd.in/eCp_Wi8b Gov.uk: https://lnkd.in/eFR94GS8 Red Hat: https://lnkd.in/enyADa_T Orange: https://lnkd.in/e895KaeK Scottish Government: https://lnkd.in/ekH78P5V Skyscanner: https://lnkd.in/eUhJ2Sb7 Useful resources: A Practical Guide To Skip Links, by Darren Lee https://lnkd.in/e-Weqsxs Web Accessibility Guide: Skip Links https://lnkd.in/e6tSPmPA How To Implement Skip Links ↳ https://lnkd.in/eK6a7UDZ ↳ https://lnkd.in/efcJJgm6 Keyboard-Only Navigation, by Marieke McCloskey https://lnkd.in/eXKtBsNU #ux #accessibility

Here's something you might not know about ChatGPT's Atlas browser: it navigates websites the exact same way screen readers do. This fundamentally changes the conversation around website accessibility. It's not just about compliance anymore (though that's still critical with the European Accessibility Act deadline hitting in June 2025). Now it's also about whether AI agents can actually navigate your website. Many websites have some ARIA tags implemented, but they aren't implemented correctly in many cases. For example a drop down might have aria-expanded="false" but it's missing the JavaScript to update it to "true" when the dropdown opens. Visually it looks perfect. For Atlas and screen readers, that dropdown is permanently stuck in the collapsed state. And those accessibility widgets that promise instant compliance? Not true. Over 1,000 companies with widgets installed got sued in 2024. Courts are increasingly rejecting widget-only implementations because they mask problems instead of fixing them. The reality is that proper ARIA implementation takes real work. We're talking 20-40 hours minimum just for critical elements like main navigation and primary forms. It's expensive, it's time consuming, and there's no shortcut. But here's why it matters: you're not just implementing for Atlas or for compliance. You're positioning your website for however AI tools evolve next, while also making your site genuinely accessible. I break down how Atlas actually uses ARIA to navigate, what to prioritize first, and how to audit your current implementation in the full article. #WebAccessibility #ARIA #DigitalMarketing

Inclusive design is not just about the font you choose. It is about how your content behaves when it meets a different nervous system. Last week, we pruned your typography. This week, we are looking at the soil. We are auditing your media and structure. In our rush for "engagement," corporate communications often rely on visual shortcuts like flashing GIFs, color-coded alerts, and walls of emojis. Marketing calls these "hacks." I call them Barriers. When you rely on a color change to signal "danger," you lock out the colorblind. When you replace words with a string of emojis, you create chaos for a screen reader user (hearing "Face with tears of joy" five times in a row). When you post a video without captions, you tell the Deaf and Auditory Processing communities that they are not your audience. Accessibility is not a "feature" for a minority group. It is an indicator of Organizational Health. If your content requires perfect vision, perfect hearing, and neurotypical processing speed to understand... your content is flawed. Below is The Inclusive Content Audit (Part 2). We moved beyond fonts to look at media, structure, and interaction. Here are 9 Ways to Operationalize Inclusion in your content: 1. The Emoji Restraint ❌ Barrier: Emojis read aloud via screen readers as clunky descriptions. ✅ Fix: Use clear words to convey tone. Keep emojis at the end of sentences rather than in the middle. 2. The Caption Mandate ❌ Barrier: Audio/Video posted "naked." ✅ Fix: Burned-in open captions. (This helps ADHD brains like mine focus just as much as it helps Deaf users). 3. The Contrast Rule ❌ Barrier: Text over busy, semi-transparent backgrounds. ✅ Fix: Solid color backgrounds behind text blocks to reduce visual noise. 4. The "Color + Shape" Rule ❌ Barrier: Using only color to convey meaning (e.g., Red = Error). ✅ Fix: Pair color with a distinct shape or icon label. 5. The Alt-Text Discipline ❌ Barrier: Images with file names like "IMG_5920.jpg". ✅ Fix: Descriptive, concise Alternative Text. 6. The Header Hierarchy ❌ Barrier: Manually bolding text to look like a header. ✅ Fix: Using actual "Heading Styles" (H1, H2) so screen readers can navigate the structure. 7. The Motion Control ❌ Barrier: Auto-playing GIFs or flashing content. ✅ Fix: Static images or user-controlled "Play" buttons. (Protect your team from vestibular triggers). 8. The Data Summary ❌ Barrier: Complex charts with no text explanation. ✅ Fix: A simple text summary beneath the visual. 9. The Permanent Label ❌ Barrier: Form field labels that disappear once you start typing. ✅ Fix: Labels that remain visible above the field. (Reduces cognitive load and working memory strain). The Verdict: Low-friction content is high-impact content. Stop making your audience fight your design to get to your message. #Accessibility #InclusiveDesign #WCAG #Neurodiversity #Leadership #ClinicalStrategy

Writing good alt text sounds simple until you actually try Every time I prepare an alternative text for my images, I hesitate at first and ask myself several questions: · How detailed should I be? · Do I describe colors, emotions, or just the main idea? · Is there a limit to how long it should be? Creating effective alternative text is definitely not easy. Because it’s not just about describing an image, it’s about communicating its purpose and meaning. Studies about importance of alt text: · “Why is alt text important?” by RNIB explains how alt text enables access to images for 2.2 billion people with sight loss and why it matters for accessibility and equality (the link: https://lnkd.in/er7brMUV) · “Communicating Visualizations without Visuals: Investigation of Visualization Alternative Text for People with Visual Impairments” is a user-study showing how alt text for complex visuals like charts must go beyond description and help users build mental models (the link: https://lnkd.in/eUDPHkug) According to WCAG 2.2 (Success Criterion 1.1.1 – Non-text Content, the link: https://lnkd.in/eZjVn7Bk), every meaningful image must have a text alternative that serves the same purpose. But WCAG doesn’t tell you exactly how to write that and that’s where many teams struggle. Rules that I use for writing accessible alt text: 1️⃣ Focus on purpose, not appearance. Ask yourself: why is this image here? What does it add? For example: instead of “woman smiling,” write “customer happy after receiving support.” 2️⃣ Be concise, but complete. Alt text should be short (under ~125 characters) unless detail adds value. Use extended text (a caption or description link) for complex visuals like charts. 3️⃣ Skip “image of” or “picture of.” Screen readers already announce the element as an image. Start with what matters. 4️⃣ Describe information, not decoration. If the image adds no essential meaning, use empty alt (alt="") so it’s ignored by assistive tech. 5️⃣ Include text that’s in the image. If the image shows visible text (e.g., a button labeled “Donate”), include it in your alt text or page content. 6️⃣ Mention color only when it’s meaningful. Say “red warning icon” if color conveys status — but not “blue background.” 7️⃣ Adapt to context. The same image can need different alt text in different contexts. Describe what’s relevant to that specific page, post or message. 8️⃣ Test with real users and assistive tech. Listen to your alt text with a screen reader (NVDA, VoiceOver, JAWS). Ask youself: does it make sense in context, without visuals? Good alt text is about describing the right things with empathy, clarity, and purpose, because accessibility is about communication. #WebAccessibility #AltText #InclusiveDesign #A11y #AccessibilityEducation #WCAG #DigitalInclusion

If you build courses in #Storyline, here’s an accessibility pitfall that shows up more often than you’d think. I keep seeing modals where the Close button looks like it’s part of the dialog, but it’s actually sitting on the base layer underneath. Visually it feels fine, but for screen reader and keyboard users, it’s like seeing a button through glass. You can see it, you can point at it, but you can’t reach it from inside the dialog. Here’s what’s really happening: Storyline exposes the layer as a dialog and moves focus into it, but the Close button isn’t actually inside that dialog layer. The keyboard is trapped in the dialog until the user tabs out of it. That might be seemless for a keyboard-only user, but for a screen reader user in Browse Mode, we get completely stuck until we guess that the magic fix is to press the tab key to escape. That breaks the entire modal experience and creates WCAG failures around focus order, operability, and keyboard traps. The fix is simple: move the Close button into the dialog layer instead of placing it visually on top. Once it actually belongs to the modal, everything works the way learners expect. The button appears in the dialog’s tab order, screen readers announce it correctly, focus stays inside the dialog, and learners can exit confidently. If you’re building accessible Storyline content, remember: visual positioning isn’t structure. A button sitting on top of a modal isn’t the same as a button belonging to it. So remember to use your Layers panel to arrange things where they belong. Your users will thank you. Or maybe not. But at least they won't curse you, which is pretty cool too. #InclusiveDesign   #A11yTips #LearningDesign

AI coding tools have an accessibility problem. I decided to fix it. I am a screen reader user and accessibility specialist. I use Claude Code every day to build apps at Techopolis LLC. And every day, I have to fight for the fundamentals. Labeled inputs. Focus trapping. Semantic HTML. Contrast ratios. Live regions. These are not advanced requirements. They are the basics. And AI drops them constantly. I tried writing detailed instructions. I tried custom skills. I tried adding reminders to every prompt. None of it stuck. As conversations grow, the model deprioritizes accessibility. Every time. So I built something different. Six specialized AI agents, each with one focused job it cannot ignore. An ARIA Specialist. A Modal Specialist. A Contrast Master. A Keyboard Navigator. A Live Region Controller. And an Accessibility Lead that coordinates them. A hook fires on every prompt. If the task involves UI code, the team activates automatically. If it does not, Claude works normally. It enforces WCAG 2.1 Level AA compliance. It covers VoiceOver, NVDA, and JAWS compatibility. It catches framework-specific pitfalls like React conditional rendering breaking live regions and Tailwind color classes failing contrast. It is open source, MIT licensed, and installs in about thirty seconds. I built it because I need it. And I know I am not the only one. If you work with AI coding tools and care about accessibility, star the repo and share this with your team. The more people involved, the better it gets. GitHub: https://lnkd.in/geYhcZm3 Full writeup: https://lnkd.in/gZdQVxr5 #Accessibility #a11y #OpenSource #WCAG #ClaudeCode #AI #WebDevelopment #AssistiveTechnology #ScreenReader #DevTools #InclusiveDesign

🔍 My Process for Testing a Web Page for WCAG Conformance Ensuring web accessibility goes beyond automated testing—it’s about a detailed, methodical approach. Here’s how I test a webpage for WCAG conformance: 1️⃣ Start with the Basics - Double-check I’m testing the correct URL, component, and page state. - Open the page in my browser, set the screen width to 1280px, and open developer tools. (I live in developer tools!) 2️⃣ Inspect Elements - Work top-down, element by element, component by component. - Use developer tools to inspect elements and select shortcut “Expand recursively” to easily view the complete code structure. -Check each element’s HTML semantic structure, name, role, value, aria and functionality. ***Ask questions like: *What is this element? *What’s its role? *What is it's name and where is the name coming from? *Does it have supporting attributes for different states? *Does it pass color contrast requirements? *Is this an interactive element? 3️⃣ Interactivity and State Testing - For interactive elements, test with a mouse first, then the keyboard (Tab, Enter, Space) to ensure equitable functionality. - Ensure all interactive elements have a non-obscured color contrast conforming focus indicator. - Check hover, focus, active, pressed, selected, expanded, and collapsed states. - Ensure the element remains conformant, maintains color contrast, and performs its intended functionality in all states across all input devices. 4️⃣ Comprehensive Component Review Apply this process to all elements within a chosen component or page. Switch to Accessibility Tree View for new fresh perspective. 5️⃣ Screen Reader Testing Use NVDA to do a pass-through, ensuring I haven’t missed anything important. 6️⃣ Responsive Testing Test at 1280px for desktop, zoom to 200% for resizing, and zoom to 400% for reflow to check responsiveness and look for cutoff or missing meaningful content. 7️⃣ ARC Toolkit Analysis - Use ARC Toolkit to run tests with all topics selected. Manually review errors, alerts, and best practices by toggling disclosure panels. - Use highlight tools to quickly check: Page titles, iframes, lists, forms, tables, language attributes, buttons, links, tab order, tab index values, landmarks, and headings. - Leverage the text spacing tool at 1280px, 200%, and 400% to ensure compliance with resizing and reflow requirements. Accessibility isn’t just a checkbox—it’s a commitment to inclusivity and usability for all. This thorough (but not exhaustive) testing process ensures every page and component is tested against the WCAG success criteria. Now knowing how to fix the failures... DM me for help! What’s your favorite step or tool for accessibility testing? Let’s discuss in the comments! #AccessibilityTesting #WCAG #WebDevelopment #Accessibility #A11y

Monday Accessibility Tip for e-Learning and online course design. 💡 Make sure learners can move through content in a logical, consistent order using just the keyboard. This includes modules, lessons, videos, and quizzes. Why It Matters: Keyboard users, including those using screen readers, depend on a predictable flow of information. Disorganized tabbing or unexpected jumps can make learning frustrating or even impossible. What You Can Do: 🔍 Use proper heading levels (H1 for titles, H2 for section headers, etc.) Ensure the tab order follows the visual reading order. Test embedded tools for consistent keyboard navigation. Bonus: ⭐ Include learners with disabilities in your testing phase. Before launching a new course, invite a screen reader or keyboard-only user to test the experience. Their feedback can highlight real-world barriers you might have missed, and improve usability for everyone!