Make every builder page usable without guesswork

An accessible builder website lets a buyer compare plans, open a gallery, read the specs and submit a lot inquiry by keyboard, by screen reader and on a phone. That takes real headings, labeled form fields, image descriptions that name the plan or room, captions on video and documents with selectable text. Test the tasks, not the checklist.

Where do builder websites create access barriers?

Builder sites lean on pictures. Floor plans, elevations, finish photos, progress video, map embeds and PDF downloads carry facts that never reach a person who cannot see them or operate them the expected way. Write down the task each barrier blocks before you assign a fix.

A gallery hides its arrows until a pointer hovers. A plan name lives only inside an image. A form uses placeholder text instead of labels. The warranty document is a scan with no readable text. A walkthrough video depends on the narrator and has no captions.

Review the pages tied to real decisions

Each page type in the builder websites articles belongs in this review.

How should plans, elevations and project photos be described?

Image text states what the image is for in context. A decorative texture needs nothing. A floor-plan image needs the plan name, the level and a sentence on the layout. A project photo needs enough to identify the room or the construction decision it shows.

No keyword lists, no “beautiful home.” If a photo supports a paragraph about a screened porch off the rear living area, describe that relationship. If an elevation shows an optional stone package, say so in visible text as well as the image description.

Keep important facts outside the image

Plan status, project status, standard-versus-optional labels and inquiry instructions belong in page text. Do not leave an essential distinction only in a rendering, a badge or a caption burned into a photo. Page text also travels better when the same asset shows up on a plan page, a community page and an event page.

The plan library page article explains how plans should be grouped and labeled before accessibility details are applied.

What should keyboard and screen-reader testing cover?

A person should be able to reach every interactive control without a mouse. The focus order should follow the visual reading order. Focus needs a visible indicator. Menus, filters, accordions, galleries, video controls and dialogs should announce their purpose and state in a useful way.

1. Begin at the page address. Move through the header, main content and footer using the keyboard.
2. Open and close navigation. Confirm focus enters the menu, reaches each item and returns sensibly.
3. Use plan filters. Change a selection, understand the result and clear the filter.
4. Operate a gallery. Open a larger image, move between items, read its description and close it.
5. Complete a form. Trigger an error, locate the message, correct the field and receive confirmation.
6. Inspect headings and landmarks. Confirm the page structure reflects the visible subject hierarchy.

Run an automated check first to catch repeated problems, then test by hand. A tool finds a missing label. It cannot tell you whether “photo” describes the framing detail the paragraph beside it discusses.

How should forms, documents and video be handled?

Forms need labels that stay visible, plain instructions, error messages that name the field and a confirmation that does not rely on color alone. Group related questions, such as lot ownership and parcel number, under a short explanation. Mark required fields before the buyer submits.

Documents need selectable text, a sensible reading order and link text that says what opens. When buyers keep asking the same question about the warranty, the specs or the allowance schedule, publish the answer as a web page too. A download should not be the only route to a basic answer.

The warranty and aftercare page guide shows how to keep service instructions available as web content instead of relying on a document alone.

Give video more than one way to communicate

Add accurate captions and review them for plan names, material terms and job-site language. Provide a transcript or surrounding explanation when the video carries substantial process information. Do not use color or camera movement as the only way to identify what changed.

Accessibility should also shape performance and phone testing. See the builder website on phones article for touch, form and layout checks.

How does accessibility stay part of publishing?

Make accessibility part of done for every page type. A new project page ships with reviewed image descriptions, heading order and working gallery controls. A changed form gets label, error and confirmation tests. A new video gets captions before it goes live. A revised document gets a reading-order check.

Keep a short issue list: page, task, barrier, owner, result. Fix first whatever blocks a buyer from reading project status, comparing a plan, submitting a lot or requesting warranty service.

Use agents for coverage and people for judgment

Our agents scan heading order, missing attributes, contrast, form markup and document inventories. People judge meaning, work the controls, read the descriptions and approve each fix. Accessibility is built into the Owned website stage, not bolted on after launch.

Check current technical guidance with the World Wide Web Consortium and legal obligations with counsel. Record which guidance you used, who reviewed it and which task failures remain open.