A page can look polished in a website builder and still be impossible to use without a mouse. A menu opens on hover but not from the keyboard. A form shows an error in red but never explains it. A screen reader reaches a row of buttons and announces each one simply as “button.”
Audit the published site instead, including its mobile menu, forms, pop-ups, and any features added through third-party widgets. The checklist below is a practical first pass for a site owner or editor. Use WCAG 2.2 Level AA as a reference point, but don’t mistake a short checklist—or a builder’s accessibility score—for proof that every page meets it.
Start with pages people need to use
You don’t have to inspect every page before finding useful work to do. Start with one page of each type: the homepage, a content page, a contact or signup form, and, if relevant, a product or booking page. Test an entire task, not just a screen. Someone needs to be able to find a service, open its details, complete the form, and understand what happened after submitting it.
Include the parts your builder adds across the site, such as the header, footer, cookie notice, and mobile navigation. A fault in a shared template can affect dozens of pages. Record where each issue appears, what you tried, and whether you can fix it in the editor, in a site-wide setting, or only through a third-party provider.
Put the mouse aside
Open a published page and use Tab to move forward, Shift + Tab to move back, and Enter or Space to activate controls. Use arrow keys where a control calls for them. On a Mac, check that keyboard navigation to controls is enabled before treating a skipped control as a site failure.
As you move through the page, ask:
- Can you reach every link, button, form field, and media control?
- Does a visible outline or other clear indicator show where you are?
- Does the focus order make sense, even if the builder has rearranged elements visually?
- Can you open and close menus, dialogs, accordions, and other interactive elements without a mouse?
- Can you leave every component, or does focus get trapped?
- Does a sticky header, pop-up, or cookie banner cover the focused control?
These checks follow the W3C’s keyboard access and visible-focus guidance. Pay special attention to “Read more” cards and entire sections made clickable through a builder interaction. If they only respond to a mouse click or hover, replace them with real links or buttons where the builder allows it. A clickable-looking box is not necessarily a keyboard-accessible control.
Check the first few Tab presses, too. On pages with a long header, a working “Skip to main content” link lets keyboard users bypass repeated navigation. If your builder supplies one, make sure it appears when focused and lands at the main content. If it doesn’t, look for a template setting or another supported way to add it.
Fix blocked tasks before cosmetic issues. A faint focus outline needs work; a booking button that can’t be reached by keyboard prevents the booking altogether.
Check what a screen reader can understand
Screen readers use the page’s structure and control names, not its visual styling, to help people find their way around. A large, bold text block might look like a heading while remaining ordinary text to assistive technology.
Inspect the heading settings on each page. Give the page a clear main heading, then use lower-level headings for sections and subsections. Choose heading levels for their structure, not because one size happens to look better; adjust appearance in the design settings instead. The W3C’s heading guidance explains why a logical outline helps people scan and move through content.
Check the other structural elements your builder produces. The site’s navigation, main content, and footer should be recognizable as page regions rather than an undifferentiated set of containers. When a builder offers a semantic element setting, choose the element that matches the content’s purpose. Page regions give assistive technology users another way to move past repeated material.
Then listen to a few pages with a screen reader, such as VoiceOver on a Mac or NVDA on Windows. Try the heading and link lists, not only the read-from-top command. Ask yourself whether you could identify the page and complete its main task from what you hear:
- Is the browser tab title specific to the page?
- Do headings make sense out of visual context?
- Do links say where they go? Several links all called “Learn more” offer little help in a link list.
- Does each icon-only button have a useful name, such as “Open menu” or “Search”?
- When a menu opens or a form succeeds, is the change understandable without seeing the screen?
For custom widgets, a label alone isn’t enough. The control must also expose what it is and, where relevant, its changing state. Use the builder’s accessible components when they work; avoid trying to repair a broken interaction by adding a label while leaving its keyboard behavior untouched.
Measure contrast, then test the layout at larger sizes
A color palette can pass a quick visual glance and fail where it matters most: small navigation labels, text over photographs, pale form borders, and error messages. Check the actual foreground and background colors with a contrast tool rather than guessing.
For WCAG Level AA, the usual minimum is 4.5:1 for ordinary text and 3:1 for large text. Relevant non-text elements, such as the visible boundary needed to identify an input, generally need 3:1 against adjacent colors. Those figures come with specific exceptions, so use them as test thresholds, not a reason to put all pale text in a larger font. A solid background behind text is often a more reliable fix than trying to find one text color that works across a busy photo.
Color must not carry a message by itself. If the only sign of a form error is a red border, add an error message in words. If an active navigation item is distinguished only by color, give it another visible cue.
Finally, enlarge the page. At 200% text size and again at a narrow viewport or high browser zoom, check whether navigation remains available, text is cut off, and buttons overlap. A layout that collapses neatly on a phone can still break when someone enlarges text on a desktop. This is particularly worth checking on builder sites with fixed-height sections or text layered over images.
Give each image a job—and an appropriate description
Don’t fill every image’s alt-text field with a description. Decide what the image contributes to this particular page.
If a photograph carries information, write a short description of that information. On a staff page, “Maria Chen, customer support manager” may be useful; on a page where her name and role sit immediately beside the photo, repeating both may add little. If an image acts as a link or button, its text alternative should explain the action or destination—not merely say what the icon looks like. The W3C’s image guidance distinguishes informative, functional, and decorative images.
Pure decoration should generally be marked decorative or have empty alt text, depending on the builder’s options. That keeps it from adding noise to screen-reader output. Don’t confuse an empty alt attribute with a missing one: decorative-image guidance notes that a missing attribute can lead some screen readers to announce the file name.
Look carefully at charts, infographics, and images containing text. A short alt description may identify a chart, but it may not convey the figures someone needs. Put the essential data or message in nearby page text when that’s the clearest way to make it available. For social graphics used as website content, move important wording into real text rather than leaving it locked inside an image.
Submit every form with mistakes on purpose
A form isn’t accessible merely because its fields can be reached with Tab. Test it once with empty required fields, once with invalid information, and once with a valid submission. If you run a store, include checkout or account creation; those flows may use components supplied by a different service.
Each field needs a persistent, descriptive label. Placeholder text such as “you@example.com” can illustrate a format, but it disappears as people type and doesn’t replace a label. Check that the visible label is actually associated with the field, so a screen reader announces it and clicking the label activates the right control. The same principle applies to checkboxes, radio buttons, and dropdowns, as the W3C’s form-label guidance shows.
Mark required fields in words, and put format instructions where people can find them before submitting. For a date field, for example, say which format you accept rather than waiting for an error. When submission fails, identify the affected field and explain how to correct it. “Email address: enter an address in the format name@example.com” is useful; “Invalid input” is not. After success, provide a confirmation people can perceive without relying on a color change or a brief visual toast. The W3C recommends clear feedback for both errors and successful submissions.
Builder forms deserve a second look after you connect an email service, payment tool, CAPTCHA, or custom validation script. Test the finished flow on the published site. If a third-party component blocks completion and you can’t repair it, ask the provider for a fix or choose a different component.
Treat automated results as a starting point
Run an accessibility checker to catch issues such as missing text alternatives, unnamed controls, and some contrast failures. Then repeat the keyboard, screen-reader, zoom, and form tests yourself. Automated tools cannot judge every accessibility issue: a tool might find that an image has alt text without knowing whether that text explains the image.
Keep a short issue log and tackle it in this order: barriers that prevent a task, problems in shared components, confusing content or feedback, then remaining page-level issues. Retest after a fix, especially if you changed a template or replaced a widget. A useful audit ends not with a score, but with someone able to reach, understand, and complete what they came to the site to do.