For me, it’s the same as daho86: I have registered but have not received a confirmation. Is that ok? When will I be informed whether I can take part?
Quick update: it is now possible to participate also with a Fairphone (Gen. 6) 
Send the form in for the FP6 which is now my daily phone unlike the FP4
Just managed to complete it, after missing the last one. [1]
For future respondents, if, like me, you were unable to see the “Next” button on the second page of support.fairphone.com/hc/en-us/articles/25144350556306-Beta-programme, invoke the Google Docs iFrame in a separate tab. The option to do so, at least in firefox-143.0.4-1.fc42 (I don’t see it in chromium-141.0.7390.76-1), is accessible via the context menu.
@michele.g, I’d report this to Google and/or FP, but Google provides no issue tracker or support avenue for Docs, and FP’s ZD appears too overwhelmed for this.
Thanks for flagging this @rokejulianlockhart!
Unfortunately, iframes can’t be scrolled. Additionally, due to limitations with Google Forms, there’s no way to auto-resize the iframe dynamically according to its content, therefore we have to use a fixed height for it.
It was tested to make sure the content could be seen correctly, but it could be that in certain languages the content needs more space vertically.
Considering these limitations, I’ve now assigned to it more vertical space buffer. Let me know if it now works for you!
@michele.g, I’m only using Eng-GBr-OxEnDict, so it could be because I utilise browser.display.use_document_fonts: 0 with font.name.monospace.x-western: monospace (as an accessibility feature):
-
rpm -qf "$(fc-match -v monospace | awk -F '"' '/file:/ {print $2}')" -
google-noto-sans-mono-fonts-20250301-1.fc42.noarch
I know that at least WebKit supports the scrolling attribute:
However, I can’t even find the iFrame in your site’s DOM — only a form element — so I might not know what I’m talking about.
It does. Thanks. Though, shan’t it continue to break for anyone using > 1em for their font\.size.*? That seems like a significant accessibility defect.
In general, this is a supported feature. However, in Zendesk Knowledge (which we use for our support articles), Zendesk applies different forms of sanitization to iframes, for security reasons. This can make iframes behave differently.
For now, there’s not much else we can do, but we’ll look into possible alternative solutions.