SharePoint Image Web Part Accessibility Guide for Authors (Alt Text, Links, Lightbox)

With SharePoint now making it possible to craft entire pages using AI, it’s more important than ever to review and enhance a page’s accessibility. If we rely solely on AI and accept the image web part’s default settings, we may end up with more content—but risk compromising the overall user experience, especially for users who require accessible features. In my last blog post, I focused heavily on the technical limitations of the image web part, but didn’t explore what these configurations actually mean for day-to-day use.

In this post, I’ll walk through the image web part’s functionality from top to bottom, highlighting where accessibility matters most.

Image links: alt text and accessible names

A link on an image can be useful in many scenarios, either linking to another resource on your intranet or to a larger version of the image.

If your image is intended to function as a link, be sure to define the link and provide alt text that clearly describes its destination. This enhances accessibility and should be your default practice. If the image is purely decorative or not interactive, it should not be turned into a link.

The screen reader announces the image as follows.

In the default configuration, SharePoint will only announce a button with text and will not indicate that the user is on an image with alt text and a caption. It will be announced as follows.

Why you can’t control the accessible name (aria-label) for image links

Historically, some implementations used the title attribute to provide extra link information. Modern accessibility practice discourages relying on it as the main way to describe link purpose.

The Web Content Accessibility Guidelines state that each link should have a clear purpose in context – SC 2.4.4.

Practically, it means:

• A visible link text
• Alternative text of an image used as a link
• Programmatic associations such as aria-label or aria-labelledby

For image links, this typically means the accessible name is (ideally) crafted from text content within the figure—such as a caption or nearby descriptive text—when those elements are correctly associated.

In SharePoint’s Image web part, this is exactly where the current implementation falls short: authors have very limited control over how that accessible name is constructed.

Opening links in a new tab: when it’s OK

There are clear guidelines for when to open a link in a new window. There are clear guidelines for when to open a link in a new window. The idea is simple: be consistent.

If the link remains in the same security context, it’s best practice to open it in the same window, rather than in a new window or tab. For example, if providing a larger version of content, do not use “open in new window.”

Users can always open a link in a new window by right-clicking and choosing “Open in new window,” or by pressing Ctrl+Click (Windows) or Command+Click (Mac). This shortcut opens the link in a new window or tab.

The Web Content Accessibility Guidelines offer documentation on this topic:

• G200 – open new windows/tabs only when necessary
• G201 – give advanced warning when opening a new window
• Link Targets and 3.2.5

Disable the lightbox (it breaks reading flow for screen readers)

Given how SharePoint implements the lightbox today, you should disable it for accessibility. In general, only use lightboxes if they’re implemented as proper dialogs with correct semantics, focus management, and clear labeling.

From a user-flow perspective, the current implementation is confusing. Instead of treating the image as content, SharePoint turns it into a button that opens a lightbox. For a screen reader user, this means suddenly encountering a button in the middle of the text, with little indication that it’s related to the image or that it will show a larger version.

Would a standalone button appear directly inside this blog post? Likely not. Yet, that is exactly how it is exposed to assistive technologies. A user navigating with a screen reader has no clear indication of what the button does, why it is there, or how it relates to the surrounding content, breaking the reading flow rather than supporting it.

As I mentioned earlier, sometimes a simple link is the better alternative.

Avoid text overlay on images (use captions instead)

In general, this feature could be used, but SharePoint adds additional information inside the image. That can cause further confusion.

When you have an image in Microsoft Word, you can add a caption to an image. Both elements, together in context, will build a figure. The figure caption can be placed below, above, to the right, or to the left of the image. In some cases, it makes sense to put the caption over the image.

SharePoint does not follow this well-established context and inserts an additional image within the figure, which causes strange announcements in the screen reader.

Especially with the lightbox enabled, the image won’t be announced, and all the different text labels within the figure will be combined into a single word salad.

The text overlay can also cause contrast issues, further degrading the user experience.

Sometimes the text overlay looks really good, but overall, it might hurt accessibility.

Alt text in the Image web part: what to write (and what SharePoint does with it)

The label Accessibility is a bit misplaced. As I showed earlier, all the settings manage accessibility and influence how well an image can or cannot be perceived by users with accessibility needs.

What is great about this section is that it links to really important guidance on crafting appropriate text alternatives (also known as alt text) for your users.

Checklist for using the Image web part accessibility

• Decide the image’s role first.
  Is it informative, functional, or decorative? Only turn it into a link if it actually does something useful.
• Make image links clear.
  If the image is a link, use alt text that describes the destination or action. Don’t rely on the title attribute, and be aware that you have limited control over the accessible link label in the Image web part.
• Avoid “Open in new window” for same-site content.
  For links in the same security context (e.g., larger versions of the same content), keep them in the same window. Users can always choose to open a new tab themselves.
• Disable the lightbox: In SharePoint’s current implementation, the lightbox turns images into confusing buttons for screen reader users. A simple link to a larger image or detail page is often better.
• Prefer captions over text over image.
  Use “Show image caption” instead of overlay text. Overlay text may look nice, but it can produce messy, hard-to-understand announcements in screen readers.
• Remember: every setting affects accessibility.
  Don’t treat the “Accessibility” section as optional. All Image web part options change how users with assistive tech experience your page.

Final thoughts

Accessibility in the Image web part isn’t just about checking a box. It’s about making sure everyone can really understand and interact with your content. SharePoint (and AI) can help, but they won’t always make the best choice for every image.

That’s why your role as a site author matters. Think about what each image is for, make sure links have a clear purpose, avoid opening new windows without warning, skip the lightbox, and use captions instead of placing text over images. With just a few thoughtful decisions, you can create pages that not only look good, but actually work for everyone.

It’s all too tempting to create a site that looks great but quietly hurts the user experience for everyone.