Understand which ADA discussion applies
This is general information, not legal advice. Ask legal counsel to assess which obligations apply to your organization. hehe.software helps implement the technical side of accessibility; we do not certify legal compliance.
The Department of Justice's web accessibility guidance says Title III of the Americans with Disabilities Act applies to goods, services, privileges, and activities offered by public accommodations, including online. Businesses open to the public must make their websites accessible to people with disabilities. The guidance also says DOJ does not have a regulation setting detailed web accessibility technical standards for private businesses. Flexibility in implementation does not remove the accessibility duty.
Title II has a separate rule for web content and mobile apps provided or made available by state and local governments, including through contractors. It specifies WCAG 2.1 Level AA. The compliance deadlines are April 26, 2027 for governments with populations of 50,000 or more, and April 26, 2028 for smaller public entities and special district governments. These are government-rule deadlines, not a general timetable for private business websites.
For a Canadian business serving US customers, or an agency working across borders, give counsel a clear description of the business and its audience. For a government project, identify the public entity and ask it to confirm the applicable requirements before you scope implementation.
Turn WCAG into a written technical target
The Web Content Accessibility Guidelines, or WCAG, are W3C's technical standard for accessible web content. They contain testable success criteria at Levels A, AA, and AAA. Level AA conformance includes the Level A criteria as well as the AA criteria. A target needs both a version and a level: simply asking for an accessible site leaves too much undefined.
For a new private-business project, consider WCAG 2.2 Level AA as the engineering target. W3C encourages use of the latest WCAG version. Record any different version specified for your project separately, including the Title II rule's WCAG 2.1 Level AA standard where relevant. Choosing a technical target does not answer the legal applicability question.
Write down what the evaluation covers: templates, customer journeys, languages, documents, embedded services, and account states. Include error messages and successful submissions. A tidy homepage cannot demonstrate whether someone can recover a password or complete a purchase.
Start with the tasks that matter to customers
Create a short inventory around actions: find a service, compare products, request a quote, book an appointment, sign in, and get support. For each action, identify the starting page, intermediate steps, and completion message. Test a complete journey rather than a collection of disconnected screenshots.
Include shared navigation and footers, plus unusual components such as date pickers, filters, consent dialogs, and payment forms. Record who can change each component. An embedded booking service needs an owner and a repair route just as much as your own contact form.
Use the checklist below for an initial review. It helps uncover barriers and define follow-up work; it is not a complete WCAG evaluation. Keep a separate list of anything you could not test.
| Check | Try this | Record the barrier |
|---|---|---|
| Keyboard | Use Tab and Shift+Tab through a complete task; activate links and controls. | Unreachable controls, missing focus indicators, or places you cannot leave. |
| Forms | Submit empty and incorrect fields, then correct them. | Missing labels, unclear instructions, or errors that are difficult to locate. |
| Zoom | Enlarge text and inspect narrow layouts. | Clipped instructions, overlapping controls, or hidden actions. |
| Screen reader | Navigate headings and controls, then submit a form. | Unclear names, unexpected reading order, or unannounced results. |
| Images and media | Check whether essential information is available without seeing an image or hearing audio. | Missing image descriptions, inaccurate captions, or unexplained visual steps. |
| External services | Continue through booking, payment, or support tools. | The affected vendor component and the exact step that fails. |
Check keyboard access and page structure
Set the mouse aside and follow your main customer journey. Watch the visible focus indicator as you move between controls. Open navigation, choose options, dismiss popups, and submit forms. A menu that looks correct while closed still needs testing while open.
For a modal dialog, W3C's authoring pattern places focus inside when it opens, keeps Tab navigation inside while it is active, and supports Escape to close it. Focus generally returns to the control that opened it, unless the next workflow step calls for another logical location. Ask your developer to test these transitions explicitly.
Review headings and page regions with someone who can inspect the underlying structure. A large, bold line is not automatically a heading that assistive technology can navigate. Use descriptive headings, meaningful link text, and a way to skip repeated navigation. Ask for a screen reader check of reading order and control names as well as a visual inspection.
Make forms understandable before and after submission
Give each field a visible label associated with its control. Explain required information and any unusual format before the person submits. Placeholder text inside a field should not be the only label. Group related choices so their shared question is clear.
Test errors deliberately. A red border alone does not explain what happened. Provide text that identifies the affected field and describes how to correct the problem. Ask your developer to check that assistive technology can find the error and understand its relationship to the input.
Test the successful path too. After someone sends an inquiry or adds an item, verify that the outcome is communicated without relying only on a visual change. Keep a test account and safe test data available so the person evaluating the site can inspect account recovery, validation, and completion states without sending real customer requests.
Inspect contrast, enlarged text, and content alternatives
WCAG's Level AA minimum text contrast is generally 4.5:1, with 3:1 allowed for qualifying large text. There are exceptions, including logos and inactive controls. Measure the actual foreground and background combination instead of judging a color swatch. Check text over photographs, validation messages, and hover states as well as ordinary paragraphs.
WCAG's resize-text criterion calls for text to resize up to 200% without losing content or functionality, except for captions and images of text. Its reflow criterion addresses vertically scrolling content at a width equivalent to 320 CSS pixels without requiring scrolling in both directions, with exceptions for content that needs a two-dimensional layout. Have your developer test both criteria; a phone screenshot alone is insufficient.
Write image alternatives according to purpose. Describe essential information in informative images; use empty alternatives for purely decorative images. For an image acting as a button, describe the action. Provide a text equivalent for meaningful chart data. Avoid filling alternatives with promotional keywords.
For video, review captions against the actual speech and meaningful sounds. Identify visual information that the audio does not explain, such as a silent demonstration, and plan the appropriate description. W3C's media guidance covers captions, transcripts, descriptions, and accessible players. Put media accessibility into the production brief so it is considered before editing finishes.
Combine automated checks with human evaluation
Use automated tools to collect potential issues and repeat checks after changes. W3C cautions that tools cannot evaluate every accessibility aspect and can produce misleading results. A report with no detected errors is useful evidence about that test, but it does not establish that every visitor can use the site.
Pair scanning with keyboard testing, zoom checks, and screen reader evaluation by someone familiar with the technology. Include people with disabilities in usability testing where possible. Give participants realistic tasks, such as changing an appointment, and observe where the interface makes progress difficult.
For each finding, record the page and state, steps to reproduce it, expected behavior, observed behavior, and affected task. Ask the evaluator to identify the relevant WCAG criterion where applicable. Preserve screenshots or recordings when useful, but include enough written detail for a developer to reproduce the problem.
Build a repair backlog with clear acceptance checks
Prioritize barriers that stop essential tasks, then shared components whose repair can improve multiple pages. For example, address an unreachable checkout action before polishing a secondary illustration description. This is a practical repair sequence, not a reason to discard the remaining issues.
Assign each issue to a developer, designer, content editor, or vendor contact. Separate fixes you control from those requiring an external supplier. For a blocked vendor component, request a specific correction and discuss an interim access route while the technical problem is addressed.
Write acceptance checks around behavior. Instead of saying fix the popup, specify that a keyboard user can open it, reach its controls, close it, and continue from a sensible place. Repeat the original failing task after deployment. A closed ticket should have retest evidence.
- Agree on the WCAG version, level, and evaluation scope before work starts.
- Request findings with reproduction steps and user impact.
- Name the person responsible for each repair and its retest.
- Keep unresolved issues and untested areas visible in the handoff.
- Include content editors in instructions for future pages, images, and media.
Keep accessibility in the publishing process
Add accessibility checks to the work that already happens before publishing. Editors can check headings, link wording, image alternatives, and captions. Designers can check color combinations and enlarged layouts. Developers can check component behavior and repeat the customer journeys affected by a change.
Provide an easy way for visitors to report an accessibility problem. Ask which task failed and which page they were using, then route the report to someone who can investigate. If you publish an accessibility statement, describe the work and known limitations accurately. Keep it aligned with actual evaluation evidence.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, British Columbia, Canada, working remotely with businesses across Canada and the United States. We offer accessibility implementation, website fixes, UI/UX design, and maintenance, including work on sites we did not build and sub-projects for agencies. Email mwe@hehe.software with your site, known barriers, platform, and essential customer tasks. We can scope a fixed-price project, paid discovery, hourly work, or a monthly retainer; pricing is quote-only.