According to the spec, a seamless iframe should not be announced as a new browsing context to AT users, whereas a regular iframe should. See also comment 12 and 13 in bug 45950 https://bugs.webkit.org/show_bug.cgi?id=45950#c12
I've confirmed that voiceover announces "frame" for a seamless iframe, unlike a div, where it reads the contents of the div. You have to tell VO to navigate inside the frame to read the contents. I am unfortunately not familiar enough with WebCore's AX code to fix this. I looked around to see if there was an easy way to change the role of the frame, but it seems to be handled by a separate system from the AX roles. Someone with AX knowledge will have to comment. :)
When determining the AX role we'd check for this attribute and return a GroupRole instead. We'd then need to make sure that the code the connects frames to their parent documents in the AX hierarchy didn't break because the frame no longer identified as a Web Area. We'd also want to hide the Scroll Area parent that probably exists in the AX hierarchy (but is not visible)
rdar://11452561
The only bit that you'll need to check is HTMLIFrameElement::shouldDisplaySeamlesslyWithParent() or Document::shouldDisplaySeamlesslyWithParent(). Both return the same thing but can be asked from either side (depending which pointer you happen to have). That single bool-returning function controls the entire operation of seamless. Assuming the AX tree is sensitive to rendering tree changes, it should notice any dynamic update of seamless, but I'm happy to help you write tests for that if needed.
Created attachment 179692 [details] patch
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment on attachment 179692 [details] patch Attachment 179692 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15378558
Comment on attachment 179692 [details] patch OK. I thought there was a FIXME in the code somewhere? Or an existing bug... maybe we just discussed this over IRC. <iframe seamless> is in a 95%-shippable state. We are discussing disabling it for Chrome, as it's currently w/o an owner and needs a few bug fixes before it's robust enough for adoption. This is still a good fix to have regardless, of course. :) Looks like you got a cr-linux failure, btw.
Created attachment 179693 [details] patch
Comment on attachment 179692 [details] patch Attachment 179692 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/15361692
Nm, this was the bug I was thinking about.
Comment on attachment 179693 [details] patch Attachment 179693 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15375631 New failing tests: platform/mac/accessibility/seamless-iframe.html
Created attachment 179756 [details] patch for landing
http://trac.webkit.org/changeset/137962