If your site runs on a website builder, most of the day-to-day accessibility work is within your reach and none of it requires a developer. It is a matter of habits applied when content goes in, plus a check every so often to catch what slipped.
This guide covers the parts you control, the free tools worth knowing, and an honest account of where a builder platform will stop you. It is written for people running their own sites, whoever built them. For what the standards ask and why, start with Understanding the Basics of ADA Web Accessibility Requirements.
The Habits That Matter Most
Write real alternative text for images. Alt text describes an image for people using screen readers and for anyone whose images fail to load. Describe what the image conveys in the context of the page, not what a filename would say. "Photo" tells a visitor nothing. "Service technician replacing a rooftop condenser unit" tells them what they are missing. Images that are purely decorative should carry empty alt text so a screen reader skips them rather than announcing a filename. WebAIM's guide is the clearest reference: webaim.org/techniques/alttext.
Keep heading levels in order. Headings are the structure screen reader users navigate by, the way a sighted visitor scans for bold text. One H1 per page for the page title, then H2 for major sections, then H3 beneath those. Most builders let you pick a heading level from a dropdown, and the common failure is choosing a level because it looks the right size rather than because it fits the outline. Set the level for structure and adjust the appearance separately. The W3C's tutorial covers this well: w3.org/WAI/tutorials/page-structure.
Check color contrast before committing to a palette. Text needs a contrast ratio of at least 4.5 to 1 against its background, or 3 to 1 for large text, meaning 18 point and above, or 14 point and above when bold. Light gray on white is the most common failure, and it usually arrives as a design preference nobody tested. WebAIM's contrast checker takes two color values and gives a verdict: webaim.org/resources/contrastchecker.
Make link text describe its destination. A screen reader user can pull up a list of every link on a page, stripped of surrounding text. A page full of "click here" and "read more" produces a list that says nothing. "Read more" becomes "read more about our maintenance plans." More at webaim.org/techniques/hypertext.
Test with the keyboard. Put the mouse aside and move through a page with the Tab key. Every link, button, form field, and menu item should be reachable in a sensible order, you should always be able to see where you are, and you should never get stuck somewhere you cannot Tab out of. This one test catches more real problems than any other five minutes you can spend, and it needs no tools: webaim.org/techniques/keyboard.
Check your captions on video. Automatic captions are a starting point, not a finished job. Review them for names, technical terms, and punctuation, all of which auto-captioning routinely mangles.
Scan the Site Periodically
Run WAVE, the free evaluation tool from WebAIM at Utah State University, over your main pages a few times a year and after any significant change: wave.webaim.org. It flags missing alt text, contrast failures, empty links, structural problems, and form fields without labels.
Two things to understand about any automated tool. It catches roughly a third of what matters, a figure the UK Government Digital Service puts at around 30 percent, because most accessibility failures require judgment a scanner cannot apply. A scanner can tell you an image has alt text, not whether the alt text is any good. And a clean scan is not a compliance certificate. There is no such certificate, from any tool or vendor.
The other habit worth building is scanning after content changes rather than on a calendar. Sites are rarely made inaccessible at launch. They drift, one uploaded PDF and one new page at a time.
Where a Builder Will Stop You
Some things are genuinely outside your control, and it is better to know which.
Platform components are the usual wall. If a template's navigation menu fails keyboard access, or a form's error messages are not announced to assistive technology, or a design block does not offer enough contrast control, those are often defects in code you cannot reach. How much you can reach varies by platform: Shopify exposes full theme code, Squarespace offers custom CSS on all plans and code injection on higher tiers, and Wix's accessibility wizard manages reading order but documents gaps, including elements it does not cover. Where the fix lives inside a component you cannot edit, your options are to choose a different component, work around it, or wait for the platform. Platform capabilities move quickly; the specifics here reflect the vendors' own documentation as of August 2026.
This is worth naming clearly because the legal standard makes no allowance for it. A visitor who cannot use your site is equally excluded whether the barrier came from your content or from your platform's template.
A Warning About Overlay Widgets
You will encounter products that promise compliance from a single line of code, usually presented as an accessibility button in the corner of the page. Treat these claims with skepticism.
In January 2025 the Federal Trade Commission brought a complaint against accessiBe, the overlay vendor it acted against, over its marketing claims. The final order, approved that April, requires the company to pay one million dollars and prohibits it from claiming its product makes websites conform to accessibility guidelines, or keeps them conforming, unless it has evidence to support those claims. The complaint described sites running the widget that still failed on menus, headings, tables, images, and recordings.
An overlay does not repair the underlying page. Spend the same money on alt text, contrast, and keyboard testing and you will be measurably further ahead.
Staying Current
Requirements do change. The Department of Justice maintains guidance on how the ADA applies to web content at ada.gov/resources/web-guidance, which is the most reliable plain-language starting point. The Web Content Accessibility Guidelines themselves are published by the W3C at w3.org/WAI/standards-guidelines/wcag.
If You Would Rather Not Own This
Everything above is genuinely doable, and plenty of businesses handle it well. If you would rather it not be your job, a site audit establishes where your site actually stands, on any platform, and gives you a prioritized list rather than a scan dump. Sites we manage are tested at build and rechecked on every change, which is described on our management page.
Either way, the habits at the top of this page are worth adopting today. They cost nothing and they remove the barriers that matter most.
Notice: provided for informational purposes only; not legal, financial, or professional advice.
Notice: The information provided in this document is for informational purposes only and does not constitute legal, financial, or professional advice. All materials and guidance offered by Generose Corporation dba Risingline are subject to its Client Services Agreement and are provided without warranty as to accuracy, completeness, or applicability to any specific situation. While Risingline takes reasonable precautions to ensure the reliability of the information presented, compliance with regulatory requirements varies based on specific circumstances, jurisdiction, and evolving standards. Recipients are encouraged to conduct independent due diligence and consult with qualified professionals before implementing any recommendations. Generose Corporation dba Risingline expressly disclaims any liability for actions taken or not taken based on this document. Receipt of this information does not establish a client, advisory, or fiduciary relationship between Risingline and the recipient.