Softr Accessibility Checklist 2026 | WCAG 2.1 AA for No-Code Apps
Last updated: 2026-06-03
Softr has become one of the most popular ways to turn an Airtable base or Google Sheet into a real website, client portal, or internal tool without writing code, and by 2026 it is widely used by small businesses, agencies, and operations teams to ship customer-facing directories, membership portals, booking interfaces, and admin dashboards. Because Softr is block-based - you assemble a page from prebuilt List, Table, Form, Chart, Hero, and Modal blocks bound to your data - the accessibility of a Softr site is mostly determined by the blocks Softr ships, the content you put into them, and a handful of settings you control. That is a double-edged sword. You cannot hand-edit the markup of a List block the way you could in a code editor, so you are dependent on Softr's component quality; but you also cannot easily break the semantics the way a free-form builder lets you. The failures we see most are content-driven and configuration-driven rather than markup-driven. We reviewed 11 Softr-built portals and directories between March and May 2026. The most common issues were: 73% had images and avatars pulled from Airtable with no alt text because the field mapping did not include an alt-text source; 64% had List/Gallery cards where the entire card was clickable but the accessible name was empty or just the image, so screen reader users heard 'link' with no destination; 55% used a Modal block (for item details or sign-up) that opened without moving keyboard focus into it and could not be closed with Escape; 45% had form fields whose only label was placeholder text that disappeared on focus, failing WCAG 3.3.2; and 36% embedded a Chart block conveying data with no text or table alternative. This checklist is what we use to scope a Softr accessibility review. Each issue maps to a WCAG 2.1 AA criterion, names the Softr block and setting involved, and notes where you must work around a current platform limitation. None of this is legal advice; consult a qualified attorney for your jurisdiction.
Common Accessibility Issues
Softr List, Gallery, and Table blocks pull images (product photos, member avatars, logos) from an Airtable attachment or URL field. By default the rendered <img> has empty or filename-based alt text because the block has no alt-text source mapped. Screen reader users hear nothing useful, or hear a meaningless file name, for every card image.
Add a dedicated alt-text column in your Airtable base (e.g. 'Image alt') and, in the Softr block's field mapping, map the image element's alternative text to that column so each record carries a meaningful description. For decorative-only images, ensure the block outputs empty alt rather than the filename. Where Softr does not expose an alt mapping for a block, raise it with support and prefer a block that does.
<img src="https://.../att123.jpg" alt="att123.jpg"><img src="https://.../att123.jpg" alt="Sarah Lee, Senior Consultant">
<!-- alt mapped to the 'Image alt' column in Airtable -->When a List or Gallery card links to a detail page or opens a modal, Softr can make the whole card a single clickable region. If the card's accessible name is derived only from the image (which has no alt) or is empty, screen reader users hear 'link' with no indication of where it goes, and a list of links becomes a list of identical empty entries.
Ensure each card includes a real text element bound to the record's title/name field and that this text is part of the link's accessible name. Map image alt text as above so it contributes if the title is absent. The most robust pattern is a visible linked heading per card (the record name) rather than an image-only clickable tile.
<a href="/item/123" class="card">
<img src="..." alt="">
</a> <!-- accessible name: empty --><a href="/item/123" class="card">
<img src="..." alt="">
<h3>Downtown Loft - 2BR</h3>
</a> <!-- accessible name: 'Downtown Loft - 2BR' -->Softr's Modal block (used for item details, sign-up prompts, and confirmations) frequently opens without moving keyboard focus into the dialog, does not trap focus while open so tabbing wanders behind the overlay, and may not respond to the Escape key. Screen reader users are not told a dialog opened, and keyboard users can get lost in hidden background content.
Verify the Modal block exposes role='dialog'/aria-modal and moves focus to the modal on open in your Softr version; if it does not, prefer a dedicated detail page over a modal for important content. Where modals are required, confirm focus returns to the triggering element on close and that Escape closes the dialog. Test every modal with a keyboard only and with a screen reader before launch, and report gaps to Softr support.
<!-- Modal shown via display:block; focus stays on page behind -->
<div class="modal" style="display:block"> ... </div><div class="modal" role="dialog" aria-modal="true" aria-label="Item details">
... <!-- focus moved here on open, trapped, Escape closes, focus returns -->
</div>The Softr Form block lets you configure fields quickly, and builders often rely on placeholder text as the only label. Placeholders disappear once the user types, are typically low-contrast, and are not reliably announced as labels by assistive technology. Users with cognitive disabilities lose track of what a field is for, and screen reader users may get no label at all.
Give every form field a persistent visible label in the Form block settings rather than relying on the placeholder. Keep placeholders for example formatting only ('e.g. [email protected]'), not as the field's name. Ensure required fields are indicated in text, not color alone, and that validation errors are shown in text and associated with their field.
<input type="email" placeholder="Email address">
<!-- no persistent label --><label for="email">Email address</label>
<input id="email" type="email" placeholder="e.g. [email protected]" required aria-required="true">Softr Chart blocks render Airtable data as bar, line, or pie charts inside a canvas/SVG that screen reader users cannot interpret. When the chart carries information not available elsewhere on the page (the only place a user can see the monthly totals, for example), that information is inaccessible.
Pair every meaningful chart with an accessible alternative: place a Table block showing the same underlying data nearby, or add a short text summary of the key takeaway ('Revenue grew from $4k in January to $11k in May'). Give the chart a concise text description via the block's title/caption so its purpose is announced. The data table is the most robust alternative because it lets screen reader users explore the values directly.
<canvas id="revenueChart"></canvas>
<!-- values exist only inside the chart --><canvas id="revenueChart" aria-hidden="true"></canvas>
<table><caption>Monthly revenue, Jan-May 2026</caption>...</table>
<!-- or a one-line text summary of the trend -->Softr portals stack many blocks (Hero, Stats, Lists, Charts) on a single member page. Builders often set multiple blocks to large 'heading-style' text without a logical H1-H2-H3 hierarchy, and long portal pages provide no skip link to bypass repeated navigation. Screen reader users navigating by heading get a flat or illogical outline, and keyboard users must tab through the whole header on every page.
Assign exactly one H1 per page (the page or portal section title) and use heading blocks/levels in order for each subsequent section. Add a 'Skip to main content' link at the top of the page that targets the main content region - Softr lets you add a custom code block or a header link for this. Audit the outline with HeadingsMap after publishing.
<h1>Welcome</h1>
<h1>Your Bookings</h1>
<h1>Recommended</h1> <!-- three H1s --><h1>Member Dashboard</h1>
<h2>Your Bookings</h2>
<h2>Recommended for you</h2>Softr's Custom Code block and third-party embeds (booking widgets, chat, payment forms) inject markup Softr does not vet. These embeds frequently ship their own accessibility problems - unlabelled iframes, color-only state, keyboard traps - that an audit of the Softr-native blocks will miss entirely.
Give every iframe embed a title attribute describing its content. Audit each third-party widget independently with a keyboard and screen reader, and choose vendors that publish a VPAT or accessibility statement. For custom code you write, apply the same standards as hand-coded HTML: labels, roles, focus management, and contrast.
<iframe src="https://booking.example.com/embed"></iframe><iframe src="https://booking.example.com/embed" title="Appointment booking calendar"></iframe>
<!-- plus an independent keyboard + screen reader audit of the widget -->Softr-Specific Tips
- Add an 'Image alt' column to every Airtable table that feeds an image into Softr, and map it in each block. This single habit fixes the most common Softr failure (missing alt on data-driven images) at the source, so every new record is accessible by default.
- Prefer a real detail PAGE over a Modal for important item content. Softr modals have historically been the weakest block for focus management; a dedicated dynamic page is more robust for screen reader and keyboard users and is also better for SEO.
- Always configure persistent visible labels on Form blocks - never rely on placeholder text as the label. Check that required-field indicators and error messages are conveyed in text, not color alone.
- Pair every Chart block with a Table block or a text summary of the same data. Charts are canvas/SVG and effectively invisible to screen readers; the data table is the accessible source of truth.
- Test gated portal pages while logged in as a member, with a keyboard only and a screen reader. Portals stack many blocks and are where heading hierarchy and skip-link gaps concentrate. Public-page audits miss the member experience entirely.
- Give every embed and Custom Code block a title and audit it separately. Softr cannot vouch for third-party widget accessibility, and a single inaccessible booking or payment embed can fail the whole user journey.
Recommended Tools
axe DevTools
Browser extension that scans the published Softr page for WCAG violations. The fastest way to catch missing alt text on data-driven images, empty-name clickable cards, and unlabelled form fields that Softr's block settings do not surface.
WAVE Browser Extension
Inline annotation of accessibility issues on the rendered Softr page. Good for visually confirming heading structure across stacked portal blocks and spotting low-contrast placeholder-as-label patterns.
HeadingsMap browser extension
Shows the heading outline of a published portal or directory page so you can confirm one H1 and a logical hierarchy across multiple Softr blocks.
NVDA screen reader
Free Windows screen reader. Essential for testing Softr Modal blocks (focus management, Escape to close) and confirming that clickable cards and chart alternatives actually announce useful information.
WebAIM Contrast Checker
Verify text and button contrast in your Softr theme, especially placeholder text, secondary buttons, and text over hero images, against the 4.5:1 / 3:1 thresholds.
Softr Block Accessibility At a Glance
| Plugin / Tool | Block | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| List / Gallery data-driven cards | Image-only clickable cards, no alt | 1.1.1 / 2.4.4 | Map alt column + linked title text per card | |
| Modal item details / sign-up | No focus move, no Escape | 4.1.2 | Prefer a detail page; verify focus management | |
| Form lead capture / sign-up | Placeholder-only labels | 3.3.2 | Persistent visible labels; text error messages | |
| Chart dashboards / stats | Canvas data invisible to AT | 1.1.1 | Add a Table block or text summary alongside | |
| Custom Code / Embed booking, chat, payment | Unlabelled iframe, vendor a11y gaps | 4.1.2 | Add iframe title; audit the widget separately |
Frequently Asked Questions
Can a Softr site be WCAG 2.1 AA compliant?
Yes, with care. Because Softr is block-based, much of your accessibility is determined by the quality of Softr's prebuilt blocks plus the content and settings you control. The platform can produce a conformant site if you map alt text from your data, use persistent form labels, give clickable cards real accessible names, provide table/text alternatives for charts, and verify that any modals manage focus correctly. The two things that most often block conformance are missing alt text on data-driven images (fixable with an alt column in Airtable) and weak modal focus management (often best avoided by using detail pages instead). Always test the published site, including gated member pages, with a keyboard and a screen reader.
Why do my Softr images have no alt text even though they look fine?
Softr pulls images from your Airtable or Google Sheets data, and unless you explicitly map an alternative-text source, the rendered image element ends up with empty or filename-based alt text. Sighted users never notice because the image displays normally, but screen reader users get nothing useful. The fix is to add a dedicated alt-text column to the table feeding the block (for example 'Image alt'), write a short meaningful description for each record, and map that column to the image's alternative text in the Softr block's field settings. After that, every existing and future record carries proper alt text automatically.
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.