Back to reviews and guides

Website ADA Compliance in Minnesota: What You Need to Know About Website Accessibility

Website ADA compliance in Minnesota requires following WCAG 2.1 AA best practice, auditing both automated and manual issues, and prioritising fixes for core user tasks. Publish an accessibility statement, use a remediation plan that fixes templates first, and keep accessibility in your development and procurement processes.

Website ADA Compliance in Minnesota: what you need to know

Website ADA compliance in Minnesota matters for any business that serves the public. State and federal disability laws, plus a growing body of court decisions and settlements, mean website accessibility is a legal risk and a user-experience priority. This guide explains the legal landscape, the technical standard commonly used, and a practical step-by-step plan to make a site accessible and reduce risk.

Who must make a website accessible?

Federal law under the Americans with Disabilities Act (ADA) prohibits disability discrimination by places of public accommodation. Minnesota law, including the Minnesota Human Rights Act, also prohibits disability discrimination in public-facing services. Courts and agencies have varied on how these laws apply to websites, but many enforcement actions and settlements involve websites that are linked to a physical place of business or to services offered to the public.

Which technical standard should you use?

Most courts, plaintiffs and accessibility practitioners use the Web Content Accessibility Guidelines at level AA as the practical standard. That typically means using WCAG 2.1 AA success criteria and, where relevant, newer WCAG 2.2 guidance. Use WAI-ARIA roles correctly when needed and follow semantic HTML and accessible patterns for forms, navigation and media.

Typical paths are demand letters, settlement negotiations, and lawsuits under federal ADA or state disability law. Many cases are resolved by settlement rather than a court ruling on the law itself. The risk is higher when a website is closely tied to a physical place of public accommodation, such as a hotel, retail chain, restaurant, health care provider or government service.

How to check your risk right now

Run a quick triage to set priorities.

  • Does your business have a physical location that the public visits? If yes, risk increases.
  • Do you sell goods or services online that require accounts, bookings or payments? If yes, prioritise critical flows.
  • Do you receive federal funding or fall under specific state obligations? Check agency rules for additional requirements.

Accessibility audit: what it must include

A useful audit combines automated scans, manual testing and assistive-technology checks.

  • Automated tools to find common problems, such as missing alt text and contrast failures.
  • Manual checks for keyboard navigation, focus order, form labels and meaningful link text.
  • Screen-reader testing with at least one free and one commercial reader, for example NVDA and VoiceOver.
  • Mobile testing for touch targets and responsive behaviour.
  • A prioritised issue list mapped to WCAG success criteria and recommended fixes.

Step-by-step remediation plan (practical)

This plan is designed to be actionable. Adjust the scope to your site and resources.

  1. Inventory: compile URLs, templates, plugins and document types to include.
  2. Audit: run automated scans and full manual testing of key pages and tasks.
  3. Prioritise: score issues by impact and frequency. Start with barriers in core tasks like checkout, booking, account creation and contact information.
  4. Fix templates: correct header structure, navigation, forms and media players at the template level so fixes scale.
  5. Content clean-up: update images with alt text, rewrite poor link text, ensure headings reflect structure.
  6. Widget and third-party review: require accessible embeds or replace failing components.
  7. Regression testing: test after each release and use automated checks in CI for high-risk pages.
  8. Accessibility statement and feedback channel: publish a clear statement and a way for users to report problems and request help.

Accessibility statement and documentation

An accessibility statement shows intent and helps mitigate risk. It should state the goal of WCAG 2.1 AA conformance, list known limitations, explain how to request help and provide contact details and response expectations. Keep the statement factual and update it after remediation milestones.

VPAT and procurement

When buying third-party software or a CMS, ask for a Voluntary Product Accessibility Template or equivalent accessibility documentation. A VPAT describes how a product meets WCAG and other criteria. Use it as part of procurement, but always verify claims with technical testing.

Ongoing governance and training

Accessibility is not a one-off project. Make it part of publishing and development workflows.

  • Train content editors on headings, alt text and link text.
  • Include accessibility checks in design reviews and QA scripts.
  • Schedule periodic audits and user testing with people who have disabilities.
  • Log and fix accessibility issues in each sprint or release cycle.
  • Relying only on automated scans and ignoring manual tests.
  • Fixing single pages instead of underlying templates or CMS patterns.
  • Using inaccessible third-party widgets without fallback or negotiation.
  • No public contact method for people who experience barriers.
  • Publishing an inaccurate accessibility statement that overstates conformance.

Decision framework for small Minnesota businesses (new practical element)

Use this quick framework to decide action and budget.

  1. Identify core public tasks on the site. If any task is essential to revenue or public access, treat it as high priority.
  2. Estimate effort by scope: template fixes first, then content. Template fixes protect many pages at once.
  3. If you have limited funds, adopt a phased approach: fix high-impact tasks, publish an accessibility statement, then expand fixes.
  4. Set a measurable goal, for example to eliminate the top five barriers on core tasks within the next releases, and measure regressions monthly.

What to do after you receive a demand letter

Take these steps without delay.

  • Preserve correspondence and relevant records.
  • Review the allegation with counsel experienced in accessibility matters.
  • Run an immediate audit of the pages referenced and the main user flows.
  • Respond with a remediation plan and timeline if advised by counsel. Demonstrable, timely action reduces litigation pressure.

Checklist: quick technical must-haves

  • All images have meaningful alt text or empty alt for decorative images.
  • Forms have visible labels and programmatic associations.
  • Keyboard focus is visible and logical across the interface.
  • Contrast ratios meet WCAG guidelines for text and UI components.
  • Video has captions and audio descriptions where required for essential content.
  • ARIA is used correctly and not to fix structural problems that should be solved with HTML.

Where to get help in Minnesota

Look for accessibility consultants with WCAG experience, developers who have real remediation case work, and legal counsel who handle ADA and state disability law. Also consider user testing with people who use assistive technology. Document each engagement carefully to show good-faith effort.

Final practical notes

Start with a focused audit of core tasks. Fix template-level issues first. Publish an honest accessibility statement and a clear feedback channel. Keep accessibility in design and development workflows so improvements last. That approach protects users and reduces legal risk under both federal law and Minnesota state law.