Accessibility.

Every week, a small business somewhere in America receives a demand letter. The subject: their website is inaccessible to users with disabilities, and they are in violation of the Americans with Disabilities Act. The business owner had no idea. Neither did their web designer. The letter asks for remediation — and usually a settlement — within 30 days.

Web accessibility is the most consistently misunderstood part of building a website for a Tucson business. It's treated as optional ("we'll add that later"), or confused with a free overlay plugin ("just install AccessiBe"), or dismissed as relevant only to enterprises. None of that is true. This guide covers the 28 questions we get asked most often — about what compliance actually requires, what it costs, and how to build a site that doesn't expose you to legal risk from day one.

01What web accessibility actually means.

1.1What is web accessibility and who is it for?

Web accessibility means building websites that people with disabilities can use. That includes people who are blind or have low vision (and use screen readers), people who are deaf or hard of hearing, people with motor impairments who can't use a mouse (and navigate by keyboard), and people with cognitive disabilities who need clearer language and layout structure. The Web Content Accessibility Guidelines (WCAG) are the international standard that defines what "accessible" means in practice.

In the U.S., the ADA's Title III — which covers "places of public accommodation" — has been consistently interpreted by federal courts to include websites. The Department of Justice has formally adopted WCAG 2.1 AA as the standard. If your website isn't meeting that bar, you're in the same position as a restaurant without a ramp: technically out of compliance, and vulnerable to a demand letter.

1.2What is WCAG and what do the different levels mean?

WCAG stands for Web Content Accessibility Guidelines. It's published by the W3C (the international standards body for the web) and comes in three compliance levels: A (minimum), AA (mid-level, legally required), and AAA (ideal but impractical to achieve fully). When courts and the DOJ reference accessibility compliance, they mean WCAG 2.1 AA. Level A covers the most basic requirements — like every image having alt text. Level AA adds requirements for color contrast, keyboard navigation, error identification in forms, and more. AAA is for things like sign language interpretation and live captions for audio.

1.3How many people does this actually affect?

About 26% of U.S. adults live with some form of disability, according to the CDC. That includes 7 million people who are blind or visually impaired, 30 million who have significant hearing loss, and tens of millions more who deal with motor or cognitive conditions. The Web Accessibility Initiative estimates that 1 in 5 people globally would benefit directly from accessible web design. This is not a niche audience. It's roughly the same share of the U.S. population as smartphone users over 65.

1.4Doesn't my accessibility overlay plugin handle this?

No. Overlay tools like AccessiBe, UserWay, and AudioEye work by injecting JavaScript into your page that tries to "fix" accessibility issues on-the-fly. The problem is that they can't fix structural issues in the HTML — they can't repair a form that's missing labels, correct reading order that the screen reader sees differently from the visual order, or add missing keyboard navigation paths. Multiple independent audits from accessibility researchers have shown that overlays fail to remediate 70–80% of WCAG violations. They also introduce new bugs for some screen reader users. Several major lawsuits have proceeded against sites actively running overlay tools. They are not a legal shield.

1.5Is accessibility different from responsive design or mobile optimization?

Yes — they overlap but aren't the same. Responsive design means your site adjusts to different screen sizes. Mobile optimization means your site loads fast and is easy to use on a phone. Accessibility means your site works for users with disabilities, regardless of device. Some WCAG requirements are relevant to mobile (tap target sizes, for example), but most aren't about screen size at all — they're about screen reader compatibility, keyboard navigation, color contrast, and content structure. You can have a perfectly responsive site that is entirely inaccessible.

02The legal exposure — ADA, Title III, and Tucson.

2.1Are Tucson businesses actually getting sued over website accessibility?

Yes. Web accessibility lawsuits have been filed in every state in the country, and Arizona is not exempt. The filings are concentrated in federal courts with high lawsuit volumes (Florida, New York, California) but demand letters — the precursor to lawsuits — are sent nationwide, including to businesses in smaller markets like Tucson. The volume of demand letters sent to small and mid-size businesses has increased every year since 2018. Service businesses — medical spas, dental practices, law firms, home services companies — are among the most common targets because their websites often have obvious violations like unlabeled contact forms.

2.2What's the actual legal basis? My business isn't a building.

Title III of the ADA prohibits discrimination by "places of public accommodation" — originally written with physical spaces in mind. The DOJ and federal courts have extended this to websites on the theory that a website is the digital version of a business's front door. The Ninth Circuit (which covers Arizona) has been receptive to this interpretation. In 2022, the Supreme Court declined to hear a challenge to this reading of the ADA, effectively confirming that website accessibility claims have standing in federal courts. The DOJ's March 2022 guidance explicitly named WCAG 2.1 AA as the compliance standard.

2.3What does a typical demand letter ask for?

Most demand letters are sent by a small number of law firms that have developed a high-volume practice around ADA website claims. The letter typically identifies 3–8 specific WCAG violations found on your site (often caught by automated scanning tools), asserts that these violations prevented their client (a disabled user) from accessing your services, and demands either a settlement payment (often $5,000–$25,000) or remediation plus a monitoring agreement. The fastest way to resolve these is to have an accessible site in the first place. The second-fastest is to have documented evidence of a good-faith compliance program and a timeline for remediation.

2.4Which industries are most exposed in Tucson?

Healthcare-adjacent businesses — medical spas, dental offices, urgent care clinics, and physical therapy practices — are among the highest-risk categories because their services are directly relevant to disabled individuals and the stakes of inaccessibility are higher. Legal services are also high-risk for the same reason. Home services companies (HVAC, plumbing, electricians) face lower headline risk but have consistently poor website accessibility scores, making them easy targets for automated scanning-based demand letters. Any business that takes online appointments, online payments, or online contact form submissions is a plausible target.

2.5Does having a privacy policy or terms of service protect me?

No. A privacy policy or terms of service does nothing for ADA compliance. They address different legal areas entirely. The only protection against web accessibility litigation is actually building an accessible website and maintaining it — or, failing that, having documented evidence of an active, good-faith compliance program with a real remediation timeline. Policies can't substitute for technical compliance.

03The WCAG 2.1 AA standard — what it requires.

3.1What are the four principles of WCAG?

WCAG 2.1 is organized under four principles — the acronym is POUR:

• Perceivable — users can see or hear the content (alt text for images, captions for video, sufficient color contrast)
• Operable — users can navigate and interact using any input method (keyboard navigation, no content that flashes more than 3 times per second, enough time to complete forms)
• Understandable — content and interface behavior are predictable (clear error messages, consistent navigation, reading level)
• Robust — content can be reliably interpreted by assistive technologies (clean, valid HTML with ARIA attributes where needed)

The Level AA requirements under each of these four principles are the practical compliance target for a Tucson business website.

3.2What are the most commonly violated WCAG requirements on small business sites?

Based on WebAIM's annual review of one million websites, the six most common WCAG failures — found on over 80% of the tested sites — are: low-contrast text, missing alt text on images, missing form input labels, empty links (links with no descriptive text), missing document language declaration, and empty buttons. Five of those six are things a developer fixes in the markup. None require significant design changes. They're just — frequently not done.

3.3What does "keyboard accessible" mean and why does it matter?

Every interactive element on a page — every link, every button, every form field, every dropdown, every modal — must be reachable and operable using only a keyboard. The Tab key should move focus through all interactive elements in a logical order. Enter or Space should activate buttons and links. Escape should close modals and menus. Focus — the highlighted state that shows which element is currently selected — should always be visible. This matters because users with motor impairments who can't use a mouse, users who are blind and navigating by screen reader, and power users who prefer keyboard navigation all depend on it. A site that hides or removes focus indicators (a common design "cleanup" decision) is immediately non-compliant.

3.4What's the minimum color contrast ratio and why is it hard to meet with certain palettes?

WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). The contrast ratio measures the luminance difference between text color and its background. Common failures: light gray text on white backgrounds, white text on medium-color backgrounds (including some greens and blues that seem dark but don't hit the threshold), and text overlaid on images. The right tool for checking contrast during design is the WebAIM Contrast Checker. Any design that passes contrast in mockup tools should be re-checked against the actual rendered colors in the browser, where anti-aliasing and rendering differences can affect perceived contrast.

3.5What is ARIA and when should it be used?

ARIA stands for Accessible Rich Internet Applications — a set of HTML attributes that add semantic meaning to elements that don't natively communicate their role or state to assistive technologies. Examples: aria-label to give a name to an icon button that has no visible text; aria-expanded to signal whether a menu is open or closed; role="alert" to announce dynamic form error messages to screen readers. The important caveat: ARIA should be used to supplement native HTML semantics, not replace them. A common anti-pattern is using role="button" on a <div> instead of just using a <button>. Use semantic HTML first; reach for ARIA when HTML alone isn't sufficient.

04How accessibility affects SEO and conversion.

4.1Does accessibility actually improve Google rankings?

Directly, partially. Google's crawlers are essentially an advanced screen reader — they parse your HTML structure, follow your heading hierarchy, read your alt text and link text, and interpret your semantic markup. A site with correct heading structure, descriptive link text, and meaningful alt text gives Google more signal about what each page is about. Sites with strong accessibility tend to score better on Core Web Vitals because semantic HTML is leaner and faster to parse than div-soup. The correlation between high accessibility scores and strong organic rankings is consistent in our audits — not because Google rewards accessibility points, but because the same practices that make a site accessible also make it crawlable.

4.2How does accessibility affect conversion rate?

It removes friction. Clear form labels reduce form abandonment. Descriptive button text removes ambiguity. Logical reading order helps users scan quickly and find the action they're looking for. Sufficient contrast makes text readable in bright Arizona sunlight on a mobile screen. These aren't accessibility-only benefits — they improve the experience for everyone. The concept is called the "curb-cut effect": design that helps disabled users almost always helps non-disabled users too, and often in ways that are hard to see until you look at the data.

4.3Do screen reader users convert differently?

When a site is accessible, screen reader users convert at roughly the same rate as sighted users for the same types of transactions. When a site is inaccessible, screen reader users frequently can't complete the conversion at all — forms are unlabeled and unnavigable, or the checkout flow depends on visual-only affordances. The practical implication for a Tucson business: if your website is inaccessible, you are literally preventing a segment of potential customers from giving you money. That segment is not small.

4.4What's the relationship between accessibility and Core Web Vitals?

Accessibility improvements rarely hurt Core Web Vitals, and they often help. Clean semantic HTML is lighter and faster to parse. Removing accessibility-overlay JavaScript (which can add 100–400ms to page load time) improves performance. Proper image alt text has no performance cost. The places where they can conflict: adding ARIA attributes to highly dynamic JavaScript-driven components can add complexity and sometimes introduce layout shift (CLS) if not handled carefully. The resolution is to build with semantic HTML from the start, so you're not patching accessibility into a page-builder-generated structure after the fact.

05What a compliant build actually involves.

5.1Can an existing site be made accessible, or does it need to be rebuilt?

It depends entirely on how the site was originally built. A custom WordPress site with clean, semantic HTML can usually be brought to WCAG 2.1 AA compliance through targeted remediation — fixing contrast issues in the stylesheet, adding alt text to images, labeling form fields, ensuring keyboard focus is visible. This typically takes 8–20 hours of developer work on a small business site. A site built on a page builder where the entire structure is div-soup generated by a visual editor is often cheaper to rebuild than to remediate — because the structural violations are baked into the builder's output, not isolated in a few places you can fix.

5.2What does the actual build process look like for an accessible WordPress site?

At Tucson Web Design Co., accessibility is a design constraint from the beginning — not an afterthought. The process looks like this: (1) Color palette is checked for contrast ratios before any design work proceeds. (2) Typography hierarchy is established in HTML — H1, H2, H3 in logical document order, not just visual size. (3) All images get descriptive alt text (or empty alt="" for decorative images). (4) All form fields have associated <label> elements. (5) All interactive elements are keyboard-reachable and show visible focus. (6) ARIA attributes are added to dynamic components (mobile menus, accordions, modals). (7) The final build is audited with Axe Core (automated) and a manual keyboard/screen reader test. Compliance isn't a step at the end — it's the entire build process.

5.3What does accessible content writing look like?

Accessible content has several specific requirements beyond "plain English." Link text should be descriptive — "Read our service page" not "Click here." Headings should outline the page content in logical order (H1 for the page title, H2 for major sections, H3 for subsections) — not be used for visual styling. Images that convey information need alt text that describes the information, not just the appearance. Tables need header cells labeled with <th> and scope attributes. PDFs accessible to screen readers need to be created as tagged PDFs from accessible source documents. None of these are design changes — they're content and markup habits.

5.4How do you test for accessibility once the site is built?

Automated testing first. We run Axe Core (the industry standard), Google Lighthouse, and WAVE on every page. Automated tools catch roughly 30–40% of WCAG violations — they're useful for catching the mechanical issues (contrast, missing alt text, unlabeled inputs) but they can't test for logical keyboard navigation order, screen reader announcement quality, or whether form error messages are actually helpful. Manual testing follows: keyboard-only navigation through every interactive element, screen reader testing with NVDA (Windows) or VoiceOver (Mac/iOS), and review of every dynamic interaction. A site isn't declared compliant until it passes both automated and manual testing.

5.5Does accessibility require ongoing maintenance?

Yes. Every time you add content, a new service page, a new blog post, a new form, or a new interactive component, you're creating new potential WCAG failures. Alt text needs to be added to new images. New form fields need labels. New dynamic components need keyboard support. This is why accessibility overlays fail — they don't run during content creation, only during page rendering, so they can't catch violations introduced by ongoing content management. An accessible site needs an accessible content process, which means whoever updates the site needs training on the handful of content-level requirements that apply to non-developer edits.

06Hiring — what to ask your web design firm.

6.1How do I know if a firm actually builds accessible sites?

Ask them to run Axe Core on one of their recent client builds and share the results. A firm that builds accessible sites will not hesitate. A firm that doesn't will either say they "follow accessibility best practices" without specifics, or offer to run the test and then go quiet. The other signal: ask whether they test with a screen reader or just automated tools. Automated tools alone are not a complete accessibility testing program. A firm that mentions NVDA, VoiceOver, or keyboard navigation testing in the same breath as Axe Core is demonstrably more serious than one that doesn't.

6.2What should an accessibility deliverable include?

At minimum: an Axe Core / WAVE audit report showing zero violations at launch, a WCAG 2.1 AA compliance statement for the site, documentation of manual keyboard navigation testing, and a content guide for whoever will be managing the site after launch — covering alt text, heading structure, and link text. Some firms also provide a Voluntary Product Accessibility Template (VPAT), which is a formal document used to declare compliance. VPATs are often required for government or enterprise contracts but are good documentation practice for any business with legal exposure.

6.3What does accessible design actually cost extra?

At a competent firm, accessibility-compliant design costs the same as design that isn't compliant — because it's the default. The color contrast ratios are checked during palette selection, not retrofitted. The semantic HTML is written once, correctly. The form labels are added during development. The extra time is in testing: a thorough keyboard and screen reader test on a small business site typically adds 4–6 hours to a project. That's a modest investment against the cost of a demand letter. If a firm charges a significant premium for "accessibility compliance," either they're upselling a normal part of the job, or they're retrofitting compliance onto an inaccessible-by-default process.

6.4What if I already have a site and want to get it compliant?

Start with an audit. A real audit — not a quick automated scan, but a document that identifies every WCAG violation by category, priority, and estimated remediation effort. From there, triage: fix the high-priority violations first (form labels, keyboard accessibility, missing alt text) because those are most likely to appear in a demand letter. Then address the medium-priority issues (contrast, heading structure, ARIA). Build a maintenance plan for ongoing content. For most small business sites, full WCAG 2.1 AA compliance is achievable within a few weeks of focused effort — the blockers are usually knowledge and prioritization, not technical complexity.