Making social media embeds on your website more accessible

Why embeds deserve extra attention

Most accessibility work on a website happens in content you control: headings you write, images you upload, forms you build. Embeds are different. A feed, a video player or a post widget is generated by a third party’s script, so you can’t edit its markup directly. If the embed lacks a text alternative or can’t be used with a keyboard, the gap is on your page, even though you didn’t write the code.

That doesn’t mean you should avoid embeds. It means you should know what an embed does and doesn’t do, check it, and arrange your page so nobody depends on the embed for anything important. The checklist below is built around that idea.

The reference throughout is the Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C’s Web Accessibility Initiative (WAI). WCAG is organized into success criteria at three levels: A (the minimum), AA (the level most organizations and many laws aim for) and AAA (the highest). We quote the criteria numbers so you can look each one up in the W3C’s quick reference.

The short checklist

The sections below explain each area in plain terms, with the questions to ask of any embed: Instagram, YouTube, a review widget or a booking button.

Images and text alternatives

Success criterion 1.1.1 asks that non-text content has a text alternative that serves the same purpose, with exceptions such as pure decoration. For an image, that usually means an alt attribute. The W3C’s images tutorial draws a clear line between two kinds of images:

1. Informative images convey something: a product, a dish, a before-and-after result, an event poster with a date on it. These need alt text that describes what matters.
2. Decorative images only improve the look of a page. The tutorial says these should have an empty alt attribute (alt="") so assistive technologies can ignore them, and warns that leaving alt out entirely can make some screen readers read the file name aloud.

The W3C notes that deciding which kind an image is “is a judgment that only the author can make”. That is the hard part with embeds: the script has to decide for you, and it usually can’t know whether your photo of a dessert is the point of the page or just a pleasant background.

Questions to ask of an embed:

1. Does every image have an alt attribute, even an empty one? A missing attribute is worse than an empty one.
2. If alt text is filled in, is it meaningful, or just a file name, a number or the word “image”?
3. Does any image contain text, such as a price, a date or an offer? If so, that information needs to be available as text somewhere.

Keyboard access

Criterion 2.1.1 asks that all functionality be operable through a keyboard. Many people navigate without a mouse: people with motor disabilities, screen reader users, and power users who simply prefer the keyboard. They move through a page with Tab and Shift+Tab, and activate links and buttons with Enter or Space.

Embeds often fail here because clickable things are built from generic elements like div with a click handler attached, rather than real links (a) and buttons (button). Generic elements look and work fine with a mouse, but they are skipped by the Tab key and announced as nothing in particular by screen readers.

Criterion 2.1.2 covers the opposite problem: a keyboard trap, where focus goes into an embed and can’t get back out. A quick Tab through the page catches both problems.

Focus: where it goes and whether you can see it

Focus is the “you are here” marker for keyboard users. Two criteria matter most for embeds:

1. 2.4.7 Focus Visible (AA). When an element has keyboard focus, there should be a visible indicator, usually an outline. Some embeds and themes remove the outline for looks, which leaves keyboard users guessing.
2. 2.4.3 Focus Order (A). Focus should move in an order that makes sense. This is where pop-ups and lightboxes often go wrong: the window opens visually, but focus stays behind it on the page.

The W3C’s ARIA Authoring Practices Guide describes how a modal dialog, which is what a lightbox is, should behave with a keyboard:

You don’t need to read code to test this. Open the lightbox with the keyboard, press Tab a few times and watch where the outline goes, then press Escape.

Names for buttons and links

Criterion 4.1.2 asks that interface components have a name and role that assistive technologies can determine. In practice, the most common failure in embeds is the icon-only button: an arrow, an × or a heart drawn with an icon, with no text. A screen reader announces “button”, and the user has to guess what it does.

Good embeds give these buttons an accessible name, often with aria-label, such as “Next image” or “Close”. When you test with a screen reader, listen for buttons that are announced without a name, and for links that all say the same thing.

Motion, autoplay and sound

Moving content can be distracting for everyone and a real barrier for some people, including people with attention-related disabilities and people who need time to read. Criterion 2.2.2 asks for a way to pause, stop or hide content that moves, blinks or scrolls on its own for more than five seconds alongside other content.

The W3C’s explanation of 2.2.2 makes two points that matter for social embeds. First, auto-advancing carousels count as auto-updating content, and there is no five-second exception for those, so a slider that moves on its own needs a pause control. Second, content can “start automatically” even after an indirect action, such as scrolling it into view or hovering over it.

Sound is covered separately. Criterion 1.4.2 says that if audio plays automatically for more than three seconds, users need a way to pause or stop it, or to control its volume independently. Video that starts muted avoids the problem, which is also why browsers generally only allow muted autoplay.

For a layout-level view of this, our article on grid or slider layouts explains why a slider that only moves when visitors use the arrows is the calmer choice.

Video captions

Criterion 1.2.2 asks that prerecorded video with audio has captions. The W3C’s captions guidance notes that captions help people who are Deaf or hard of hearing, people who can’t play sound at that moment, and people who simply take in text more easily.

Two practical points from the W3C’s page are worth knowing:

1. Automatic captions are a starting point. The W3C says automatically generated captions don’t meet user needs or accessibility requirements unless they are confirmed to be fully accurate. A single dropped word, such as “not”, can reverse the meaning.
2. Open and closed captions differ. Closed captions can be turned on and off by the viewer. Open captions are part of the picture and are always visible.

For embeds, open captions have a practical advantage: they travel with the video wherever it is played, because they are part of the image. A separate captions track only shows if the player that displays the video supports and loads it.

Contrast and target size

Embeds often bring their own small, light gray text: post counts, dates, credits, “view more” links. Criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Light gray on white often falls short.

Criterion 2.5.8, new in WCAG 2.2, asks that pointer targets are at least 24 by 24 CSS pixels, with exceptions such as targets that have enough space around them. Small arrows, close buttons and icon links in embeds are the usual suspects.

How to test an embed in fifteen minutes

You don’t need special training to catch the most common problems. The W3C’s “Easy Checks” page is a good companion; it also reminds readers that passing quick checks doesn’t guarantee a page is accessible. A simple routine:

1. Unplug the mouse, mentally. Click in the browser’s address bar, then press Tab repeatedly through the page. Note whether you can reach every link and button in the embed, whether you can see where focus is, and whether you can get past the embed.
2. Try every interaction with Enter and Space. Open whatever the embed opens, such as a lightbox, a menu or a video. Then try to close it with Escape.
3. Turn on a screen reader briefly. VoiceOver is built into Macs and iPhones, Narrator into Windows, and TalkBack into most Android phones. Move through the embed and listen: are images described or skipped sensibly, and do buttons have names?
4. Check motion and sound. Load the page and wait. Does anything start moving or playing on its own? If it does, can you stop it?
5. Zoom to 200%. Use the browser zoom. Text should stay readable and nothing important should be cut off.
6. Check contrast on small text. Use a contrast checker on any light gray text inside the embed.

Our widget today: an honest look

We make Social Feed by grip space, an Instagram feed widget, so it’s fair to apply the same checklist to it. Here is how the current version behaves, checked against the widget’s code. We’d rather you know this before you add it than discover it later.

In short: mouse, touch and keyboard users can all open posts, and a screen reader user hears a description for each photo. The weakest point is the descriptions themselves: a caption fallback or a generic label is not real alt text, so write alt text on Instagram for the posts that matter. Decorative icons, such as the play and carousel marks, are hidden from screen readers. Our article on lightbox or link to Instagram covers the click options and keyboard behavior in more detail.

Some limits remain: there is no field in the dashboard to type alt text per post, captions in the lightbox are plain text, and videos have no separate captions track. So the approach recommended for any embed still applies: treat it as extra, and make sure your page works without it.

Make your page work without the embed

You can’t change a third-party embed’s markup, but you control everything around it. These steps help regardless of which embed you use:

1. Put essential information in your own text. Prices, opening hours, dates, menus, booking details and offers belong in the page’s text, not only in a photo caption or an image of a flyer. A feed should show what you’ve already said, not be the only place it’s said.
2. Add a real heading above the embed. A heading such as “Recent photos from our Instagram” helps screen reader users understand what the section is and skip it if they want.
3. Add a plain text link. A sentence such as “See all our posts on Instagram (opens in a new tab)” gives everyone, including keyboard users, a route to the full content. Mentioning the new tab follows the W3C’s advice to warn users before opening one.
4. Describe the gist in a sentence. If the feed shows your work, a short line of text above it, such as “Weekly photos of finished kitchen renovations”, tells people who can’t see the images what they would find there.
5. Keep embeds out of critical paths. Don’t place a feed between a visitor and a form, a checkout button or your main call to action. Someone tabbing through the page should reach those first.
6. Choose calm settings. Prefer embeds that don’t autoplay, don’t auto-advance and start video muted.

Accessibility-friendly settings in Social Feed

Within the current widget, a few settings make the feed calmer and clearer:

If you set On click to Do nothing, the feed becomes a pure visual element: tiles leave the Tab order, and the account header’s Follow button becomes the single route to Instagram. On pages where you want a simple, predictable experience, that’s a reasonable choice. See matching the feed to your website design for color and font settings.

Video posts: decide case by case

If your Instagram includes Reels or other videos with speech, think about captions before you show them on your website. Videos with open captions, where the text is part of the video picture, carry their captions into the lightbox. Videos that rely on captions added only as a separate setting may play without them on your page. If many of your videos have speech without open captions, you can turn video posts off for a widget, or use the Reels filter to exclude Reels. Our guide to Instagram videos on your website covers the video settings.

Common mistakes with embeds

1. Only testing with a mouse. Most embed problems are invisible until you press Tab.
2. Putting important information only in images. A flyer in a feed is invisible to screen reader users and hard to read on small screens.
3. Removing focus outlines in your theme. If your site’s CSS removes outlines globally, it removes them from embeds too. Keep a visible focus style.

Frequently asked questions

Is a caption a good alt text? Sometimes, but often not. A caption is written to accompany a photo, not to replace it, so “New this week!” describes nothing. That’s why the widget uses your Instagram alt text first, and why we recommend putting important information in your page text.

Can I add alt text to the feed images myself? Yes, on Instagram. The widget uses the alt text you write there when Instagram’s API returns it. There is no separate alt text field in the Social Feed dashboard.

Do I need my own code to make the tiles keyboard-accessible? No. Tiles that open the lightbox or Instagram are already focusable. We don’t recommend editing the widget’s output with your own scripts; it’s generated fresh on every page load and may change. A heading and a text link around the widget are still worth adding.

Is a slider less accessible than a grid? A slider that advances automatically raises extra issues under criterion 2.2.2. Ours doesn’t move on its own, so the main difference is that the grid shows everything at once without scrolling, which many visitors find simpler.

Get started

If you decide an Instagram feed suits your site, create a free Social Feed account and add a heading and a text link around it as described above. The setup guides for WordPress, Shopify, Wix, Squarespace, Webflow and plain HTML show where the code goes. If accessibility is important for your site and you’d like to tell us what you need, write to info@grip-space.co.jp.

Sources

1. W3C WAI, “How to Meet WCAG (Quick Reference)”, WCAG 2.2: https://www.w3.org/WAI/WCAG22/quickref/
2. W3C WAI, “Understanding Success Criterion 2.2.2: Pause, Stop, Hide”: https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html
3. W3C WAI, Images Tutorial, “Decorative Images”: https://www.w3.org/WAI/tutorials/images/decorative/
4. W3C WAI, ARIA Authoring Practices Guide, “Dialog (Modal) Pattern”: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
5. W3C WAI, “Captions/Subtitles”: https://www.w3.org/WAI/media/av/captions/
6. W3C WAI, “Easy Checks – A First Review of Web Accessibility”: https://www.w3.org/WAI/test-evaluate/easy-checks/
7. W3C, “G201: Giving users advanced warning when opening a new window”: https://www.w3.org/WAI/WCAG22/Techniques/general/G201