Websites and SEOWCAG 2.2 for small businesses: accessibility basics

WCAG 2.2 for small businesses: accessibility basics

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, the standard most governments, large companies and procurement teams use to judge whether a website can be used by people with disabilities. For a small business, the guidelines can look like hundreds of pages of technical rules. Most of the work comes down to a manageable set of habits in design, content and code. This guide explains what WCAG 2.2 is, what changed from earlier versions and the basics worth getting right on any business site.

What WCAG is, in one paragraph

WCAG is published by the World Wide Web Consortium (W3C). It sets out testable “success criteria” grouped under four principles: they cover whether people can perceive the content, operate it, understand it, and use it with assistive technology such as screen readers. Each criterion has a level: A (the minimum), AA (the level most laws and contracts point to) and AAA (the highest, not usually required for whole sites). When people say a site “meets WCAG”, they normally mean Level AA.

Wall signs marking wheelchair access and pram access
Accessible sites work for more customers. Photo: Pexels

What changed in WCAG 2.2

The W3C published WCAG 2.2 as a Recommendation on 5 October 2023. According to the W3C’s summary of what’s new in WCAG 2.2, it adds nine success criteria and removes one (4.1.1 Parsing, now obsolete). The new criteria at levels A and AA, which matter most for business sites, are:

  • Focus Not Obscured (Minimum), AA: when someone moves through the page with a keyboard, the item in focus must not be completely hidden, for example behind a sticky header or cookie banner.
  • Dragging Movements, AA: anything done by dragging, such as a slider or a drag-to-reorder list, needs a simple alternative like tapping or clicking.
  • Target Size (Minimum), AA: buttons and links should be at least 24 by 24 CSS pixels, or have enough space around them, with some exceptions such as links inside a sentence.
  • Consistent Help, A: if you offer help such as a phone number, chat or contact link on several pages, keep it in the same place on each.
  • Redundant Entry, A: do not make people type the same information twice in one process, such as re-entering a delivery address as the billing address without an option to reuse it.
  • Accessible Authentication (Minimum), AA: logging in should not depend on a memory or puzzle test unless there is an alternative. Allowing password managers and copy-paste helps meet this.

WCAG 2.2 is backwards compatible, so a site that meets 2.2 also meets 2.1 and 2.0.

Why it matters for a small business

Accessible sites are easier for everyone to use: older customers, people on small phones, people in bright sunlight, people with a temporary injury. The same changes also tend to help search engines understand your pages, because headings, alt text and clear link text are what Google reads too.

There is also the legal and commercial side. In India, the Rights of Persons with Disabilities Act, 2016 includes provisions on access to information and communication technology. If you sell to government bodies, large enterprises or international clients, expect to be asked about WCAG conformance. How these rules apply to your particular business is a question for a lawyer, and the rules in India and the UAE continue to develop, so check the current position.

An accessibility basics checklist

Content

  • Give meaningful images alt text that says what the image shows or does. Decorative images can have empty alt text.
  • Use real headings (H2, H3) in a logical order, not bold text styled to look like headings.
  • Write link text that makes sense on its own: “Download the price list” rather than “click here”.
  • Add captions to videos and transcripts to audio.
  • Write plainly. Short sentences and familiar words help everyone, including readers using English as a second language.

Design

  • Check colour contrast. Level AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
  • Do not use colour alone to convey meaning, such as a form field marked wrong only by turning red.
  • Make buttons and links large enough to tap, at least 24 by 24 CSS pixels.
  • Show a visible focus outline so keyboard users can see where they are.
  • Keep sticky headers, chat widgets and cookie banners from covering focused content.

Forms and interaction

  • Every form field needs a visible label, not just placeholder text that disappears when typing starts.
  • Error messages should say what went wrong and how to fix it.
  • Everything should work with a keyboard alone: menus, forms, pop-ups, sliders.
  • Do not block pasting into password or verification fields.
  • Set the page language in the code, so screen readers pronounce the text correctly.

How to test without a large budget

  1. Run a free automated checker such as WAVE or Lighthouse in Chrome. These catch missing alt text, low contrast and missing labels. Automated tools find only part of the problems, so treat a clean result as a starting point.
  2. Put your mouse away and use the Tab key to move through your home page, a service page and the contact form. Can you reach and use everything? Can you see where you are?
  3. Zoom the browser to 200 per cent and check that nothing overlaps or disappears.
  4. Turn on the screen reader built into your phone (VoiceOver on iPhone, TalkBack on Android) and try to complete your contact form.
  5. For a formal claim of conformance, or if a client asks for an accessibility statement, get an expert audit.

Fixing an existing site

Start with the pages that matter most: home, main service pages, contact, checkout if you sell online. Fix the quick items first: alt text, labels, contrast, link text. Then tackle anything that needs a developer, such as keyboard access to menus or focus handling in pop-ups. For a new site, write “meet WCAG 2.2 Level AA” into the brief so it is built in from the start, which is far cheaper than retrofitting.

Accessibility checks are part of the testing stage in every website Emberoot builds, and the same approach applies to the mobile and web apps we develop.

Not sure where your site stands? Talk to us and we can run a quick review together.

This article is general information, not legal advice.

Frequently asked questions

Is WCAG 2.2 a legal requirement for my business?

WCAG itself is a technical standard, not a law. Laws and contracts in many countries refer to it, usually at Level AA, and in India disability rights law includes provisions on accessible technology. Whether a requirement applies to your website depends on your sector, customers and location, so check with a lawyer if you need a firm answer.

What is the difference between WCAG Level A, AA and AAA?

Level A covers the most basic requirements, such as text alternatives for images. Level AA adds criteria such as colour contrast and visible focus, and is the level most laws, policies and client contracts ask for. Level AAA is the strictest and is not generally expected for entire websites, though some AAA criteria are easy wins.

Can an accessibility plugin or overlay make my site WCAG compliant?

Overlay widgets that add a toolbar to your site do not fix the underlying code, such as missing form labels, poor heading structure or keyboard traps. They can also interfere with screen readers that users already rely on. Treat accessibility as part of how the site is designed and built, and fix issues at the source.

Tell us what you are trying to build.

A thirty-minute call, no charge. If we are not the right team for it, we will tell you and point you to someone who is.