Post by Larry Knight

The first step in building a WCAG AA-compliant SharePoint intranet? 👉 Accepting that you can’t. Don’t believe me? Run an axe.core scan on the out-of-the-box homepage (yes, the glossy Contoso demo). What you’ll see: instant red flags. Multiple fails. Even critical WCAG A issues. And here’s the kicker 👇 Some of the worst offenders are Microsoft’s own components — things you cannot rip out or override: ⚠️ Flexible sections ⚠️ Hero web part ⚠️ Content Highlight ⚠️ Events ⚠️ Collapsible sections ⚠️ Image backgrounds ⚠️ Editorial cards ⚠️ Document Library ⚠️ Viva Engage ⚠️ Org Chart ⚠️ Embed Every single one introduces barriers — missing aria labels, nested interactive controls, broken focus, low contrast, poor semantics. So! what does that mean for digital workplace teams? ❌ “Compliance by default”? Myth. ❌ “We’ll fix it in one audit”? Nope. ✅ Accessibility has to be designed in, tested often, and fought for. And here’s the truth nobody likes to admit: If you’re running SharePoint, you’ll never be 100% compliant. But success isn’t perfection. 💡 Success is knowing you did everything you could — testing, fixing, designing with inclusion in mind — even if the platform itself still comes up short. 👉 Over to you: what’s the nastiest accessibility blocker you’ve found in SharePoint? #Accessibility #DigitalWorkplace #SharePoint #Microsoft365 #Inclusion #AccessibleDesign #WCAG #A11y #InclusiveDesign #AccessibilityMatters