A polished template can still produce a page that’s hard to use. A visitor may see a clear “Book an appointment” button, while a keyboard user can’t reach it. A form may look tidy until its placeholder text disappears and no label remains to say what belongs in the field.
You can fix many of these problems in a website builder without touching code. The work happens in the page editor, design settings, form builder, and—most importantly—the published site. Use this checklist on a real page, not just a template preview. If a setting isn’t available, record the problem rather than assuming the builder has handled it for you.
Give every page a structure people can follow
- Set a descriptive page title in the builder’s page or SEO settings.
- Use actual heading styles, in a logical order.
- Use the builder’s list and table tools where the content calls for them.
- Write links that say where they go.
A page title is the text browsers show on a tab. “Services | Oak Street Dental” distinguishes a page better than “Untitled” or “Home.” It’s separate from the large heading visible on the page, and both help visitors identify where they are.
For visible content, choose the builder’s heading controls—not a large font size applied to ordinary text. Give the page a clear main heading, then use the next heading level for major sections and a lower level for subsections. A section called “Fees” might contain subsections called “Consultations” and “Follow-up visits.” Don’t pick a heading level because its default styling looks nicer; adjust its appearance in the theme settings if you can. Heading levels communicate the page’s organization to assistive technology, and skipping levels can make that organization confusing.
The same distinction applies to lists and tables. Three lines beginning with typed hyphens may look like a list but lack list structure; use the editor’s bulleted or numbered list control. Reserve tables for data that needs rows and columns, such as a schedule. If the table tool lets you designate header cells, do so. Don’t use a table simply to position text beside an image.
Link wording should make sense when someone scans a page quickly or hears links read aloud. “View appointment options” is more useful than “Click here.” If several cards each have a “Learn more” link, make sure the card title is included in the link or that each link identifies its destination.
Describe images for their purpose, not their appearance alone
- Add useful alternative text to images that convey information.
- Mark purely decorative images as decorative where the builder allows it.
- Explain important charts or text shown only in an image elsewhere on the page.
Ask what a visitor would miss if the image weren’t visible. For a photo introducing a staff member, “Dr. Maya Chen, pediatric dentist” may do more work than “Woman smiling in an office.” For a button made only of a magnifying-glass icon, the accessible name should convey “Search,” not describe the icon. A chart needs its main finding or data in nearby text; a short image description alone may not carry enough detail.
Not every picture needs a spoken description. A background flourish or an image that repeats nearby text can be marked decorative. That is different from leaving the alternative-text field unfinished: W3C’s image guidance distinguishes informative, functional, and decorative images because each needs different treatment.
Check the published page after editing. Some builders use separate image settings for a gallery, a linked image, and a mobile version. If the image itself is the only link to a destination, its accessible name must make that destination clear.
Make the design readable without relying on color alone
- Check text contrast against its actual background.
- Make links, errors, and status messages identifiable without color alone.
- Test the page at increased browser zoom and on a narrow screen.
Pale gray text can disappear against white even when it looks elegant on a designer’s monitor. For WCAG Level AA, ordinary text needs a contrast ratio of at least 4.5:1; large text generally needs at least 3:1. A contrast checker can measure a color pair, but check the colors as they appear on the published page—especially text placed over photos or gradients.
Don’t make “required fields are red” the only instruction on a form. Add the word “Required.” Likewise, a chart with red and green lines needs labels or another way to tell the lines apart. Color alone should not carry information that a visitor needs to act on.
Increase browser zoom to 200%, then try a phone-sized view. Look for clipped text, overlapping cards, menus that obscure content, and buttons that move out of reach. Rearranging a layout, shortening an overly long label, or choosing a simpler template section may fix a problem without custom code. Don’t solve it by making the text smaller.
Test every important action without a mouse
- Use Tab and Shift+Tab to move through the published page.
- Confirm you can see which link, button, or field has focus.
- Open and close menus, accordions, pop-ups, and forms using the keyboard.
- Check the mobile menu separately.
Start at the browser’s address bar, move into the page, and follow the focus indicator. The order should make sense. Press Enter on links and buttons; use Space where a control calls for it. Try to complete the page’s main task: send an inquiry, book a service, or reach a product page.
Watch for a card that responds only to hovering, a pop-up you can open but not close, or focus that disappears behind a sticky header. These aren’t copy edits. First check the builder’s component and theme options; if they don’t resolve the problem, replace the component or ask the provider for a fix. A keyboard user needs a visible indication of which control has focus, not merely a way to tab through the page.
A desktop menu working well says little about its collapsed mobile version. Open that version with the keyboard too, and check that its items appear in a sensible order and that you can leave the menu.
Give forms labels and useful feedback
- Put a clear, persistent label on each field.
- Identify required fields and explain unusual formats before submission.
- Submit the form with missing or incorrect information and inspect the errors.
- Check the confirmation message after a successful submission.
A placeholder such as “Email address” inside an empty box is a poor substitute for a label: it can vanish as soon as someone types. In the form builder, look for a field-label setting and leave the label visible where practical. Check every control, including checkboxes, dropdowns, search fields, and newsletter sign-ups. Labels need to identify form controls and be associated with them, so nearby text that only looks like a label may not be enough.
If a date must follow a particular format, say so beside the field. If a field is required, communicate that in words rather than with an unexplained asterisk. Then make a deliberate mistake. An error should identify the field and explain how to fix it—“Enter an email address in the format name@example.com” is more helpful than a red border alone. Test whether keyboard focus can reach the error and the field that needs attention.
Embedded booking, payment, and mailing-list forms deserve the same test as the builder’s native forms. If an embedded tool fails, you may need its vendor to fix it or a different form—not another instruction placed above an unusable field.
Check media and downloaded content
- Review captions on videos and provide a transcript where useful.
- Make important visual information in a video available to people who cannot see it.
- Check documents visitors must download to complete a task.
If the builder lets you upload or link a caption file, use it and play the video to check timing, names, and meaningful sounds. Automatically generated captions can be a starting point, but they need review. Captions convey speech and relevant non-speech audio to people who cannot hear the track.
A captioned video can still leave out someone who cannot see an on-screen price, diagram, or instruction. Include essential visual information in the spoken narration, a suitable description, or an accompanying text alternative. And if the page’s main instructions sit inside a PDF, check that document too; an accessible web page doesn’t repair an inaccessible download.
Publish, retest, and know when the builder is the obstacle
A useful final pass takes one representative page from each type of content: the home page, an article, a product or service page, and a page with a form. Run the builder’s accessibility checker if it has one, then do the keyboard, zoom, image, and form checks yourself. Automated tools cannot assess every accessibility issue; they assist human review rather than replace it.
Keep a short record of what you found, which page it affects, and whether the fix belongs in your content, the template, or a third-party component. Fix a broken form or unreachable primary button before polishing minor wording. Repeat the check when you change a shared template or add a new type of page.
The practical limit of a no-code checklist is the builder itself. You can improve headings, labels, descriptions, and color choices, but you may not be able to repair the keyboard behavior or markup of a component the platform generates. When that happens, choose a better component, raise the issue with its provider, or get specialist help. The goal isn’t to tick every box in the editor. It’s to make sure people can use the site you actually publish.