An iframe embeds one document inside another. A map, a video player, a payment form, a chat widget. What matters is that it is a whole separate document with its own focus behaviour rather than a styled box, and every consequence follows from that. Each one carrying content a person can use needs a name saying what is inside it, and the conventional way to give it one is a title attribute on the iframe. That attribute sits on your markup rather than the vendor's, which is the answer to we cannot fix it, it is theirs. The W3C technique for it serves two rules. Giving a component a name, and grouping repeated content so it can be skipped.
In practice
The title on the iframe and the title element inside the embedded document are two different things, and W3C says to provide both. The one inside the frame belongs to the vendor. The one on the element is yours, and its test has two parts rather than one. The attribute has to be there, and it has to describe what is in the frame, so a frame titled iframe passes the first half and misses the entire point of the second.
Being a separate document explains the rest. Focus inside a frame belongs to that document, which is why a keyboard trap inside a cross-origin embed cannot be fixed from the page around it. It fails your page anyway, because the no keyboard trap rule applies to all content on a page whether you rely on it or not. The sandbox attribute can make things worse without anybody noticing. A sandboxed frame denied scripting cannot manage its own focus, and one denied modals loses the browser's own alert, confirm, prompt and print dialogs, which is narrower than it sounds and still enough to break a payment flow built on them.
Lazy loading is the auditing trap. The frame is in the document all along, and what has not happened is the load, so the tool finds an element with nothing inside it and reports nothing about the content. A human who scrolls down finds a booking form. A page carrying iframes has more than one document, and a tool that walks only the top one has not examined the checkout.
Why it matters
Iframes are where third-party accessibility problems go to hide. A clean scan of a page carrying an embedded booking form has usually not looked inside the booking form. The visitor cannot tell the difference between your site and the widget you dropped into it. The one fix that is always yours is the title. It costs a sentence, it needs no cooperation from the vendor, and it turns four mystery frames on a page into four things somebody can decide whether to enter.
The check people forget
Present is only half the test. A frame titled iframe, or widget, has an attribute and still leaves the reader guessing. Guessing costs them a trip into a separate document to find out what they have walked into, and then a trip back out again.
Where this shows up on the site
Related terms
- Accessible nameThe accessible name is what assistive technology announces an element as, the words a screen reader speaks when it lands on a button or a link.
- Focus trapA focus trap is somewhere on a page that keyboard focus can get into and not out of.
- Cookie bannerA cookie banner is the overlay asking permission to set cookies, and it is usually a vendor script laid over the top of a finished page.
- Screen readerA screen reader is software that reads the screen out loud, or sends it to a braille display, for people who cannot see it.
- Automated testingAutomated testing is software that checks a page's code for the accessibility failures a machine can prove.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.