We often talk about accessibility as though it is something we need to add for a particular group of people.
I think we should look at it differently.
Accessibility is about removing unnecessary barriers so people can participate independently.
That distinction matters.
An estimated 1.3 billion people – around 1 in 6 globally – experience significant disability. Microsoft itself describes its accessibility commitment as designing products and services for everyone, including more than one billion people with disabilities.
But accessibility isn’t only about disability.
Accessible content is often:
- easier to understand
- easier to navigate
- clearer to read
- easier to search
- easier to consume in different ways
- more usable for everyone
That’s why I believe accessibility should be treated as a quality standard, not a specialist feature.
Accessibility isn’t about “making things available”
It’s about removing the barriers that get in the way.
Think about a document with:
- no headings
- tiny text
- poor colour contrast
- meaningless hyperlinks
- images with no descriptions
- complicated language
- tables being used purely for layout
- information communicated only through colour
Technically, the document exists.
But can everyone actually use it?
That’s the question we should be asking.
Accessibility is about giving people more than one way to access, understand and interact with information.
That might mean reading instead of listening.
Listening instead of reading.
Using a keyboard instead of a mouse.
Captions instead of audio.
A structured document instead of trying to interpret a visual layout.
Plain language instead of unnecessary complexity.
And importantly, these aren’t necessarily niche requirements.
We’ve all had moments when we’ve benefited from them.
Microsoft’s approach to accessibility
Microsoft’s accessibility thinking is built around some powerful principles.
Recognise exclusion
Start by identifying where a product, meeting or document creates a barrier to participation.
Don’t wait for someone to tell you they can’t use it.
Look for the barrier.
Learn from diversity
People work, communicate and consume information differently.
Understanding those differences – particularly through lived experience – helps us design better experiences.
Solve for one, extend to many
This is one of my favourite concepts.
A feature designed to solve a specific accessibility challenge can benefit a much wider audience.
Captions aren’t only for people who are deaf or hard of hearing.
They can help when you’re:
- in a noisy environment
- somewhere you can’t play audio
- working in another language
- struggling to hear a speaker
- trying to search through a meeting afterwards
The same principle applies across Microsoft 365.
Accessibility by default
Accessibility shouldn’t be something we remember at the end of a project.
It should be part of the workflow.
Microsoft’s own Microsoft 365 accessibility guidance recommends keeping accessibility capabilities available, increasing use of Accessibility Checker, making accessibility resources visible and keeping users on appropriate update channels so they benefit from newer accessibility features.
Think of accessibility as publishing quality
For me, this is the simplest way to explain it.
When you’re creating a document, presentation, email, meeting or SharePoint page, think:
Structure.
Describe.
Contrast.
Navigate.
Caption.
Simplify.
Check.
That’s accessibility.
And it’s also just good content design.
A practical accessibility checklist
Before you publish something, ask:
Structure
- Have I used built-in headings?
- Is the document logically structured?
- Is the reading order correct?
Language
- Is the language clear and concise?
- Have I removed unnecessary jargon?
- Could someone quickly understand the key message?
Visuals
- Does meaningful imagery have useful alt text?
- Is there sufficient colour contrast?
- Am I relying on colour alone to communicate meaning?
- Are fonts and sizes readable?
Links
Instead of:
Click here
Use:
Read the Microsoft accessibility guidance
The link should tell the user where it goes.
Tables
Use tables for data, not simply because they make a document layout easier.
Meetings and media
- Are audio/video recordings captioned?
- Can people access the important information without relying solely on audio?
- Are key decisions captured somewhere people can find them?
Documents
Avoid scanned-image-only PDFs where possible.
And use the Accessibility Checker before publishing.
Microsoft’s Accessibility Checker identifies potential accessibility issues and provides recommendations for addressing them. Microsoft also provides policy options to increase its use, including configuring it to run automatically in supported Office apps.
But there’s an important caveat:
The Accessibility Checker is a quality gate, not a replacement for human judgement or testing.
Do this. Avoid that.
Do
✅ Use headings and structure
✅ Describe meaningful images
✅ Use live captions in meetings
✅ Make links descriptive
✅ Use plain language
✅ Test with a keyboard and screen reader where possible
✅ Check your content before publishing
Avoid
❌ Relying on colour alone
❌ Using images of text unnecessarily
❌ Ignoring reading order
❌ Burying important decisions in chat
❌ Assuming everyone consumes information in the same way
❌ Treating Accessibility Checker warnings as noise
Accessibility needs adoption, not just awareness
Buying technology with accessibility features isn’t enough.
People need to know those features exist.
And they need to know when and how to use them.
I like a simple four-stage approach:
1. Awareness
Explain why accessibility matters.
Show people the built-in capabilities already available to them.
2. Enablement
Give people practical resources:
- templates
- checklists
- training
- short demonstrations
- quick-reference guides
3. Governance
Make accessibility part of your publishing standards.
Define what “good” looks like.
Use the available Microsoft 365 controls and policies where appropriate.
4. Community
Create feedback routes.
Encourage accessibility champions.
Share examples of good practice.
And, importantly, listen to people with lived experience.
The bigger picture
WCAG 2.2 provides a useful framework around four principles:
Perceivable.
Operable.
Understandable.
Robust.
These principles aren’t just technical terminology. They provide a useful way of asking whether people can actually access and use the information we’re providing.
And there’s an important point here.
Even conformance with WCAG doesn’t mean every possible user need has been solved. Accessibility is broader than checking boxes against a standard.
That’s why people have to remain at the centre of accessibility.
My challenge to Microsoft 365 administrators
Don’t ask:
“Does Microsoft 365 have accessibility features?”
We already know the answer is yes.
Ask:
“Are we actually making those features part of how our organisation works?”
Are your templates accessible?
Are your meetings accessible?
Are your documents structured?
Are people using captions?
Are your publishers checking their content?
Are your accessibility resources easy to find?
Are people comfortable telling you when something doesn’t work for them?
That’s where accessibility moves from technology capability to organisational culture.
Accessibility is not a feature
It is a way of designing better work.
It removes unnecessary barriers.
It gives people choices.
It improves the quality of our content.
And very often, the thing we build to help one person ends up helping many more.
Don’t ask: “Do we have accessibility features?”
Ask:
“Are we using them?”
Every person.
Every ability.
Every day.
Useful resources
Leave a Reply