SharePoint Accessibility Checklist 2026 | WCAG 2.1 AA, 508 & Title II
Last updated: 2026-07-27
SharePoint Online is where an enormous amount of organizational content lives: intranets, department hubs, policy libraries, onboarding sites, project workspaces, and increasingly public-facing communication sites for public sector bodies. Microsoft invests seriously in the platform's own accessibility, publishes conformance reports for it, and builds an accessibility checker into both the modern page editor and the Office applications people author content in. Despite that, SharePoint sites are among the most consistently inaccessible properties inside most organizations, and the reason is structural rather than technical. SharePoint is authored by everyone. Every team owns a site, every manager posts a page, and every department dumps documents into a library, with no editorial review layer and rarely any training. What accumulates is a decade of untagged PDFs, scanned policy documents, spreadsheets used as forms, images of org charts with no text alternative, and pages where the author made section titles by bolding text because that is what the toolbar made easy. Modern pages built from web parts are considerably better than the old classic pages with their nested layout tables, but plenty of classic content survives in long-lived tenants, and custom SharePoint Framework web parts and third-party embeds reintroduce keyboard and labeling failures that the platform itself avoided. The legal picture depends on who you are. Federal agencies and their contractors face Section 508, which references WCAG 2.0 Level AA; state and local government bodies, including public universities and school districts, fall under the Department of Justice Title II web rule requiring WCAG 2.1 Level AA; and organizations serving EU consumers face the European Accessibility Act. Employment settings add another dimension, because an intranet a disabled employee cannot use is a workplace barrier, not just a compliance line item. This checklist targets the content and configuration layer where nearly all SharePoint failures originate.
Common Accessibility Issues
The real content of most SharePoint sites is the documents, and libraries accumulate years of PDFs exported by print-to-PDF, scanned signed policies that are images of text, spreadsheets used as forms, and slide decks with no reading order. None of these carry heading structure, table headers, alt text, or a defined reading order, so a screen reader user opening the HR policy or the benefits form gets nothing usable. Because these files are often the authoritative version of a policy or a required form, the failure blocks a task rather than degrading an experience.
Fix documents at the source rather than remediating PDFs after the fact: author in Word with real heading styles, alt text on images, marked table header rows, and a set document language, run the built-in Accessibility Checker, and export with the accessibility-preserving option instead of print-to-PDF. Replace scanned image-only documents with digital originals or run optical character recognition and verify the result. For high-traffic items such as forms, policies, and onboarding material, publish the content as a SharePoint page rather than an attachment, since HTML reflows and reads reliably. Prioritize by download counts instead of trying to remediate an entire library at once.
The hero web part is the visual anchor of most modern SharePoint pages, and its tiles are frequently published with no alternative text, or with images that contain the tile's actual text baked into the graphic. Image web parts holding org charts, process diagrams, and infographics are similarly published with the information available only visually. A screen reader user gets an unlabeled link where a sighted user gets a headline, or silence where a diagram explains a process.
Set alternative text on every informative image and hero tile, describing the information the image conveys in context, and mark purely decorative images as decorative so they are skipped. Avoid images of text entirely: put the headline in the tile's text field rather than baking it into the graphic, which also keeps it readable when a user zooms or uses a high-contrast mode. For complex images such as org charts and process diagrams, provide the same information in text on the page or in a linked accessible document, because a single alt attribute cannot carry a diagram's full content.
Page authors using the text web part commonly build structure visually, selecting text and applying bold with a larger font size instead of using the heading styles in the formatting toolbar. The page looks organized and has no programmatic structure at all, so screen reader users cannot navigate by heading and have to read a long intranet page linearly. The same pattern shows up in pasted content from Word and Outlook, which brings inline styling rather than semantics.
Use the heading styles in the text web part's formatting menu for every section title and control the appearance through the site theme rather than by hand-setting font sizes. Keep levels in order without skipping, and remember the page title already occupies the top of the outline, so headings within the content sit below it. Paste as plain text and re-apply styles when bringing content in from Word or email, and run the accessibility checker in the page editor before publishing, which surfaces heading and alt text problems while the author is still on the page.
SharePoint Framework web parts built in-house or bought from a vendor, along with embedded dashboards, forms, and third-party widgets, routinely reintroduce the failures Microsoft's own web parts avoid: clickable divs that cannot be focused, custom dropdowns and carousels with no keyboard behavior, modals that do not trap or return focus, icon-only buttons with no accessible name, and dynamic content that updates with no announcement. Because these often carry the most important functionality on the page, such as a request form or a directory search, they fail the primary task.
Require an accessibility review before any custom or third-party web part is deployed to the tenant, and make keyboard operability the first gate: every control reachable by Tab, operable by Enter or Space, with a visible focus indicator and a meaningful accessible name. Ask vendors for an accessibility conformance report and test the actual component rather than trusting the document. For embeds you do not control, provide an accessible alternative path to the same function, such as a plain form or a direct contact route, and make that alternative discoverable rather than buried.
Organizations apply brand palettes to SharePoint site themes, and those palettes are chosen by brand teams rather than checked against contrast requirements. The typical result is low-contrast secondary and metadata text, brand-colored links and button labels that fall below the threshold against the page background, hero overlay text sitting on a photograph with no scrim, and status indicators in lists conveyed only by color. Employees with low vision or color vision deficiency then struggle with everyday navigation, which in an intranet means struggling with their job.
Validate every text and background pair in the custom theme against 4.5 to 1 for normal text and 3 to 1 for large text, and check interactive component boundaries and focus indicators against 3 to 1. Darken brand variants used for text and controls rather than dropping the brand. Add a solid or gradient overlay behind any text placed over a photographic hero image so contrast holds regardless of the picture. Ensure list and library status columns carry text or an icon in addition to color, and confirm the focus outline survived the theming pass, since custom themes frequently weaken it.
Intranet pages embed training videos, all-hands recordings, and recorded meetings, and these are frequently published with no captions, with unreviewed automatic captions, or with no transcript. Deaf and hard of hearing employees cannot access company announcements, mandatory training, or policy briefings that colleagues receive as a matter of course. Automatic captions that mishandle product names, acronyms, and staff names are especially problematic in an internal context, where that vocabulary is most of the content.
Require captions on every video published to an internal or public site, and treat automatic captions as a draft that must be reviewed and corrected for names, acronyms, and technical terms before the page is published. Post a transcript alongside longer recordings so people can search and skim rather than scrub through video, and describe essential on-screen visual information that is never spoken aloud. Where a recording is mandatory training, treat missing captions as a blocker rather than a follow-up item, since an employee cannot be required to complete training they cannot perceive.
SharePoint Online-Specific Tips
- Run the accessibility checker built into the modern page editor before publishing, and the Office Accessibility Checker before uploading any document.
- Prioritize document remediation by download count instead of trying to fix an entire library, because a small number of files carry most of the traffic.
- Publish forms, policies, and onboarding material as SharePoint pages rather than PDF attachments whenever the content is mostly text.
- Gate every custom SPFx web part and third-party embed on a keyboard test before it is deployed tenant-wide, since one bad web part affects every site that uses it.
- Retire remaining classic pages with nested layout tables rather than trying to remediate them, as modern pages start from far better markup.
Recommended Tools
Microsoft Accessibility
Microsoft's accessibility hub, where conformance documentation for Microsoft 365 and SharePoint is published along with guidance on the Accessibility Checker built into the page editor and the Office applications used to author library documents.
axe DevTools
A browser extension that audits a rendered SharePoint page for contrast failures, missing accessible names, heading structure problems, and non-semantic interactive elements introduced by custom web parts and embeds.
NVDA
A free Windows screen reader for verifying that hero tiles and images are described, that custom web parts expose their role and state, and that library and list content is announced in a usable order.
Frequently Asked Questions
Microsoft says SharePoint is accessible. Why does our intranet still fail an audit?
Because an audit measures the pages and files your organization published, not the platform's own code. SharePoint Online gives you accessible building blocks, ships an accessibility checker in the page editor, and Microsoft publishes conformance documentation for the product. What it cannot do is stop a department from uploading a scanned policy PDF, an author from bolding text instead of using heading styles, a brand team from applying a palette that fails contrast, or a vendor web part from shipping clickable divs. SharePoint is authored by everyone in the organization with essentially no editorial layer, so the accessibility of a tenant reflects the habits of hundreds of people rather than the quality of the platform. That is also why training and a lightweight review gate produce more improvement here than any technical change.
Do we have to remediate every document in every library?
No, and attempting it is usually why remediation programs stall. Sort by download or view count and start there, because access is heavily concentrated: a small set of policies, forms, handbooks, and onboarding documents accounts for most of what anyone actually opens. For those, the durable fix is often to stop distributing them as attachments and publish the content as a SharePoint page instead, which reflows, scales, and reads reliably in ways a PDF frequently does not. For documents that must remain files, fix them at the source in Word with real heading styles, alt text, marked table headers, and a set language, then export with the accessibility-preserving option. Archived material nobody opens can be handled on request, provided the request path is genuinely responsive rather than theoretical.
Further Reading
Other CMS Checklists
- Adobe-experience-manager Accessibility Checklist
- Sitecore Accessibility Checklist
- Kentico Accessibility Checklist
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.