SharePoint Accessibility Audit Checklist for Modern Pages, Files, and Forms

Overview

Accessible SharePoint content helps people find, understand, navigate, and complete tasks regardless of how they use Microsoft 365. That may include keyboard navigation, screen readers, browser zoom, magnification, captions, voice input, high-contrast settings, or mobile devices. Accessibility is therefore a content, design, configuration, and governance responsibility—not a final technical check performed only after a page is complete.

Use this SharePoint accessibility checklist at three points: while content is being created, before a major page or document is published, and during a periodic compliance or content-quality review. Automated checks can highlight some issues, but they do not reliably confirm whether headings are meaningful, instructions are understandable, link labels make sense out of context, or a form can be completed efficiently with assistive technology. A short manual review remains essential.

Define the standard you are using before the audit begins. Many organizations use the Web Content Accessibility Guidelines (WCAG) as a reference and then map applicable criteria to their own legal, policy, or procurement requirements. Record the chosen version, conformance target, scope, and exceptions in the audit documentation. This keeps an accessibility review separate from assumptions about what SharePoint or another Microsoft 365 service automatically guarantees.

Accessibility should also be part of SharePoint governance. Link the audit to your page ownership model, document lifecycle, permissions review, and publishing workflow. For supporting governance practices, see the guidance on SharePoint site provisioning and ownership and Term Store governance.

What to track

Modern SharePoint pages

• Page title: Confirm that the title describes the page purpose and is distinct from nearby pages. Avoid vague titles such as “Information” or “Resources” when a more specific label is possible.
• Heading structure: Use headings to express the page outline. Check that sections appear in a logical order, that the page has a clear main topic, and that headings are not being used only to make text look larger. Do not skip structure merely because the visual design appears acceptable.
• Readable text: Review font size, line length, spacing, alignment, and the amount of text placed over images. Plain language, short paragraphs, descriptive subheadings, and lists improve usability for everyone.
• Color and contrast: Do not use color alone to communicate status, required fields, categories, or meaning. Check text, icons, buttons, links, focus indicators, and graphical information against the contrast target selected by your organization. Test text on backgrounds that change across screen sizes or themes.
• Links and buttons: Use descriptive labels such as “Download the travel policy” rather than “Click here.” Make the destination or action clear from the link text, and distinguish links from surrounding text without relying only on color. Avoid opening new windows or tabs unexpectedly.
• Images and icons: Add concise alternative text that conveys the purpose of an informative image. Mark purely decorative images as decorative where the authoring control supports that option. Do not repeat a caption or surrounding text unnecessarily. For diagrams, provide the important relationship or conclusion in nearby text rather than relying on a long, difficult alt-text paragraph.
• Tables: Use tables for data, not page layout. Provide a meaningful caption or introduction, identify header cells where the authoring control allows it, and avoid merged cells or complex nesting unless there is a strong reason and a tested alternative.
• Embedded content: Review maps, videos, dashboards, forms, and custom web parts independently. Check that the embedded item has a useful title, keyboard access, sufficient contrast, and an equivalent route to the information or task if the component cannot be used.
• Keyboard and focus: Move through the complete page with the keyboard. Confirm that focus is visible, follows a sensible order, does not become trapped, and reaches interactive controls. Test menus, accordions, carousels, filters, search controls, dialogs, and any custom SharePoint Framework component.
• Responsive behavior: Test browser zoom, a narrow window, and a mobile layout. Look for clipped text, horizontal scrolling, overlapping controls, hidden instructions, and interactive elements that become difficult to target.

Documents and downloadable files

A page can be accessible while the linked document is not. Include every high-use or high-risk file in the review, including Word documents, presentations, spreadsheets, PDFs, images, scanned records, and templates.

• Check document language, title, authoring structure, headings, lists, reading order, and table headers.
• Confirm that images have useful alt text and that decorative objects are identified appropriately.
• Check hyperlinks, bookmarks, document navigation, color contrast, and text that is embedded only in images.
• For PDFs, verify that the file is tagged where required, has a logical reading order, exposes text to assistive technology, and includes accessible tables and form fields where applicable. A visual scan alone is not sufficient.
• Test the published or downloaded version, not only the source file. Conversion to PDF or another format can change tags, reading order, links, and form behavior.
• Review whether the file is still needed, whether an HTML alternative would be clearer, and whether the document owner and review date are recorded.

Document accessibility belongs in document management and migration planning. Before moving content into a new library, identify inaccessible legacy files, assign owners, and decide whether each file should be remediated, replaced, archived, or removed. The SharePoint migration runbook provides a useful model for discovery, testing, and cutover controls.

Microsoft Forms and task workflows

For Microsoft Forms embedded in a page or linked from one, audit the entire task rather than the form in isolation. Check that the form has a descriptive title and introduction, each question has clear instructions, required questions are identified in more than one way, and error messages explain how to correct a response.

Use keyboard-only navigation to move through every question, option, date control, upload control, and submit action. Check that focus remains visible and that the completion status is understandable. Review branching logic, confirmation messages, time limits, file-upload requirements, and privacy notices. If the form cannot be completed by a portion of the intended audience, provide a documented alternative route and make it equally discoverable. Microsoft 365 interfaces and authoring controls can change, so verify the available options in the current tenant before publishing instructions.

Audio, video, and live content

Check captions for accuracy, synchronization, speaker changes, and important non-speech information. Provide a transcript when practical, especially for instructional, compliance, or frequently reused material. Describe meaningful visual information in the narration or an accompanying text alternative. For live events, record what accessibility support is available and review the resulting recording after publication.

Use an issue log

Track findings in a shared list or workbook rather than relying on email. At minimum, record:

• site, page, library, file, or form URL;
• issue description and the user impact;
• relevant WCAG criterion or internal requirement, if applicable;
• severity and remediation priority;
• owner, target date, status, and evidence of retesting;
• exception rationale and approval, if the issue will remain temporarily unresolved.

Use a practical priority model. Treat barriers that prevent access to a required task, affect a critical audience, or occur across many pages as urgent. Prioritize next issues that cause significant confusion or exclude a common workflow. Schedule cosmetic or low-impact improvements after functional barriers, but do not close a finding merely because it is difficult to fix.

Cadence and checkpoints

Accessibility reviews work best when they are tied to predictable publishing events. Apply the following checkpoints:

Use a risk-based sample for large intranets. Include the home page, global navigation, search and results pages, top task pages, employee forms, policy documents, templates, and representative content from each department. Expand the sample when a template, custom web part, migration, or platform update affects many assets.

Keep accessibility checks in the same release process as security, permissions, and content approval. When a site is provisioned, assign an accessibility owner and review date. When content is migrated, test both the source-to-target transformation and the post-cutover experience. For related storage and lifecycle controls, see SharePoint storage management.

How to interpret changes

A rising issue count does not always mean accessibility is getting worse. It may indicate better coverage, a larger sample, a new template, or a change in the audit standard. Record the scope and method for each review so results can be compared fairly.

Look for patterns rather than isolated totals:

• Repeated missing alt text: Improve author guidance, page templates, and publishing prompts instead of correcting the same image issue one page at a time.
• Many unclear links: Review navigation design, search result labels, and content-writing guidance. Link quality often reflects information architecture as well as author behavior.
• Keyboard failures in one component: Escalate to the web-part owner or development team and test every page using that component. A shared component can create a wide impact.
• PDF problems after conversion: Revisit the source template and publishing workflow. Repeated repair of finished PDFs may be less reliable than fixing the generation process.
• Issues concentrated in migrated content: Add accessibility to migration discovery, acceptance criteria, and post-cutover sampling. Do not assume that a successful file transfer is a successful accessibility transfer.
• Older pages with no owner or review date: Treat ownership as a governance gap. Assign an accountable owner, set a decision date, and archive or remediate content that no longer serves a purpose.

Separate defects from exceptions. An exception should state the affected content, reason, risk, temporary alternative, approver, and expiration or review date. “Not supported” is not enough on its own; verify whether a different authoring method, format, or equivalent experience can address the need.

Measure progress with useful operational signals: the percentage of sampled assets with owners, the number of critical tasks that pass keyboard testing, the age of open high-priority issues, the proportion of new content reviewed before publication, and the percentage of recurring defects fixed at their source. These measures are more actionable than a single overall score.

When to revisit

Revisit this checklist before every major SharePoint page release, new intranet section, form launch, document-library redesign, template change, custom web-part deployment, or migration cutover. Run a focused review when navigation, branding, permissions-dependent content, embedded media, or search experiences change.

At a minimum, schedule a monthly or quarterly review for critical pages and forms, depending on their change rate and risk. Refresh the checklist and its interface instructions at least twice a year, and sooner when Microsoft publishes new accessibility authoring controls, SharePoint Online updates affect the tested experience, browsers or assistive technologies change materially, or your organization updates its accessibility requirements.

To make the next review easy, finish each audit with three actions: assign owners to every open issue, record the exact URLs and test conditions, and place the next review date in the site or content governance register. Start the next audit with unresolved high-priority items, recently changed templates, and new content. This turns a one-time SharePoint accessibility audit into a repeatable control for accessible pages, files, and forms.