Someone finds your firm after a car accident. They enlarge the text because reading is difficult, but the contact button disappears behind the navigation. Another visitor uses a keyboard and can't open the practice-area menu. A third finishes your form, makes one mistake, and can't find out which field needs correcting.

You worked to help those people find the firm, but the website then got in their way.

I'd start an accessibility review with a practical question: can someone understand what your firm does and contact you using the tools they rely on? A scan can point out some problems, but to find out whether the page works for a visitor, you also have to try what they're trying to do.

Key takeaways

  • Test whether visitors can understand the firm's work and complete the contact process.
  • Use automated checks alongside keyboard, enlarged-text, and screen-reader evaluation.
  • Repair repeated barriers in shared menus and form controls, then retest the affected tasks.
  • Define a technical accessibility target and assess the firm's legal obligations separately.

Choose a standard and understand what it proves

The Web Content Accessibility Guidelines, or WCAG, describe testable requirements for accessible web content. WCAG 2.2 Level AA is a sensible technical target for a new website or substantial remediation project. Your agreement with a developer should identify the version, level, and scope of testing, because “we'll make it accessible” is too vague to evaluate.

Meeting a technical standard and establishing your firm's legal obligations are related questions, but they require different evidence. The Department of Justice takes the position that the Americans with Disabilities Act (ADA) applies to the online services of public accommodations. Its web accessibility guidance also distinguishes general obligations from detailed technical standards. The specific rule for state and local government websites should not be presented as a universal deadline for private law firms.

Ask counsel which requirements apply to your firm, and ask the website team for a record of what it tested and fixed. Those are different jobs. Buying a widget or publishing an accessibility statement doesn't show that visitors can use the site, and neither guarantees protection from a claim.

Test the journey that matters most

Start with a practice-area page, an attorney biography, and the contact process. Include any third-party scheduling service or intake form, because those external steps are part of the experience even if another company supplies them.

Imagine a visitor trying to answer: “Does this firm handle my situation, and how do I ask about it?” Follow that journey with a keyboard. Then repeat it with enlarged text and on a small phone. A trained tester should also use a screen reader, which reads the page and exposes its controls through speech or braille.

Perhaps the menu opens with a mouse but won't open from the keyboard. Or the consultation banner covers the field you're typing into. Show the developer the exact page and the steps that lead to the problem. “I can't open the employment-law menu using the keyboard” gives them a much clearer starting point than “navigation needs accessibility work.”

The W3C's first-review checks are a useful introduction. They're an initial review, not a complete conformance audit.

Repair the form all the way through

A contact form has several opportunities to fail. Its labels need to remain understandable when a visitor starts typing. Required fields need an explanation beyond a change in color. Error messages need to identify the problem and help the person correct it.

Consider a hypothetical date field that accepts only one format. A visitor enters “October 14, 2026,” submits the form, and sees a red border. That border gives them no usable instruction, whereas “Enter the date as MM/DD/YYYY” explains what to do next.

Check whether submitted values survive an error. Requiring someone to retype a long account of their situation can turn a small correction into a reason to leave. Also check that successful submission produces a clear confirmation and that the message actually reaches intake. Accessibility and delivery both matter to the person expecting a reply.

The W3C forms tutorial explains labels, instructions, and feedback in more detail. Keep the initial inquiry proportionate; the website doesn't need to become an exhaustive legal intake questionnaire before anyone has spoken with the firm.

Make the information usable in more than one form

An attorney introduction video may be helpful, but its information shouldn't depend on hearing the audio. Provide accurate captions and a useful text version. Review automated captions for names and legal terms before publication.

For images, ask what the reader needs to know. A photograph that simply decorates the page can have an empty text alternative. An infographic explaining a process needs a text explanation of that process. “Legal infographic” doesn't convey its meaning. W3C's image guidance helps distinguish these uses.

Headings should describe the sections they introduce. Links should make their destinations understandable in context. A visitor moving between headings or links should be able to find the fee explanation or contact route without reading the page from beginning to end.

Clear headings and useful text explanations help other readers as well, which is a good reason to make the changes. That benefit doesn't let you promise that they'll raise the firm's search rankings by a particular amount.

Fix shared components before repeating work

If the same menu fails on fifty pages, repair the menu component. If every form uses the same inaccessible date picker, fix or replace that control. Shared templates often provide the fastest way to remove a repeated barrier.

For each repair, keep enough detail that someone else can repeat the check. Which task failed? How can the developer reproduce it, and which shared part of the site needs changing? Name the person responsible, then record what happened when you tried again after the fix.

Automated tools are helpful for repeatable checks, including some missing labels and contrast problems. They can't decide whether an instruction makes sense or whether a visitor can complete an unfamiliar task. Use them alongside manual evaluation, and include people with disabilities in usability work where possible.

If a vendor offers an accessibility overlay, ask it to show you what the product changes on your page. What has it tested with assistive technology? What still needs work from your developer? You'll still need to check the visitor's experience after installing the software.

Keep the improvement from disappearing

Accessibility work needs to survive the next content update. Give editors a short set of practical instructions for the elements they publish: headings, images, links, documents, and video. Test changed forms and navigation before release.

An accessibility statement can explain the firm's approach and provide a way to report a problem. Describe tested facts honestly. Avoid declaring complete conformance when the evidence covers only a handful of pages. Ensure the reporting channel itself works and that someone monitors it.

Start with one real visitor task this week. Can a person using a keyboard reach the relevant practice page and submit an inquiry? If they can't, fix that journey, retest it, and use what you learn to inspect the rest of the site.

If your team needs help connecting website repairs with its broader marketing priorities, talk with Morpheus Consulting Inc. about the pages and contact routes you want to improve.