Accessible HTML Email: What the Builder Handles and What's Still on You

Why role=presentation matters (and why the builder adds it for you)

Email layout is built out of tables — not because anyone likes tables in 2026, but because desktop Outlook on Windows still renders through Microsoft's Word engine, which ignores flexbox and grid and effectively requires table-based layout (as of June 2026). The problem: a screen reader, encountering a <table>, assumes it's a data table and announces rows, columns, and cell counts — turning your tidy two-column header into 'table, three columns, four rows' noise that buries the actual message. The fix is one attribute: role="presentation" on every layout table, which tells assistive technology 'this table is for visual arrangement only — skip the grid semantics and just read the contents in order.' This is exactly the kind of mechanical, easy-to-forget markup a builder should own. BuilderJS's EmailExportPipeline converts your visual flexbox/grid design into nested email tables and emits them with role="presentation" as part of the export, so the structural scaffolding is announced correctly without you hand-editing markup. That's the 'for free' part: you don't decide table-by-table whether to add the attribute, and you can't forget it.

Live HTML text beats text baked into images — every time

The single highest-impact accessibility choice in email is also a deliverability and rendering choice: keep your words as live HTML text, not as pixels inside a picture. Text inside an image is invisible to screen readers, can't be resized or reflowed by a reader who zooms, won't adapt to dark mode, isn't selectable or translatable, and vanishes entirely when a client blocks images by default (many do). A headline rendered as a JPG is a headline that a blind subscriber, a low-vision subscriber, and an images-off subscriber all simply never receive. Because BuilderJS is a builder of live HTML — headings, paragraphs, buttons, and lists are real text elements you style with fonts, colors, and sizes — your copy stays as text that the export pipeline carries through to the inbox as text. The pipeline also inlines CSS and generates @media rules for mobile stacking and fluid images (max-width:100%; height:auto), so live text reflows and scales rather than breaking. The author's job here is restraint: resist the temptation to 'design' a headline as artwork in an image just because it looks crisp in the preview. If it's words, make it text.

Real alt vs decorative alt='' — the judgment only you can make

Every <img> needs an alt attribute, but 'needs alt' splits into two opposite cases, and getting them right is editorial, not mechanical. An informative image — a product photo, a chart, a logo that identifies the sender — needs descriptive alt text that conveys what a sighted reader gets: alt="Blue running shoe, side view" not alt="image" or alt="DSC_4471.jpg". A decorative image — a divider line, a background flourish, a spacer — should carry an explicitly empty alt="" so screen readers skip it silently instead of announcing a filename or 'graphic.' Both are correct; the wrong move is leaving alt off entirely (readers may then read the URL aloud) or writing alt for decoration that should be silent. BuilderJS gives every image an alt-text field in the editor and carries your value through export, so the plumbing is there on every image — but the builder cannot know whether a given graphic is meaningful or decorative, or what the meaningful ones should say. That's the boundary: the editor guarantees the attribute exists and is editable; you supply the words, and you decide which images get alt="". Charts deserve special care — pair them with a text summary nearby, since a long alt string is a poor substitute for the data.

Semantic headings, descriptive links, and a plain-text alternative

Three more author-owned habits round out an accessible email. First, semantic headings: use real heading elements in a logical order (one main heading, then sub-sections beneath it) so screen-reader users can navigate by structure and skim the way sighted readers skim — don't fake a heading by just enlarging a paragraph, and don't skip levels for visual effect. Second, descriptive link text: screen-reader users often pull up a list of just the links, stripped of surrounding sentences, so 'Click here' and 'Read more' repeated five times are useless out of context — write links that describe their destination, like 'See the spring collection.' Third, ship a plain-text alternative alongside the HTML part (a multipart message): it's the ultimate fallback for text-only clients, smartwatches, screen readers that prefer it, and aggressive spam filters, and it improves deliverability as a bonus. These three are choices made while authoring, so they live with you, not the tool — but BuilderJS supports them by giving you genuine heading and text elements to mark structure properly, real link text fields, and clean exported HTML that a downstream system can pair with a plain-text part. The builder produces sound, semantic markup; you make the editorial calls that turn sound markup into a genuinely accessible message.

The honest split: accessible base from the builder, judgment from you

It's worth stating plainly because plenty of marketing won't: no email builder can hand you a guaranteed WCAG pass, and BuilderJS doesn't claim one. Accessibility is half markup and half meaning. The markup half — role="presentation" on layout tables, live text instead of image-text, an alt field on every image, real semantic heading and link elements, inlined CSS and responsive @media so content reflows — is exactly what an embeddable editor can and should automate, and that's what BuilderJS emits as your accessible foundation through its export pipeline, the same pipeline whose 30+ templates and 200+ samples are Litmus-tested across 22 email clients. The meaning half — what each image conveys, which images are decorative, whether a heading order reflects the content's real structure, whether a link describes where it goes, what the plain-text version says — is judgment the tool can't supply. The right mental model: BuilderJS removes the tedious, error-prone, easy-to-forget structural work so it's correct by default, which frees you to spend your attention on the editorial decisions that actually require a human. And because BuilderJS is the editor you embed and self-host — not a sending platform — it builds the accessible markup and exports it; your own sending stack delivers it (including the plain-text part). You can try the editor and inspect its exported markup on the live demo at builder.emotsy.com.

Frequently asked questions

• Does BuilderJS make my email WCAG-compliant automatically? expand_more

  No, and any tool that promises a one-click WCAG pass is overstating it. BuilderJS emits the accessible base markup automatically — layout tables marked role="presentation", live HTML text rather than text-in-images, an alt field on every image, and real semantic heading and link elements — plus inlined CSS and responsive @media for reflow. But compliance also depends on editorial judgment the tool can't make for you: writing meaningful alt text, marking decorative images alt="", ordering headings logically, and writing descriptive links. The builder handles the structural half; you own the judgment half.

• What does role="presentation" do on a table, and do I have to add it myself? expand_more

  It tells screen readers that a table is for visual layout only, so they skip the row/column/cell announcements and just read the contents in reading order — without it, a layout table gets announced as a data grid, which is confusing noise. You don't add it by hand in BuilderJS: the EmailExportPipeline converts your design to nested email tables and emits them with role="presentation" automatically, since Outlook's Word-based engine still requires table layout. That's part of the accessible base the builder gives you for free.

• When should alt text be descriptive, and when should it be empty (alt="")? expand_more

  Use descriptive alt text for any image that carries meaning — a product photo, a chart, a sender-identifying logo — so a screen-reader user gets what a sighted reader gets. Use an explicitly empty alt="" for purely decorative images like dividers or background flourishes, so readers skip them silently. The wrong move is omitting alt entirely (a reader may then read the file URL aloud). BuilderJS provides an alt field on every image and carries your value through export, but it can't decide which images are meaningful — that call, and the wording, are yours.

• Why is live HTML text more accessible than putting text inside an image? expand_more

  Text baked into an image is invisible to screen readers, can't be resized by readers who zoom, won't adapt to dark mode, isn't selectable or translatable, and disappears when a client blocks images — which many do by default. Live HTML text avoids all of that. Because BuilderJS builds real text elements (headings, paragraphs, buttons), your copy stays as text and the export pipeline carries it to the inbox as text that reflows and scales. The author's job is to resist designing headlines as artwork inside images.

• Does BuilderJS generate the plain-text version of my email? expand_more

  BuilderJS is the editor — it builds and exports the HTML part, including the accessible markup. It doesn't send, and the plain-text alternative is paired with the HTML by your sending stack as part of the multipart message your ESP or backend assembles. A plain-text part is worth shipping: it's the fallback for text-only clients and some screen-reader setups, and it helps deliverability. So author your content as live text in the builder, export the HTML, and have your own sending path attach the plain-text alternative.