THOUGHT

The Vendor's Bug Is Still Mine

I found an accessibility fault in my own site's comment widget. It wasn't my code. It was still my problem.

October 18, 2026 · 3 min read by Steve McGarvey

Wireframe of a web page in a browser window. A yellow tag reading main sits on the page's content area. An embedded comment frame lower on the page, outlined with a dashed line, carries a second, identical main tag. — Two main landmarks: one from my page, one from the comment widget inside it.

I was reviewing my own site for accessibility and found pages with two main landmarks. One was the essay. The other was the comment box.

On paper, neither page was wrong. My page has one <main>. The comment widget, giscus, renders inside an iframe, and that iframe’s document has a <main> of its own. Each document passes on its own terms, and automated checkers test frames separately, so they pass it too. Screen readers don’t see it that way. They fold the iframe into the page, so someone jumping by landmark hears “main” twice and has to guess which one is the article. I checked it in VoiceOver: with comments open, the rotor lists two main landmarks.

I couldn’t fix it. The iframe is served from someone else’s domain, and the widget only lets me restyle it. So I did the two things I could do.

First, I changed how comments load. Every article now ends with a Comments heading and a button. Nothing from giscus loads until you ask for it, and when you do, focus moves to the heading so you keep your place. The second main only exists for readers who chose it. As a bonus, nobody’s browser talks to a third party just because they opened an essay.

Second, I told the people who can fix it. I filed giscus/giscus#1734 with the line that causes it and a one-line fix.

Contain it on your side, report it to theirs, and keep the receipt. That’s the job when the fault belongs to a vendor.

Companies run into this at a much bigger scale. In 2014, H&R Block entered a consent decree with the Department of Justice and the National Federation of the Blind over the accessibility of its website and online tax product. Section II, paragraph 12(c), tucked into the conformance timeline, reads:

If H&R Block uses or integrates third-party plug-ins or content, H&R Block shall provide a method of obtaining and using such content that conforms to WCAG [Web Content Accessibility Guidelines] 2.0 AA, except that at present, H&R Block uses a third-party plug-in to display the map location of its physical offices. This plug-in is not in conformance with WCAG 2.0 AA. No later than three (3) years after the Effective Date, H&R Block will provide a method of obtaining and using map content that conforms to WCAG 2.0AA

The vendor wrote the plug-in. H&R Block answered for it.

That moves the real work upstream, to the moment you pick the vendor. Any service that runs inside your page through an iframe brings its accessibility along with it, so accessibility belongs in the vetting next to security and price. Ask for their conformance report. Put a screen reader and a keyboard through their widget before anyone signs. Find out who fixes it when it breaks, and how fast. I didn’t do that with giscus. I found the problem the way most teams do, after launch. By then you can only contain their faults, and containing them is the expensive path.

My site is a lot smaller than H&R Block. The rule doesn’t scale down.