Accessibility Checks to Run Before You Publish a Builder Page

A builder page ships with a form, a hero, a gallery, and a contact block, and the person who assembled it usually tests it on a fast connection, in one browser, with a mouse, while sitting upright. That test tells almost nothing. The page will be opened on a cracked phone in a truck cab, by someone using a screen reader, by a person who cannot separate red from green, and by a person who tabs through the whole thing because a trackpad is a mystery. Accessibility checks are the part of publishing that catches those visitors before they bounce.

What follows is a practical pre-publish pass for builder-made pages specifically. Page builders introduce their own failure patterns: nested divs that look fine and read terribly, icon fonts with no text alternative, sliders that trap focus, and form plugins that style a label into invisibility. The checks below target those patterns directly.

Keyboard-Only Walkthrough of the Entire Page

Put the mouse away. Press Tab from the top of the page and keep pressing until focus returns to the browser chrome. Every interactive element should receive a visible focus ring in a logical order: header links, hero button, gallery controls, form fields, submit, footer links. If focus disappears at any point, something on the page is either unreachable or invisible when focused.

Builder themes are notorious for the second problem. A stylesheet resets outline to none for aesthetics, and the focus state never gets rebuilt. The element still works, but a keyboard user has no idea where they are. The fix is a single CSS rule that restores a visible outline on :focus-visible, and it belongs in the theme's custom CSS panel, not buried in a plugin.

The first problem, unreachable elements, shows up most in sliders and lightboxes. If the gallery advances only by clicking an arrow that cannot be tabbed to, the images are decorative for anyone without a mouse. Check whether the slider exposes previous and next as real buttons. Check whether Escape closes a lightbox. Check whether focus returns to the thumbnail that opened it. These are small behaviors that builders often forget to wire up.

Reading Order Against the Visual Order

Builders let a column get dragged to the left of another column without changing the underlying markup order. Visually the page reads one way; the screen reader announces it another. A hero image might be announced after the paragraph it illustrates, or a sidebar promo might interrupt a sentence in the main copy.

The check is crude and effective: disable CSS in the browser, or use a reader mode, and read the page top to bottom. The text should still make sense. If a caption appears before the thing it captions, or a callout lands mid-thought, the visual order and the DOM order have diverged. Rebuild the section rather than papering over it with absolute positioning.

Heading Levels That Match the Outline

Builder pages accumulate headings the way a garage accumulates boxes. A section title gets set to H2 because it looks right, a subtitle to H4 because H2 was too big, and the page ends up with an outline that skips levels and repeats itself. Screen reader users navigate by heading list, and a broken outline turns that list into noise.

The rule is simple: one H1 for the page, H2 for major sections, H3 for subsections, no skipping. Style can be handled separately with CSS classes if the default sizes are wrong. A heading is a structural marker first and a typographic choice second, and builders blur that distinction constantly.

Alt Text on Every Image That Carries Meaning

A gallery image of a finished product needs a description of what is shown. A decorative divider does not. The distinction matters because a screen reader either reads nothing (decorative, alt="") or reads a description (informative). Builders tend to leave the alt field blank across the board, which is fine for ornament and a real loss for content.

Two failure modes recur. The first is the filename dumped into the alt field: "IMG_2043.jpg" announces as letters and numbers. The second is keyword stuffing, where the alt text reads like a search query rather than a description. Alt text serves a person who cannot see the image, and it should describe what the image shows in plain language, in roughly the length of a tweet.

Form Labels Wired to Their Inputs

Contact forms on builder pages are frequently the worst offenders. A placeholder sits inside the field, the label above it is a styled paragraph, and the two are not connected in the markup. A sighted user sees "Email" above a box. A screen reader user hears "edit text" and nothing else.

Open the form in the browser inspector and confirm that every input has a label element with a for attribute matching the input's id. Placeholders are not labels; they vanish the moment typing begins. If a builder's form plugin will not output proper labels, replace the form or rebuild it by hand. No amount of styling rescues a form that a screen reader cannot parse.

Error messages deserve the same scrutiny. When a required field is left blank and the form rejects, the error text should be announced, not just colored red. A message that appears visually but never reaches the accessibility tree is a dead end for anyone who cannot see it.

Color Contrast Measured, Not Eyeballed

Designers judge contrast on a good monitor in good light. Visitors judge it on a phone at noon. The ratios that matter are 4.5:1 for normal text and 3:1 for large text and interactive elements, and those figures are checkable with a browser extension or a contrast tool in seconds.

The usual casualties are light gray body text on white, white text on a pastel button, and ghosted placeholder text inside form fields. Each of these looks refined in a mockup and disappears in daylight. Run the check on the actual rendered page, not the design file, because builder themes often override the intended colors with their own defaults.

Meaning That Survives Without Color

Color is a fine way to distinguish a required field, a status badge, or a chart series, as long as it is not the only way. A red asterisk next to "Email" works for most people and fails for anyone with red-green color blindness. The asterisk itself carries the meaning; the red is decoration. Pair it with a word.

Charts and status indicators are harder. If a green dot means "live" and a gray dot means "draft," add a text label or a shape difference. If a graph distinguishes two lines by hue alone, add a dashed stroke or a direct label. The check is to view the page through a grayscale filter and confirm nothing important is lost.

Motion That Can Be Stopped

Builder pages love a parallax hero, an autoplaying background video, and a carousel that advances every five seconds. Some people find that motion uncomfortable or disorienting, and some need it to stop in order to read. Any animation that runs longer than five seconds needs a visible pause control, and a rotating carousel should stop when hovered or focused.

The page should also respect the operating system's reduced-motion preference. That is a single CSS media query, and it is the difference between a page that accommodates a visitor and one that makes a visitor leave. Builders rarely expose this setting in their UI, so it usually goes in custom CSS.

A Screen Reader Pass on the Finished Page

No substitute exists for listening to the page. VoiceOver on macOS, NVDA on Windows, or TalkBack on Android will read the page in the order a screen reader user hears it, announce form fields and buttons, and expose whether images have descriptions. Ten minutes with any of these tools surfaces problems that a checklist cannot.

The most common discovery is unlabeled buttons. An icon-only close button on a modal announces as "button" with no clue what it does. A hamburger menu announces the same. Adding an aria-label of "Close" or "Open menu" is a one-line fix, and it is exactly the kind of detail a builder's default components omit.

Zoom to 200 Percent and Read the Page

Set the browser zoom to 200 percent and scroll through. Text should reflow, not clip. Buttons should not overlap. Nothing should require horizontal scrolling except a genuinely wide table. Builders often lock widths in pixels, and those widths break the moment zoom kicks in.

The same check applies at 320 pixels wide, which approximates a small phone in portrait. If a hero heading runs off the edge, if a gallery grid collapses into a single column that overflows, if a sticky header eats half the screen, the page needs responsive work before it ships. A person reading on a bus does not have the luxury of resizing a window.

Timed Elements and Session Limits

Any part of the page that expires on a timer creates a barrier. A form that resets after ten minutes, a modal that closes itself, a promo that disappears, a session that logs out mid-application: each of these punishes a slow reader, a person using assistive technology, or someone who stepped away. Where a timer is unavoidable, extend it on request and warn before it fires.

Builder pages rarely intend to include timers, but plugins add them quietly. A countdown widget for a sale, an auto-advancing hero slider, a chatbot that collapses on a schedule. Audit the page for anything that moves or disappears without a click, and either remove it or give it a stop.

The last thing to do before pressing publish is to open the page on a phone, with the sound off, with the screen dimmed, and navigate it using only a thumb and a screen reader. If the page holds up under that, it will hold up for the person who arrives at it at the end of a long day, on a device that is not the one it was built on, looking for one specific thing. That visitor is the one the checks are for.