Super.so Accessibility Checklist 2026 | WCAG 2.2 AA & EAA Compliance
Last updated: 2026-06-11
Super.so (now simply Super) turns Notion pages and databases into fast, public-facing websites, adding a custom domain, themes, a navbar and footer, and the ability to inject custom CSS and JavaScript. Because the content lives in Notion and Super renders it to HTML, your site's accessibility is split between two sources: what Notion's block model produces, and what Super wraps around it. That split is where the surprises are. Notion's editor encourages you to build structure visually - you make text big and bold to act as a section title instead of using a real Heading block, you stack toggle blocks and callouts that may not expose their state or role correctly once rendered, and you tint text with Notion's color options that exist purely for decoration. Notion's image alt support is limited and easy to skip, so informative images and screenshots publish with no text alternative. Database-driven pages rendered as galleries, tables, or boards add their own questions about reading order, headers, and whether cards are keyboard-operable. On top of all that, Super contributes the site chrome - the navbar (including its mobile menu), the theme's colors and fonts, and anything you add through custom code - each of which can pass or fail independently of the Notion content. With the European Accessibility Act now enforceable for businesses serving EU consumers and ADA Title III obligations applying in the United States, a Super site is in scope just like any other website, and 'it's just Notion' is not a defence. This checklist covers the issues we see most often on Super.so sites and the specific Notion and Super practices that fix each one. None of this is legal advice; consult a qualified attorney for your jurisdiction.
Common Accessibility Issues
In Notion it is tempting to make a line of text large and bold to act as a section title rather than using a Heading 1/2/3 block. When Super renders the page, that styled text becomes an ordinary paragraph, not a heading, so screen reader users navigating by heading skip right past it and the page has no usable outline. Conversely, using Notion's Heading levels out of order produces a broken outline once rendered.
Use Notion's Heading 1, Heading 2, and Heading 3 blocks for all section titles, in logical order, and never substitute bold body text for a heading. Be aware that Super typically renders the Notion page title as the page's H1, so structure your in-page Heading blocks beneath it without introducing a second competing H1. Review the rendered page's heading outline, not just how it looks in Notion.
<!-- Notion bold paragraph rendered as a fake heading -->
<p><strong>Our Pricing</strong></p><!-- Notion Heading 2 block rendered as a real heading -->
<h2>Our Pricing</h2>Notion's support for image alt text is limited and the field is easy to overlook, so images, screenshots, and diagrams on a Super site frequently render with empty or filename-based alt. Informative images - product shots, infographics, screenshots that carry instructions, banners with text baked in - then convey nothing to screen reader users, and image-only content becomes inaccessible.
Add a caption or alt text to every informative image in Notion (use the image block's caption/alt option where available), describing what the image communicates. For an image that contains important text, reproduce that text in the caption or as real text on the page. Where Notion's alt control is insufficient, place a short descriptive caption beneath the image so the information is not image-only, and treat purely decorative images accordingly.
<img src="screenshot1.png" alt=""> <!-- instructional screenshot, no alt --><img src="screenshot1.png" alt="Settings page with the Notifications toggle switched on">Notion toggle blocks (collapsible sections) and callouts are popular for FAQs and notes, but when rendered by Super the toggle's expand/collapse control may not be a real button, may not expose aria-expanded state, and may hide its content from assistive tech while collapsed without announcing that it can be opened. Screen reader and keyboard users then cannot tell a toggle exists or operate it, so collapsed content - often important FAQ answers - is effectively missing.
Verify in the rendered site that each toggle's header is keyboard-focusable, operable with Enter or Space, and exposes aria-expanded that updates as it opens and closes, with the content programmatically associated. If Super's default rendering does not provide this, add custom CSS/JS to enhance the toggle markup, or avoid hiding essential content (like key FAQ answers) inside toggles. For callouts, ensure any icon is decorative (aria-hidden) and the text meets contrast.
<div class="toggle" onclick="open()"> ▸ Question</div>
<div class="toggle-content" hidden>Answer...</div><button class="toggle" aria-expanded="false" aria-controls="a1">Question</button>
<div id="a1" class="toggle-content" hidden>Answer...</div>Two contrast risks combine on a Super site. First, the Super theme sets site-wide text, link, and background colors that can fall below the minimum, especially light text on tinted backgrounds. Second, Notion's text and background color options - gray text, colored highlights - are decorative and often produce body text well under 4.5:1 once rendered, with no warning in either tool.
Check the theme's body text, link, heading, and button colors against the 4.5:1 (normal) and 3:1 (large/UI) minimums and adjust in Super's theme settings or with custom CSS. Avoid Notion's lighter text colors (gray, and pale tints) for body content, since they commonly fail; reserve color for emphasis backed by another cue, never as the only way to convey meaning. Re-check link and hover colors.
/* Notion gray text on white - about 3.5:1, fails body text */
.notion-text.gray { color: #9b9b9b; }/* Adjusted via Super custom CSS to about 7:1 */
.notion-text.gray { color: #5a5a5a; }Super renders Notion databases as galleries, lists, tables, or boards. Gallery and board cards are often clickable containers that are not reachable or operable by keyboard, table views may render without proper header associations so screen reader users cannot tell which column a cell belongs to, and the visual reading order of a multi-column gallery may not match the DOM order, scrambling the experience for assistive tech.
Ensure each clickable database card is a real link or button that receives keyboard focus and shows a visible focus indicator, with an accessible name (usually the card's title). For table views, confirm column headers are marked up as table headers (th with scope) so cell-to-header associations are announced. Check that the DOM order of cards matches the visual order. Test browsing and opening database items with the keyboard alone.
<div class="gallery-card" onclick="go('/post-1')"> ... </div> <!-- not focusable --><a class="gallery-card" href="/post-1"> ... </a> <!-- real link, keyboard-reachable -->Notion content often contains links written as 'click here', 'read more', or bare pasted URLs, and database cards may all link with generic wording. When a screen reader user lists the links on a Super page, these give no indication of destination, failing WCAG 2.4.4 Link Purpose, and bare URLs are read out character by character, which is tedious and uninformative.
Write descriptive link text that makes sense out of context - 'Read the 2026 pricing guide' instead of 'click here', and a real label instead of a pasted URL. In Notion, select the text you want as the link and apply the link to it rather than pasting the raw address. For database cards, make sure the linked title is descriptive so the card's accessible name is meaningful.
<a href="/pricing">click here</a>
<a href="/guide">https://example.com/guide</a><a href="/pricing">View our 2026 pricing</a>
<a href="/guide">Read the accessibility guide</a>Super's navbar adds site navigation on top of the Notion content, including a hamburger toggle at the mobile breakpoint. If the hamburger is rendered as a div or icon without button semantics, an accessible name, or aria-expanded state, keyboard and screen reader users cannot open the menu on mobile, and dropdown items that reveal on hover alone are unreachable by keyboard.
Confirm the mobile menu toggle is a real button with an accessible name (aria-label="Menu") and an aria-expanded value that updates as it opens and closes, that every navbar link is reachable and operable with Tab and Enter, and that any dropdown opens on focus and click rather than hover alone and can be closed with Escape. Where Super's default does not do this, enhance it with custom JS. Test the navbar by keyboard at both desktop and mobile sizes.
<div class="super-navbar__toggle" onclick="toggle()"></div><button class="super-navbar__toggle" aria-label="Menu" aria-expanded="false" aria-controls="nav">
<span aria-hidden="true">☰</span>
</button>Super.so-Specific Tips
- Use real Notion Heading blocks (H1/H2/H3) in order for every section title; never make bold body text stand in for a heading. Remember Super renders the page title as the H1.
- Add a descriptive caption or alt to every informative image in Notion; for images that carry text, reproduce that text, since Notion's alt support is easy to skip.
- Check that rendered toggles are real buttons with aria-expanded, and avoid hiding essential FAQ answers inside toggles that may not be operable.
- Avoid Notion's gray and pale colored text for body content - it commonly fails 4.5:1 - and verify the Super theme colors with a contrast checker.
- Make database gallery and board cards real links/buttons that are keyboard-focusable, and confirm table views use real header cells.
- Verify the Super navbar's mobile hamburger is a real button with aria-expanded and an accessible name, and that dropdowns open on focus, not hover alone.
Recommended Tools
axe DevTools
Browser extension for automated WCAG testing. Run it on the published Super site (not inside Notion) to catch missing alt text, low contrast, broken headings, and unlabelled navbar and toggle controls in the rendered HTML.
WebAIM Contrast Checker
Check the Super theme colors and any Notion colored text against the 4.5:1 and 3:1 minimums; both Notion and Super let you ship low-contrast text with no warning.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing confirms how Notion blocks render in practice - whether toggles announce their state, headings form an outline, images have alt, and database cards have meaningful names - which automated tools cannot fully judge.
Keyboard-only testing (Tab, Enter, Escape)
Operate the published Super site with the keyboard to expose the most common failures: an unopenable mobile navbar, hover-only dropdowns, non-focusable gallery cards, and toggles you cannot expand.
Lighthouse (Chrome DevTools)
Built-in Chrome audit that flags contrast, alt-text, and accessible-name issues on the rendered Super page. Use it as a first pass, then confirm with manual keyboard and screen-reader testing.
Super.so Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Headings Notion blocks | Bold text used as fake heading | 1.3.1 | Use real Heading 1/2/3 blocks in order | |
| Images Notion image blocks | Alt skipped; limited Notion support | 1.1.1 | Caption/alt describing the image | |
| Toggles collapsible FAQs | Not a button; no aria-expanded | 4.1.2 | Operable button; don't hide essentials | |
| Color theme + Notion text | Gray text/theme below 4.5:1 | 1.4.3 | Fix theme; avoid pale Notion colors | |
| Navbar Super mobile menu | Hamburger not openable by keyboard | 2.1.1 | Real button with aria-expanded |
Frequently Asked Questions
If my content is in Notion, who is responsible for accessibility - Notion or Super?
Practically, you are, and the work is split across two layers you both influence. Notion's block model decides a lot: whether you used real Heading blocks or just bold text, whether your images have alt, whether your links are descriptive, and which colors your text uses. Super decides how those blocks render to HTML and adds the site chrome - the navbar and mobile menu, the theme colors and fonts, and any custom CSS/JS you inject. Either layer can fail independently: perfectly structured Notion content can still ship with a low-contrast theme or an unopenable mobile menu, and a clean Super theme can still render a page with no headings because you used bold text. So treat the rendered, published site as the thing under test - run an automated scan and manual keyboard and screen-reader checks on the live URL - and fix issues in whichever layer they originate, using Notion blocks correctly and Super's theme settings or custom code as needed.
Why do my Notion headings disappear for screen reader users on a Super site?
Almost always because they are not real headings. In Notion it is easy to make a line large and bold to look like a section title instead of using a Heading 1/2/3 block. When Super renders the page, that styled line becomes an ordinary paragraph, so a screen reader navigating by heading skips it entirely and the page has no outline. The fix is to use Notion's actual Heading blocks for every section title, in logical order without skipping levels. Keep in mind that Super typically renders the Notion page title as the page's single H1, so your in-page headings should start at H2 beneath it and not introduce a competing second H1. After publishing, check the rendered page's heading structure with a screen reader or a headings-outline tool rather than judging it from how it looks in Notion.
Can a Super.so site meet WCAG and pass an EAA or ADA audit?
Yes, a Super site can be brought to WCAG 2.2 AA, which is the benchmark behind both European Accessibility Act conformance and US ADA Title III claims, but it takes deliberate work in both Notion and Super. The common audit findings on Super sites - fake headings made from bold text, images with no alt, toggles that are not operable, low-contrast Notion gray text or theme colors, database cards that are not keyboard-reachable, vague link text, and a mobile navbar you cannot open - are all fixable. Use real Notion Heading blocks, add alt text and descriptive links, avoid hiding essential content in non-operable toggles, correct contrast in the theme and avoid pale Notion text, make database cards and the navbar keyboard-operable, and then verify the live site with an automated scanner plus manual keyboard and screen-reader testing. 'It's just Notion' is not a defence; the published website is in scope. This is general guidance, not legal advice; consult a qualified attorney about your obligations.
Further Reading
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.