Semantic HTML for Accessibility

Your design might look clear and organized, but if that structure isn't in the code, assistive tech users miss out. Headings, lists, form groups, required fields, tables - they all need proper HTML to be meaningful. This carousel breaks down how to meet 1.3.1 and why it's important. Check it out 👉 #Accessibility #A11y #InclusiveDesign #WebDev #WCAG #SemanticHTML #DesignWithIntention If you prefer your content as text, read on: When design isn’t enough. Understanding WCAG 1.3.1. What is WCAG 1.3.1? Your design communicates meaning and relationships. But if it’s not in the code, assistive technology users can’t access that information. Why it matters. If you rely only on how things look, you leave out people who use screen readers, rely on braille displays, or can’t see layout or hear audio cues Common mistakes. These may look fine, but aren’t coded accessibly: Bold text as a heading Asterisks or red text for required fields Dashes for lists Tables made with spaces or tabs instead of HTML Do it right with semantic HTML. Use the correct HTML tags and attributes to convey meaning to assistive technologies. Reinforce style with structure. If color, sound, or placement communicates something, back it up with code. Code grouped form fields. Wrap form fields that go together in a fieldset and use a legend to describe the purpose of the set of fields. Code headings correctly. Use semantic heading tags in a logical order. Use h1 for the page title, h2 for section headings, h3 for subsection headings, and so on. Mark up lists correctly. Use ul or ol elements to code lists. Don't fake it with dashes or emojis. Mark up (and use) tables correctly. Use tables for tabular data, not for layout. Use a caption to describe what the table is about. Use th elements for table headers and define their scope. Use td elements for table cells. Label it or lose the meaning. Programmatically associate labels with form fields by using a for attribute on the label that refers to the ID of the input. Required field? Code it that way. Use the aria-required="true" attribute to mark required fields. No landmarks? No map. Provide page landmarks such as header, main, footer, aside, and nav to help users find their way. The big picture. WCAG 1.3.1 is one of the most common success criteria to have failures...and many of those are some of the easiest to fix! Learn more. Want more clear and actionable WCAG breakdowns? WCAG in Plain English is available now!

🧑🦯 Accessibility in React: What I Used to Miss (and What I Do Differently Now) ✨See, I’ll be honest. For the longest time, I thought accessibility (a11y) meant: 🔸Adding alt text to images 🔸Maybe using aria-label here and there 🔸And then… shipping the feature 🚀 But that’s just the surface. One day, I watched 🧐 a visually impaired user navigate a web app using only a keyboard + screen reader. And… my app failed 🥺 🔸Buttons weren’t reachable. 🔸Modals weren’t announced. 🔸Focus was lost between screens. 🔸The entire experience was broken. 🔥 That’s when I decided to get serious about accessibility in React. 🚫 Common Things I Was Missing: 🔸Keyboard navigation — Elements weren't focusable in the right order 🔸Incorrect semantics — Using <div>s instead of <button> or <nav> 🔸Modals without focus traps — Users couldn’t exit easily 🔸No skip links — Forced to tab through headers every time 🔸Custom components breaking native behaviors — Especially dropdowns and tooltips 🛠️ What I Do Now (and You Can Too): ✅ Use semantic HTML first ❌Don’t overuse <div> and <span>. Use: 🔸<button> instead of clickable divs 🔸<section>, <nav>, <article> for structure 🔸<label> and <fieldset> for forms 🔸It’s built-in accessibility — use it! 🧠 Manage focus like a pro ✨When opening modals or navigating pages: 🔸Set focus to the first interactive element 🔸Trap focus inside modals 🔸Return focus to the last element when modal closes 🔸Use hooks like useFocusTrap() or libraries like [focus-trap-react]. 🎙️ Make screen readers your friend ✨Use ARIA only when needed: 🔸aria-live for announcements 🔸aria-hidden to hide irrelevant elements 🔸aria-label to clarify non-text content 🔸Test with VoiceOver (Mac), NVDA (Windows), or browser dev tools. 🧪 Test for accessibility ✨Don’t leave it to chance. Use: 🔸axe DevTools 🔸Lighthouse audits 🔸jest-axe for automated tests 🔸Manual keyboard-only testing ✨ Bonus: Component Libraries with A11y Built In 🔸Radix UI 🔸Reach UI 🔸Headless UI 🔸MUI / Chakra (with caveats — test them!) 🚀 The Result? 🔸Better UX for everyone (not just screen reader users) 🔸Fewer bugs from keyboard edge cases 🔸Compliance with WCAG & legal standards 🔸More inclusive products 💬 Let’s Talk What’s one accessibility mistake you’ve seen (or made)? How are you testing for a11y in your React projects? If you’re building for the web, you’re building for everyone. #LinkedIn #ReactJS #Accessibility #a11y #WebDev #Frontend #FrontendDevelopment #FullstackDevelopment #InclusiveDesign #ReactTips #UX #DigitalInclusion #KeyboardNavigation #WebAccessibility

Webflow Accessibility Tip #1: Use Proper Paragraph Tags! When building accessible websites, do not leave text floating inside <div> or <span> elements. Instead, use the <p> (paragraph) element to mark up blocks of text! This ensures consistent styling and gives users more control when customizing their view. How to improve accessibility with the <p> tag: Improved Readability and Assistive Tech Compatibility: Using paragraph tags (<p>) ensures text is semantically correct, making it easier for screen readers and other assistive technologies to interpret and navigate. This improves readability for users who rely on these tools, as opposed to leaving text in <div> or <span> elements, which lack inherent semantic meaning. Better Text Spacing Support: Paragraph tags naturally support increased text size and custom spacing settings (required by WCAG 1.4.12), ensuring that when users apply adjustments for readability, like increased line-height or word spacing, the layout remains intact. Text inside non-semantic elements like <div> or <span> may not handle these changes as smoothly. Enhanced Compatibility with High Contrast Mode: Paragraphs integrate better with high-contrast modes, which rely on semantic HTML to properly adjust visual styling for users with low vision. Using <p> ensures that text remains readable and contrast settings apply correctly, unlike text inside generic elements, which may not receive these adjustments effectively.

Accessibility Tip of the Day 290: Accessible collapsible sections and accordions: Collapsible sections are another great way to limit the amount of information shown on the screen. Users can easily scan the content by looking at the section headings, and they can choose to expand the sections that they want to read. This has the benefit of not just faster reading time but also faster screen reader navigation and keyboard navigation time. The interactive clickable section header is the part that's easiest to get wrong. You need to combine both the functionality of a header and a button. We should not just add a click handler to the header like what you see below, because that doesn't work for keyboard and screen reader users: <h2 onClick={toggleSection}>Section heading here</h2> To compensate for that, you might see someone add a tabIndex={0} and a role="button" to the heading like what you see next, but that's also incorrect because now we lose the semantic meaning of the heading since we've overridden it to be a button: <h2 onClick={toggleSection} tabIndex={0} role="button">Section heading here</h2> Instead, we need to use both a heading element and a <button> element. Here's the correct way to do this (note that we've also added the aria-expanded attribute to indicate to screen readers if the section is expanded or collapsed): <h2> <button type="button" onClick={toggleSection} aria-expanded="false">Section heading here</button> </h2> Much better! If you'd like to learn more about creating accessible collapsible sections, Heydon Pickering wrote an awesome post on this in his Inclusive Components blog: https://lnkd.in/gUUBsD3T #accessibility #a11y #accessibilityTipOfTheDay

Had a request to dive further into Semantic HTML in my last post...so here we go 👇 With Semantic HTML we're focused on using HTML tags that add meaning to our web content. For example, instead of making a sidebar with a <div> tag, using <aside> would be semantic. HTML has purpose-specific tags we can use based on the type of content we want to display. <main>, <article>, <nav>, <section>, <header>, <footer>, and <aside> are all used for structuring documents. Then we have <h1> to <h6> for headings, <p> for paragraphs, <ul>, <ol>, and <li> for lists, and so forth. Additionally, there are: <mark> (important text), <-- I once (ostensibly) got a featured snippet with this <time> (standardizing dates and times in a machine-readable format) <address> (physical addresses, phone numbers, and email addresses) <details> and <summary> (combined for open/close show/hide functionality) <cite> (referencing the title of a creative work) <blockquote> (for quotes, typically browsers automatically indent this) For search engines, while it's certainly not a "rankings factor", semantic HTML can help with crawling/indexing and better understanding your content. --> If your existing HTML is poorly formed and you notice crawling/indexing issues, you might see an increase in visibility as a result of doing this. *Arguably the most important reason to use semantic HTML is for accessibility* --> Screen readers (and other assistive technologies) often rely on semantic elements to convey information about the structure and navigation of the page. Some other reasons we'd want to leverage Semantic HTML: - Simplified CSS targeting - Cross-device and browser compatibility #SEO #TechnicalSEO #HTML #Accessibility

Google just launched GenTabs. Turning your browser into custom web apps. But it exposes a technical truth most brands don't understand. Powered by Gemini 3, GenTabs creates applications on the fly: reading and synthesizing content from multiple sites simultaneously. Trip planners. Meal prep tools. Research dashboards. All generated instantly from the sites you're browsing. But to do this, GenTabs doesn't just "read" your website like a human. It parses your DOM (Document Object Model) and extracts meaning from your site's structure. That's the exact same process browsers use to build the "accessibility tree" for screen readers. Research backs this up: Google found LLMs are 12% more accurate at understanding web content when pages use proper semantic HTML (Gur et al., 2023) A study on AI web agents concluded: "DOM-based agents, much like screen reader users, rely heavily on the semantic structure of web content to perceive and act" (Nitu, Mühle, and Stöckl, 2025) Our own TestParty research shows, if a screen reader can't parse it, neither can GenTabs. The technical overlaps run deep: → READING ORDER: AI reads your DOM in code order, not visual order. CSS Grid reordering breaks AI parsing the same way it breaks screen readers. → LINK TEXT: "Click here" is meaningless to both AI and assistive tech. GenTabs needs descriptive links to understand what to cite. → TABLE STRUCTURE: Without proper <th> tags, AI sees a flat stream of text, not structured data. → HEADING HIERARCHY: H1-H6 create the content outline AI uses to chunk and synthesize information. Semrush studied 10,000 sites: accessible ones get 23% MORE SEO traffic, 27% MORE SEO keywords. Yet 94.8% of websites fail basic accessibility (WebAIM 2025). Here's the core insight: The accessibility tree IS the AI interface. Same semantic structure. Same descriptive text. Same logical reading order. Accessibility and AI readability aren't parallel tracks. They're the same track. So, what's your site's accessibility (and AI) score?