Website ADA Compliance in North Carolina: A Practical Website Accessibility Guide

This guide shows North Carolina website owners how to approach Website ADA Compliance in North Carolina. It explains which federal rules matter, which technical standard to use, and a practical step-by-step remediation plan you can follow now.

Does the ADA apply to websites in North Carolina?

The Americans with Disabilities Act (ADA) is a federal law. It applies across the United States, including North Carolina. Title III covers places of public accommodation. Federal enforcement actions and many court decisions treat websites and mobile apps used by the public as subject to the ADA. There is no single binding federal regulation that names a specific web standard, but courts and agencies regularly point to Web Content Accessibility Guidelines.

Which accessibility standard should North Carolina websites follow?

Use a technical standard so developers and testers have clear targets. Options to consider:

• WCAG 2.1 AA — the most common baseline used in enforcement and contracts. It covers keyboard access, color contrast, captions and more.
• WCAG 2.2 — a W3C Recommendation with additional success criteria such as improved focus visibility and target size. Adopt it when practical.
• Section 508 — applies to federal agencies and contractors. It references WCAG for web content.

For most businesses and public-facing sites in North Carolina, aim for WCAG 2.1 AA as a minimum and plan to move toward WCAG 2.2 AA.

Key technical requirements to check first

• Keyboard access: All interactive elements must be reachable and usable with keyboard only. Check tab order, focus, and skip links.
• Contrast: Normal text should meet a 4.5:1 contrast ratio. Large text should meet 3:1.
• Alternative text: Images need meaningful alt text or proper role if decorative.
• Forms: Input fields need explicit labels and error messages that are programmatically connected.
• Multimedia: Provide captions for videos and transcripts for audio.
• Semantic HTML and ARIA: Use correct headings, lists, landmarks and WAI-ARIA only when needed.
• Accessible PDFs: PDFs must contain selectable text, structural tags and a logical reading order.

How to test a North Carolina website for accessibility

Testing must combine automated checks, manual inspection, and user testing with assistive technology.

Automated tools

• Run tools such as axe-core, WAVE or Lighthouse to find common code issues quickly.
• Automated tools catch only a subset of problems. Use them to prioritize fixes, not to certify compliance.

Manual checks

• Keyboard test: navigate the entire site without a mouse, activate controls and submit forms.
• Screen reader test: test pages with NVDA, VoiceOver, or JAWS to confirm meaningful reading order and labels.
• Color and contrast: verify with a contrast tool and also check for color not being the only means of conveying information.

Real-user testing

Contract people who use assistive technologies to test key tasks such as finding product info, completing a purchase and contacting support. Their observations find real barriers automated tools miss.

Practical remediation plan (step-by-step)

Use this actionable plan to move from unknown to maintained compliance.

Step 1 — Quick discovery (1–2 weeks)

• Run automated scans across the primary site templates and important pages.
• Compile the highest-impact issues: keyboard traps, missing labels, broken form errors, missing captions, and inaccessible PDFs.

Step 2 — Triage and scope (1 week)

• Classify issues into critical, major and cosmetic. Critical examples: inability to complete checkout, inaccessible legal notices, or lack of captions on essential video content.
• Identify owners: content team, design, front-end dev, third-party vendors.

Step 3 — Remediation sprint(s) (2–8 weeks)

• Fix critical and major issues first. Use semantic HTML and correct ARIA usage.
• Replace or update inaccessible third-party widgets where possible.
• Ensure new content follows an accessible content template for images, headings and links.

Step 4 — Manual testing and user validation (1–2 weeks)

• Perform end-to-end keyboard and screen reader tests on remediated pages.
• Run at least one round of testing with assistive-technology users for core journeys.

Step 5 — Accessibility statement and maintenance

• Publish an accessibility statement that lists your standard (for example WCAG 2.1 AA), what you have done, and how people can request help. Include a clear contact method.
• Schedule regular automated scans and quarterly manual checks. Add accessibility to your design and procurement workflows.

Who should be involved

• Senior sponsor — approves budget and policy.
• Product manager — sets priorities and releases scope.
• Front-end developer — implements code fixes and testing hooks.
• Content editor — writes alt text, headings and transcripts.
• QA engineer or accessibility specialist — runs manual and automated checks.
• People who use assistive tech — validate the user experience.

Common mistakes to avoid

• Relying only on automated tools. Many important issues need manual or user testing.
• Using ARIA as a substitute for semantic HTML. ARIA should augment, not replace, proper markup.
• Publishing an accessibility statement without a remediation plan or contact method.
• Failing to test PDFs, third-party vendors and legacy content.

What to do if you get a demand letter or lawsuit

I cannot give legal advice. Consider these practical steps while you seek counsel.

• Preserve evidence of your existing accessibility efforts, audits and remediation timelines.
• Engage outside counsel experienced in ADA website matters and an accessibility auditor.
• Prioritise fixes that remove core access barriers and document each change.
• Offer a clear contact path for the claimant while you remediate.

Accessible procurement and ongoing policy

Include accessibility requirements in vendor contracts. Require new code and components to meet WCAG 2.1 AA and to be delivered with test reports and documentation. Add an accessibility checklist to release criteria.

Quick accessibility checklist for North Carolina websites

Item	Minimum target
Technical standard	WCAG 2.1 AA (move toward WCAG 2.2 AA)
Contrast	4.5:1 normal text, 3:1 large text
Keyboard	Full site operable by keyboard
Captions/transcripts	Captions for prerecorded video, transcripts for audio
PDFs	Tagged, searchable and structured
Accessibility statement	Published with contact method and roadmap

Resources and next steps

Start with an automated site scan, document the top issues, and run user tests for core tasks. If your organisation has legal questions about obligations in North Carolina, get legal advice tailored to your circumstances.

Follow the step-by-step plan here and keep accessibility part of ongoing releases. Doing so reduces legal risk, improves customer experience and makes your site usable by more people.