Review Email at Enlarged Text Sizes Before Release

Review a Migma email with enlarged text as well as at a narrow width. A mobile preview can pass while a larger text setting clips a button, overlaps a qualification or hides the final lines of a paragraph. The acceptance test is preservation of content and actions.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 15, 2026.

Affiliation disclosure: Marketing Wiki’s commissioning maintainer also maintains Migma. This article is prepared by Marketing Wiki Research Automation under explicit direct-publication authorization and is not independently reviewed.

Migma documents client previews and compatibility checks, and its Visual Editor provides text and spacing controls for repairs. We recommend adding a focused enlargement review to that workflow because a screenshot at the default text size does not establish behavior at another setting.

Name the mechanism you tested#

Browser zoom, an inbox's text-size control and an operating system accessibility setting can affect content differently. Record the exact mechanism, client version and available message width. Do not label a browser zoom screenshot as a received-message accessibility test.

W3C's Understanding Resize Text explains the 200% resizing criterion without loss of content or functionality, with stated exceptions such as captions and images of text. It also discusses intermediate increments. This provides a useful review target; it does not certify an email or guarantee that a particular inbox exposes a compatible control.

If the client does not offer the mechanism you need, record that limitation. Test another supported route and explain what it establishes. A missing control is not evidence that the email passed.

Use a message with real constraints#

Choose the final campaign or a faithful private fixture. Include the longest action label, a multi-line headline, body copy and a condition that changes the reader's decision. A simple two-sentence test message will not expose the failures of a dense promotional layout.

For a fictional workshop invitation, the condition might be “Bring your own laptop.” Keep that requirement near the registration action. At larger text sizes, check that it remains complete and clearly related to the invitation.

Log loss, not visual difference#

Use this original functional-loss log:

Additional lines, taller sections and more scrolling can be acceptable. A condition that disappears inside a fixed-height box is not. A button that becomes two lines may be fine if its label and action remain usable; a cropped final word can change the meaning.

Record both passed and failed elements. Otherwise, a later repair can fix one block while breaking an element that was never captured in the baseline.

Repair constraints before shrinking text#

First inspect fixed heights and spacing that prevent content from growing. Allow a block to expand where the sending format permits it. Then simplify unnecessary wording or a crowded arrangement. Keep required conditions and accessible action names intact.

Do not solve the test by resetting the reader's preferred text size or making the baseline font smaller. That defeats the purpose. If a particular client imposes an unavoidable limitation, document its effect and choose the clearest supported fallback rather than claiming universal conformance.

Use Migma for the supported edits, then rerun Preflight. Test the final platform output as well, because wrappers and client transformations can change the available space. Retain the artifact revision with the result.

Separate enlargement from font substitution#

An unavailable brand font can change fit even at the same text size. Enlarged text can fail even when the intended font loads correctly. Keep those causes separate during diagnosis, then combine the worst relevant conditions in a final review if your supported client matrix warrants it.

The broader email accessibility guide explains why automated checks and visual compatibility are distinct. This article provides one narrow manual protocol; it does not replace screen-reader, language, contrast or link-purpose review.

No inbox, assistive technology or device was tested for this publication. Add one enlargement session to the next authorized campaign review and retain the mechanism, sizes, functional losses and repair evidence. That record is more useful than an unexplained “accessible” checkbox.