Website Accessibility Audit for San Diego Businesses

A website accessibility audit for a San Diego business should answer a practical question: can people complete the tasks that matter, including finding a location, booking a room, requesting an estimate, submitting a healthcare form, buying a product, or sending an RFQ? A color-contrast score by itself cannot answer that.

Accessibility is part of the customer journey, not a technical add-on. The useful approach is to test the website against Web Content Accessibility Guidelines (WCAG) 2.2, combine automated and human review, repair the components that create repeated barriers, and assign ownership so the same problems do not return after the next content or design update.

Key takeaways

Start with the customer tasks that affect access, service, and revenue, not a random list of URLs.
Use automated checks to find patterns, then add keyboard, screen-reader, zoom, form, and mobile testing.
Fix shared templates and components before repairing the same issue page by page.
Treat third-party booking, payment, scheduling, and application tools as part of the journey.
A clean automated report is not proof of accessibility or legal compliance.

Why website accessibility matters across San Diego County

San Diego County combines a large online audience with different service models. The U.S. Census Bureau QuickFacts profile reports that 94.9% of households had a broadband subscription in the 2020–2024 period. It also reports that 7.3% of residents under age 65 had a disability and that 17.5% of residents were age 65 or older. Those measures should not be added together, and they do not capture every person who benefits from accessible design. They do show why an online path should not assume perfect vision, hearing, dexterity, memory, or device conditions.

The priority journey differs by business. A North County hotel may depend on a booking engine, a South Bay clinic on a bilingual intake flow, an East County contractor on an estimate form, and an Otay Mesa manufacturer on an RFQ portal. The audit must follow the customer beyond the homepage.

The U.S. Department of Justice guidance on web accessibility and the ADA explains that inaccessible websites can prevent people with disabilities from accessing goods and services. It identifies barriers such as weak contrast, missing text alternatives, uncaptained video, inaccessible forms, and mouse-only navigation. The guidance also says automated tools should be paired with manual checks.

Set the audit scope around user tasks

Auditing every public URL can be impractical, while auditing only the homepage can miss the most serious barriers. Define the scope with representative templates, components, content types, and complete processes.

Choose priority user journeys

List the actions a customer must complete and rank them by impact. Typical priorities include contact, booking, account access, checkout, applications, downloads, and support. Include error, loading, and confirmation states where they change the experience.

Choose a representative sample

The W3C’s WCAG-EM overview recommends defining the scope, exploring the website, selecting and evaluating a representative sample, and reporting findings. A business sample may include the homepage, a service page, a location page, the contact flow, a form with errors, a third-party tool, and every unique template.

What a WCAG 2.2 audit should examine

WCAG 2.2 is the latest WCAG 2 version encouraged by W3C. It retains the earlier success criteria and adds nine more. For most business teams, Level A and AA provide a practical technical target, but a conformance target is not a substitute for advice about the laws, contracts, or industry rules that apply to the organization.

Perceivable content

Check text contrast, alternative text, captions, heading structure, information conveyed by color, and content at 200% zoom. Decorative images should not create screen-reader noise, while informative images need text that explains their purpose.

Operable controls

Use the keyboard to operate every control and embedded tool. Focus must be visible, logically ordered, and not trapped or hidden by sticky content. WCAG 2.2 adds Level AA criteria involving obscured focus, dragging alternatives, and minimum target size in many situations.

Understandable forms and instructions

Confirm that labels connect to controls, required fields are identified without color alone, instructions arrive on time, and errors explain the repair. Repeated information should be reusable where the criterion applies. Authentication should support password managers and copy-and-paste instead of memory tests.

Robust code and assistive technology

Use semantic HTML for headings, buttons, links, lists, tables, and landmarks. Controls need an accessible name, role, state, and keyboard behavior. Incorrect ARIA can misrepresent the nonvisual experience. Test with a common screen-reader and browser combination instead of inferring behavior from code.

Automation finds code patterns, not the whole experience

An automated scanner can flag issues such as missing attributes or some contrast failures. It cannot reliably decide whether alt text is useful, keyboard order makes sense, instructions are clear, a dialog is understandable, or a complete booking path works with assistive technology.

Run the website accessibility audit in six layers

Inventory the site and dependencies. Map templates, components, forms, embedded media, booking, payment, chat, and account tools. Record who can change each surface.
Run an automated baseline. Scan the representative sample, group findings by shared cause, and keep the tool, date, page, component, and evidence.
Complete a keyboard pass. Confirm every action is reachable, focus is visible, menus and dialogs behave predictably, and focus returns logically after overlays close.
Test zoom, reflow, touch, and motion. Review narrow widths, larger text, and reduced motion for clipped content, horizontal scrolling, tiny controls, and overlapping labels.
Test forms and transactions. Submit invalid and valid states, confirm errors stay associated with fields, and follow the journey into third-party systems.
Use assistive technology and human judgment. Review structure, names, reading order, image alternatives, links, and live updates with a screen reader. Include experienced users with disabilities for high-impact journeys when possible.

Prioritize repairs by customer impact and repetition

A critical blocker in checkout or appointment booking usually deserves attention before a low-impact issue on an archived article. Rank each finding by the user harm, task importance, frequency, number of affected templates, ease of detection, and risk of recurrence.

Then repair at the source. A missing form label may come from one shared component. Weak focus styles may come from a design token. Empty alt text may reflect a CMS workflow that never asks editors for context. Fixing the system can remove dozens of instances and prevent the next content update from recreating them.

When the problem sits inside a broader conversion path, compare the accessibility repair with other sources of friction. The Branding Bull San Diego hotel mobile booking audit shows how performance, forms, booking clarity, and measurement can be reviewed as one customer journey rather than separate checklists.

A practical 30-day accessibility improvement plan

Week 1: define scope and establish the baseline

Name an owner, choose the target standard and level, map priority journeys, identify third-party dependencies, select representative pages, and run automated and keyboard reviews. Document the test environment and steps.

Week 2: remove critical task blockers

Repair issues that prevent navigation, forms, booking, checkout, account access, or support. Add labels, names, keyboard behavior, visible focus, clear errors, captions, and useful text alternatives.

Week 3: repair templates and content systems

Move repeated fixes into components, design tokens, templates, and CMS fields. Add editorial guidance and ask third-party vendors for accessibility documentation and an escalation path.

Week 4: retest and build ownership

Repeat failed steps and regression-test repaired components. Record what passed, what remains open, its owner, and the next review date. Add accessibility to design, code, content, and release reviews.

Measure progress without claiming false certainty

A useful scorecard reports operational progress, not one grade. Track critical-task blockers, high-impact findings, shared components repaired, templates tested, pre-release regressions, third-party issues, and customer reports.

Keep the evidence. For each finding, preserve the page, component, steps, expected behavior, actual behavior, user impact, standard reference, severity, owner, and retest result. This turns the audit into a maintainable product backlog rather than a PDF that becomes stale.

Common mistakes to avoid

Treating an accessibility overlay as proof that the underlying site and complete customer journey work.
Optimizing for an automated score while keyboard, screen-reader, zoom, and form problems remain.
Repairing individual pages but leaving the same defect inside a shared component or CMS workflow.
Excluding third-party booking, payment, scheduling, chat, document, or authentication tools from the scope.
Publishing an accessibility statement without a monitored contact route or a process for resolving reports.
Waiting until the end of a redesign to test interactions that are expensive to rebuild.

Frequently asked questions

Does the ADA require every private business website to meet WCAG 2.2?

The Department of Justice says the ADA applies to goods and services that public accommodations provide online, but its guidance for businesses does not set a detailed web regulation that simply says every private site must meet WCAG 2.2. WCAG is useful technical guidance. Ask qualified legal counsel how federal, California, contractual, and industry-specific requirements apply to the exact business and digital service.

Is an automated accessibility checker enough?

No. W3C and DOJ guidance both emphasize that tools cannot determine the full accessibility of a website. Use automation for repeatable patterns, then add manual evaluation and assistive-technology testing.

Which pages should a San Diego business audit first?

Start with the paths that customers need most: contact, booking, checkout, account access, applications, directions, support, and high-traffic service pages. Include a representative sample of templates and third-party steps.

Should accessibility wait for the next website redesign?

Critical barriers should be addressed as soon as they are understood. A redesign can incorporate deeper component, content, and workflow improvements, but it should not become a reason to leave an unusable customer task in place.

How often should a website be tested?

Test high-impact components during design and development, run regression checks before meaningful releases, review new content as it is published, and schedule broader audits based on the pace of change and risk. A frequently updated ecommerce or booking flow needs more attention than a stable brochure site.

Build accessibility into the website operating system

A website accessibility audit for a San Diego business is most valuable when it changes how the team designs, develops, publishes, procures, and measures digital experiences. The goal is not to produce a perfect score. It is to remove barriers from real customer tasks and make future updates safer.

The Branding Bull can help assess priority journeys, improve accessible design systems, repair website components, and build practical quality checks through web and mobile application services and creative and branding support. Schedule a consultation to define the audit scope and the first repair sprint. Legal conclusions and formal conformance claims should remain with appropriately qualified reviewers.

Website Accessibility Audit for San Diego Businesses: A Practical WCAG 2.2 Checklist