Mythbusting: Image Accessibility in SharePoint
It’s time to take a closer look at how modern SharePoint really handles image accessibility. In this post, I’ll focus on what matters for both site authors and developers: alt text and how decorative pictures behave.
We’ll look at where SharePoint helps you, where it gets in the way, and bust a few common myths along the journey. From design quirks to DOM oddities, I’ll show concrete examples of what works well, what doesn’t, and what you can do about it. In this article I cover most of the technical aspects, but I also created accessiblity guide for site authors guide for that.
Myth 1: SharePoint provides great accessibility out of the box
This statement is partially true. SharePoint covers many requirements at the platform level.
The content level, especially how authors handle images, alt text, and layout, is something Microsoft cannot control.
The application cannot control the content; it can only help. And images are one of the clearest examples of this.
Reality
Microsoft targets both the Web Content Accessibility Guidelines (WCAG 2.1 AA) and the relevant requirements of the European EN 301 549 accessibility standard, which the EU Web Accessibility Directive and the European Accessibility Act reference.
Not all WCAG AA or EN 301 549 criteria are fully met in SharePoint’s modern experience. Microsoft documents the known gaps and partial failures in their official Accessibility Conformance Reports (ACRs):
https://www.microsoft.com/en-us/accessibility/conformance-reports
In practice, this means that SharePoint provides a strong starting point, but compliance depends heavily on how sites are designed and how content is authored.
Myth 2: SharePoint generates alt text out of the box
Reality
The image feature in the latest SharePoint version has degraded, and usability has deteriorated. Older versions of SharePoint used to notify the user about the image description and even suggested an alt text. The results were fairly accurate and described what was visible in the image. The new Image Web Part no longer provides this experience.
I tested this behaviour across two different tenants, one with Microsoft Copilot enabled and one without. Without Copilot and using stock images, you only get automatically generated alt text, and even that is fairly inaccurate. Without Copilot and using a custom uploaded image, you don’t get any alternative text at all. The site author needs to take care of it.
With Copilot enabled, the descriptive alt text reappeared and was fairly accurate. Based on these observations, automatic alt text generation no longer functions consistently without a Copilot license. I was not able to fully verify this behaviour, but the pattern is very clear.
According to the Image Web Part documentation, this functionality should still work, but it differed from what I observed across multiple tenants.
Do this instead
Don’t rely on Microsoft’s SharePoint Alternative text system and check the images yourself.
This example shows “Person alone in office”. If you look closely at the image, there are actually two people in the frame. One in the background, small but still there, and one in the front.
A more descriptive alternative text would be preferable. Something like “Person working on a laptop in an open-plan office.”
Myth 3: Every image needs to have an alt text
The myth that every image must have alt text is common. The origin is hard to identify. Many tools report that the missing alt text, and so does SharePoint.
Reality
With the introduction of the HTML W3C specification, the ‘alt’ or alternative text attribute became mandatory. It just states that every image must have this attribute, not whether it has meaningful content or is just empty.
In case of accessibility standards, the WCAG 2.1 Success Criterion 1.1.1 says non-text content must have a text alternative, but the techniques show two patterns:
- meaningful images – must have a descriptive text on the alt attribute
- purely decorative image – empty alt
Screen Reader will skip all images with an empty alt attribute, which makes them decorative. While some developers set ‘aria-hidden’ to true for decorative images, this violates the first rule of WAI-ARIA (Accessible Rich Internet Applications).
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so. W3C – using ARIA
The empty alt attribute is the right choice over ‘aria-hidden’.
In SharePoint
When you upload an image and don’t provide alternative text, the alt attribute is set on the image. This was not the case in the past. According to how HTML works, the image will become instantly decorative and hidden from screen readers.
If it is just decorative, you don’t need to do anything.
The decorative toggle is purely decorative and won’t affect accessibility. No benefit, no downside.
If you define an alternative text, the image instantly becomes included and not hidden from screen readers. This works exactly as the accessibility guidelines defined it.
For developers
In the case of images, there is another caveat, which is more developer-focused.
<img src="https://mysharepoint/image.jpeg" alt >
The code above is what SharePoint renders. This works for accessibility checkers, but does not guarantee that the screen reader sees the image as decoreactive.
<img src="https://mysharepoint/image.jpeg" alt="">
The correct pattern is to have the alt attribute and an empty string.
Myth 4: SharePoint handles the alt text properly
You found an image, defined an alternative text for it, and SharePoint renders everything perfectly.
Reality
SharePoint uses the alt text not only on the image, where it belongs. The alternative text is also applied to the surrounding button container.
I have two identical images on a SharePoint page, and both images have alternative text. A look at the accessibility reveals the issue.
We see two buttons labeled with the alternative text. We will also see the button’s alternative text.
The button is focusable; the image is not. The button’s context also does not reveal its purpose. Something like, click to show a larger version of this picture, or something similar.
It gets worse. After adding a caption, SharePoint concatenates the alt text and the caption into a single long label on the button. The image itself is no longer directly accessible, and neither is the alt text in its intended place. A screen reader only announces the combined button label, which does not reflect the image, the caption, or the action. This leads to a confusing and ultimately poor user experience.
Person alone in the office Coworker tries the new Copilot for the first time.
No separator, no nothing. Neither alt text nor caption will be handled properly.
This behaviour exists only because SharePoint always enables a lightbox, which is incorrectly implemented as a button’s role.
It breaks the first rule of ARIA again, which states:
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
The static behavior is a figure, not a button.
Myth 5: Lightbox is great for accessibility
Adding an image to SharePoint immediately enables a lightbox for the pictures. People can then see a larger version of the image.
Reality
Research from the accessibility community consistently shows that lightboxes are one of the most problematic UI patterns. Studies from the W3C and WebAIM issue with keyboard navigation, focus management, and semantic structure.
The lightbox on images is always enabled on any image you add to your SharePoint page. As shown in the previous myth, SharePoint does not handle the lightbox well. My recommendation is that they be disabled by default.
Lightboxes became popular around 2005–2007, when JavaScript image overlays were considered cutting-edge design. They stuck around in frameworks like SharePoint, even though modern accessibility research shows they’re one of the least accessible UI patterns.
- Nielsen Norma Group – Tooltips, Dialogs, Instructional Overlay
- WCAG 2.1 Techniques – W3C – Creating modal dialogs with the HTML dialog element
- HTML Dialog: getting accessibility and UX right
Myth 6: The accessibility checker in SharePoint is a blessing
Accessibility check shows me exactly where I have forgotten to add alt text.
Reality
The accessibility check shows you some issues, maybe, and some not.
I accidentally used a theme with red as the primary color, and this is how the accessibility check appeared to me. The label stated “Missing alt text” and a red check mark. Does this mean there is something wrong, or everything is correct?
Red is the most common color in branding and among companies that may run on Microsoft 365. They will see a red checkmark, indicating an error. The checkmarks should not follow the branding; instead, they should have a clear message.
Use might have added an image as decorative, sure, accidentally, those are not accessibility issues. They should be listed there in case there was a mistake. They don’t show up, leaving an image on the screen without an alt text.
The whole design is also not really explicit about what it actually means. I have “Image web part (1 of 6)” below “Missing alt text,” with the number 1 appended.
I don’t know what it means. One image is missing alt text, which is incorrect, since I know there are two images with missing alt text. Can I have more than one alt text field?
Why does it even show? No issues.
Confusing, at least for me, a designer too.
This violates Microsoft’s own Fluent Design principles, which require consistent color semantics and prohibit using brand colors to represent system states.
More information can be found at Microsoft:
Verdict
Modern SharePoint gives you a solid foundation, but it does not handle image accessibility for you. Alt text generation is inconsistent, the lightbox is poorly implemented, semantics are misused, and the accessibility checker misses entire categories of issues. What looks good on the screen often falls apart in the accessibility tree.
SharePoint’s platform-level accessibility is strong, but content-level accessibility is entirely in the hands of the author, and SharePoint’s tooling doesn’t always guide you in the right direction. If you rely on defaults, AI, or the built-in checker, you will create pages that fail WCAG, confuse screen reader users, or behave unpredictably.
The truth is simple:
SharePoint can be accessible, but not automatically. It takes knowledge, intention, and careful authoring.
Especially with AI-generated content in SharePoint, it will become increasingly crucial that the underlying technology has a solid, accessible implementation of all core components.
I hope that, when SharePoint turns 25 next year, some of the long-standing accessibility issues will finally be resolved. We need a platform we can trust, especially when our users rely on assistive technologies.
And there’s good news: while this post uncovered the problems, the next one will focus on the solutions. I’m preparing a dedicated guide on how to work with the Image Web Part properly, how to choose the right alt text, when to use empty alt, how to avoid the lightbox pitfalls, what authors should do, and what developers must watch for.
If you want to make SharePoint truly accessible in your organization, this practical guide will help you get there.
Accessibility is not a feature SharePoint switches on.
It’s a practice you bring to the platform. In the next article, I’ll show you exactly how.