SharePoint provides accessible foundations, but it cannot make an inaccessible page, document or custom web part compliant by itself. Site owners still control headings, link text, images, colour choices and reading order. Developers still control keyboard behaviour and accessible names inside custom components.
Treat accessibility as an authoring and testing discipline, not a switch in the admin centre.
Decide what standard applies
Many organisations use the Web Content Accessibility Guidelines as their technical baseline. The applicable version, conformance level and legal duty depend on the organisation, jurisdiction and service.
Microsoft publishes WCAG information and conformance resources, but a Microsoft product statement is not a compliance certificate for your completed intranet. Your content, extensions, embedded services and operating process are part of the result.
If this is a regulated or public-facing service, involve your accessibility and legal specialists before declaring conformance.
1. Start with a clean page structure
Use modern SharePoint pages where possible. Give the page a specific title and use heading styles in a logical sequence. Do not imitate headings by making ordinary text large and bold.
Keep sections simple. Check that the reading order still makes sense when the page is zoomed or narrowed. Avoid using a table for layout.
2. Write links that make sense on their own
“Click here” tells a screen-reader user almost nothing when links are read as a list. Use text such as “Download the expenses policy” or “Open the service desk”.
Microsoft's guidance on adding accessible content and links recommends clear display text and checking the link preview.
3. Describe meaningful images
Add concise alternative text that communicates the image's purpose in context. Mark decorative images as decorative when the editor supports it. Do not repeat a caption word for word.
Charts need more than “bar chart”. Explain the conclusion in nearby text and provide the underlying data in an accessible format when readers need it.
4. Check colour and visual presentation
Use site themes rather than hand-picked colours where practical, but still test contrast. Never use colour as the only way to communicate status. Pair it with text, an icon with an accessible name, or both.
At high zoom, verify that content reflows without hiding controls or forcing unnecessary horizontal scrolling.
5. Fix the documents, not just the page
An accessible library page can still lead to an inaccessible PDF, Word document, spreadsheet or video.
Use the accessibility checker in the source Office application. Check document headings, table headers, reading order, alt text, meaningful file names and link text. Videos need captions, and audio-only content needs an equivalent transcript where required.
Do not convert a badly structured document to PDF and assume the conversion repairs it.
6. Hold custom SPFx web parts to a higher bar
SharePoint Framework provides an accessible container, but Microsoft states that developers must implement the remaining keyboard and screen-reader behaviour inside the web part and its property pane.
For every interactive control:
- use the native HTML element where possible
- provide a programmatic name
- keep a visible focus indicator
- support keyboard operation
- move focus deliberately after dialogs or dynamic updates
- announce important status changes without stealing focus
- avoid positive
tabindexvalues and keyboard traps
Test custom components before deployment and again after framework or browser changes.
7. Test the complete journey
Automated checkers catch some problems, not all of them. Combine:
- keyboard-only navigation
- browser zoom and narrow viewport testing
- automated scans
- at least one screen reader and supported browser combination
- testing by people with disabilities for important journeys
Microsoft recommends testing SPFx experiences with Narrator and Edge, then checking other combinations relevant to your audience. Record the browser, assistive technology, page, date and result so a later retest means something.
A useful publishing gate
Before publishing, confirm:
- the page has one clear title and logical headings
- every link has useful text
- meaningful images have suitable alt text
- colour is not the only signal
- documents and videos have been checked
- keyboard focus reaches every action in a sensible order
- errors are described in text and linked to the affected field
- the page works at the zoom and viewport sizes required by your standard
Passing this checklist is evidence of a structured review. It is not, on its own, proof of WCAG conformance or legal compliance.
Sources
- Accessibility in SharePoint web part design
- Accessibility in SharePoint
- Add accessible content and links to a SharePoint site
- Build accessible SharePoint sites
- Microsoft WCAG offering information
For more practical page, governance and admin checks, join the SharePoint & Teams Admins Space.