[Config 2025] Figma Sites is here — let's hear what you think!

### What we heard Here are the most common and impactful themes raised by the community here in Figma Forum: **1. Accessibility: Export Options & Integration Flexibility** A key request was the ability to export clean, semantic HTML/CSS or integrate Figma Sites with existing CMS tools. Many of you see Figma Sites as a powerful tool — if it can fit into their broader publishing and dev ecosystems. … - **Export & CMS Support:** Code export and CMS integrations are top-of-mind. While not available yet, these areas are being explored for future roadmap considerations — especially as more teams request publishing flexibility. - **Font Fidelity & Customization:** Good news — custom fonts support is coming soon. We’ve heard your reports on Google Fonts and variable text rendering inconsistencies. These issues are under investigation, and we’re reviewing how font handling can better match your design file expectations. … - **Component Behavior & Breakpoints:** Multiple users noted differences between Figma Design and Sites when it comes to variables, auto layout, and component states. We’re reviewing this feedback to smooth out those inconsistencies and make responsive behavior more predictable and performant. For more details and latest updates, keep an eye on this article: Create a responsive component that automatically adapts to each breakpoint. … ... A big worry-flag for me, without knowing more around the tool (so I can be totally wrong), is the fact that in the demo’s I saw people use it in a “Copy and paste your designs from Figma into Sites”, which… totally defeats the point of having everything in 1 tool. … I highly recommend checking out the Authoring Tool Accessibility Guidelines, published by the W3C: https://www.w3.org/WAI/standards-guidelines/atag/ for some evaluation criteria for Figma Sites as an accessible authoring tool. I was excited for this when it was initially mentioned, but if the sites are going to be only be divs, it is essentially impossible to release accessible websites with it. Meaning most businesses globally can't use it without risking litigation or having their product pulled from the market. I hope that as you iterate on this product you ensure the folks paying to use it are set up for success. … 1. Accessibility settings are hidden by default - you have to manually add them to each layer. Why can’t we make these settings already visible? 2. No high-level view of applied tags - you have to click into every single layer to check. 3. Everything defaults to a <div>. Why can’t we utilise the purpose of some of the Blocks to add some basic semantics? … 8. aria-label is added everywhere, sometimes duplicating visible content or mislabeled as “alt text.” This could cause WCAG 2.5.3: Label in Name failures. Also, now I have tested this more, if you apply a tag to something like a heading, the usage of aria-label duplicating the intenral <div> actyually makes the heading completely inaccessible to VoiceOver, where it doesn’t read the content of the heading due to the ‘grouped’ element inside it with aria-label. So **applying accessibility tags can actually make it worse for users**. 9. Default content blocks aren’t accessibility-ready - e.g., poor reading order in card layouts where images are above their heading - means screen readers will here a related image before the heading - have we considered keyboard and reading focus order? 10. No functionality possible like skip links. … 1. Accessibility settings are hidden by default - you have to manually add them to each layer. Why can’t we make these settings already visible? 2. No high-level view of applied tags - you have to click into every single layer to check. 3. Everything defaults to a <div>. ... 8. aria-label is added everywhere, sometimes duplicating visible content or mislabeled as “alt text.” ... Also, now I have tested this more, if you apply a tag to something like a heading, the usage of aria-label duplicating the intenral <div> actyually makes the heading completely inaccessible to VoiceOver, where it doesn’t read the content of the heading due to the ‘grouped’ element inside it with aria-label. ... 9. Default content blocks aren’t accessibility-ready - e.g., poor reading order in card layouts where images are above their heading - means screen readers will here a related image before the heading - have we considered keyboard and reading focus order? 10. No functionality possible like skip links.