Global Accessibility Awareness Day is on May 21 this year. It is the third Thursday in May, the way it always has been since 2012, and it is the one day a year when the entire web -- developers, designers, regulators, journalists, even the people at the platforms you depend on -- pays attention to whether websites work for people with disabilities.
For a small-business owner, GAAD is awkward. The big tech companies post their accessibility highlight reels. Government agencies announce new compliance deadlines. The big agencies publish their pricey audit packages. And you, the person running a five-person business with one part-time web person, are left wondering whether you are supposed to do something, and if so, what.
Here is what you are supposed to do: something. Anything. The goal is not to fix everything before May 21. The goal is to use the week as a focusing event -- a reason to spend a few hours on a topic you have been deferring all year. By May 21 you should be able to point at one concrete thing that is better than it was on May 15.
This is a six-day plan that gets you there. Each day is roughly thirty to sixty minutes of work, no developer required, no money spent. By Thursday you will have done more than ninety percent of small businesses do in an entire year.
Why bother if nobody is going to sue you next week
The honest answer is: somebody might. The ADA Title III plaintiffs' bar has been filing roughly 4,500 website-accessibility lawsuits per year in U.S. federal and state courts for the last three years, and the rate has accelerated in 2026 since the Department of Justice published its Title II final rule and signaled that WCAG 2.2 AA is the new floor. Small businesses are not exempt. The plaintiffs' firms specifically target small businesses because the settlement math is favorable for them: a small business is more likely to settle for $8,000–$15,000 to make the case go away than to litigate for $200,000.
But the real reason to bother is more boring than that. Fifteen to twenty percent of every human population has a disability. If your website does not work for them, you are leaving fifteen to twenty percent of your potential customers on the table. The accessibility-aware customers also tell their friends, leave better reviews, and -- this is the part the SEO community has finally figured out -- spend longer on accessible pages, which Google reads as a quality signal. Accessibility is not just about compliance. It is about whether the customers you already paid to acquire can actually buy from you.
GAAD is just an excuse to start.
Day 1 (Friday, May 15): Take the keyboard test
Open your homepage in any browser. Put your mouse on the other side of the desk. Press the Tab key.
A focus indicator -- usually a thin outline around the currently selected element -- should jump from one interactive thing to the next: the menu, the search box, each navigation link, each button, each form field. Keep pressing Tab and try to get from the top of the homepage all the way to the footer using only the keyboard.
Three questions to answer:
Can you see the focus indicator at every step? If at any point the focus indicator disappears entirely -- you can no longer tell what is selected -- that is a WCAG 2.4.7 (Focus Visible) failure. This is the single most common issue on small-business websites and it is fixable in about ten minutes by anyone who can edit a stylesheet.
Does the tab order make sense? It should follow the visual order, roughly top-to-bottom, left-to-right. If Tab jumps from the header to the footer and then back up to the middle of the page, that is a WCAG 2.4.3 (Focus Order) failure and your customers using screen readers are getting a scrambled experience.
Can you actually complete the things your customers need to do? Try to add an item to your cart with the keyboard. Try to submit your contact form. Try to use your search box. If any of these traps you -- you can tab in but not out, or you cannot reach the submit button at all -- that is a WCAG 2.1.2 (No Keyboard Trap) or 2.1.1 (Keyboard) failure.
Write down what you find. Do not fix anything yet. Today is a diagnostic, not a fix.
Day 2 (Saturday, May 16): Run a free automated scan
Visit wave.webaim.org/ and enter your homepage URL. Wave is a free tool from WebAIM that flags the most obvious accessibility issues automatically.
You will get a list. Some entries will be red ("errors") and some will be orange ("alerts"). Ignore the alerts for now -- those are things that might be a problem but require human judgment. The red ones are the ones to focus on.
The three most common red errors on small-business sites are:
Missing alt text on images. Wave flags every image that has no alt attribute. For decorative images (background photos, logos, icons that have text next to them) the fix is to add alt="" -- an empty alt attribute, not no alt attribute. For meaningful images (product photos, blog header images, screenshots) the fix is to write a one-sentence description of what the image shows. Our alt text guide walks through the difference.
Missing form labels. Wave flags every form field that does not have a label. The fix is to add a <label for="email">Email address</label> element next to the input. If you cannot edit HTML directly, your platform -- Squarespace, Wix, Shopify, WordPress with a page builder -- has a way to set labels on form blocks. Most platforms get this right by default; most third-party widgets (Mailchimp, ConvertKit, HubSpot embeds) get it wrong, which is why we keep flagging them.
Empty links and buttons. Wave flags links that have no text and buttons that have no label. The most common cause is a social-media icon link that has an image but no aria-label="Facebook" to tell a screen reader what the icon is for. The fix is one attribute per icon.
Scan your homepage, your most-trafficked landing page, and your contact page. Note the count of red errors on each. By the end of the week you want that count to be lower than it is today.
Day 3 (Sunday, May 17): Check your color contrast
Visit webaim.org/resources/contrastchecker/. This is a free contrast checker, also from WebAIM.
For your site's three most important text combinations -- body text on background, link text on background, button text on button -- get the hex codes of the foreground and background, plug them in, and look at the result.
WCAG 2.1 AA requires a contrast ratio of at least 4.5 to 1 for body text and 3 to 1 for large text (18 point or 14 point bold). If your body text is light gray on white, your link text is brand-blue on white, or your call-to-action button has white text on a pastel background, you are likely failing.
The fix is usually trivial: darken the body text, darken the link color, change the button background to something closer to your brand's primary color. The reason this is worth doing is that low-contrast text is one of the most-tested accessibility issues by plaintiffs' firms -- because it is one of the easiest things to prove in a complaint. Our color contrast guide explains the math and walks through the most common small-business failures.
Make a list of every text/background combination that fails. Adjust your site's primary brand colors if needed. This is a thirty-minute task that often pays back in a 5–10% boost in conversion, because the text that was illegible to your low-vision customers is now legible to all your customers.
Day 4 (Monday, May 18): Fix the top five issues
You now have three lists: keyboard issues from Day 1, automated-scan issues from Day 2, and contrast issues from Day 3.
Pick the top five things across all three lists. Fix them.
For most small businesses, the top five will be:
- Add a visible focus indicator to your CSS (one or two lines:
:focus { outline: 2px solid #1a1a1a; outline-offset: 2px; }) - Add
alt=""to every decorative image and write real alt text for every meaningful image - Add
<label>elements (or platform-equivalent labels) to your contact form, your newsletter signup, and your search box - Add
aria-labelattributes to your social-media icon links and any other icon-only buttons - Bump your body-text color from #888 (or whatever low-contrast gray you are using) to #333 or #000
If you cannot fix something yourself, write it down for your developer or your platform's support team. Send the list. Do not wait until June.
Day 5 (Tuesday, May 19): Write or update your accessibility statement
An accessibility statement is a public page on your website that says three things: (1) you are working on accessibility, (2) this is the standard you are working toward (usually WCAG 2.1 AA or WCAG 2.2 AA), (3) here is how to contact someone if you find an accessibility problem.
This is the single most-leveraged thirty minutes you will spend this week. An accessibility statement is not legally required everywhere, but in jurisdictions where it is recommended (most EU member states under the EAA, several U.S. states for public-accommodation websites), having one demonstrably reduces lawsuit risk because it shows good-faith effort and gives a customer with an accessibility complaint a path other than calling a lawyer.
Our accessibility statement guide has a template you can adapt. The minimum version is four paragraphs and a contact email. Publish it at /accessibility/ or /accessibility-statement/, link to it from your footer, and add the date you last updated it.
Day 6 (Wednesday, May 20): Tell someone
This is the part most small-business owners skip, and it is the part that matters most.
Pick one person on your team -- a designer, a copywriter, a customer-support lead, your virtual assistant -- and tell them what you did this week. Walk them through the list. Show them the keyboard test. Show them the contrast checker. Show them the WAVE scan.
The goal is not to make them an accessibility expert. The goal is to make sure that the next time someone on your team launches a new page, embeds a new widget, swaps a brand color, or changes the footer, they know that accessibility is a thing they should be checking. One person who knows this is far more valuable than one expensive audit you commission once a year and then forget about.
If you have an external developer, send them the WAVE report and ask them to flag accessibility issues in their pull requests from now on. If you use a page-builder platform, look at their accessibility documentation and bookmark it. If you have a design system or brand-style guide, add a contrast-ratio requirement to it.
This is what makes GAAD work for a small business: not the heroic one-time push, but the small handoff that makes accessibility somebody's job going forward.
What to do on May 21
On the actual day, do three things.
First, run the WAVE scan again on your homepage. Compare the error count to the one you wrote down on Day 2. It should be lower. That is your GAAD result. Take a screenshot.
Second, post about it -- on LinkedIn, on your blog, in your newsletter, wherever your customers see you. You do not need to be technical. "We took accessibility seriously this week and made these five fixes to our website" is enough. Customers with disabilities and their families notice this. So do regulators and journalists who cover the space.
Third, put May 19, 2027 on your calendar as the start of your GAAD 2027 prep week. Make it a yearly habit.
That is the entire plan. Six days, no money, no developer required, and at the end of it your website is measurably more accessible than it was a week earlier. The plaintiffs' bar can still file a lawsuit against you next month, but you will be in a much stronger defensive position than the ninety percent of small businesses that did nothing this week. And -- the part that actually matters -- a few more of your customers can buy from you than could last Friday.
Related Reading
- The 5-Minute Accessibility Audit Anyone Can Run -- if you only have time for one of the six days, pick this one
- How to Write an Accessibility Policy That Doesn't Read Like a Lawyer Wrote It -- a deeper version of the Day 5 step
- Why Accessibility Overlays Don't Work (and What to Do Instead) -- if a vendor offers to "fix accessibility in one line of code" this week, read this first
We're building a simple accessibility checker for non-developers -- no DevTools, no jargon. Join our waitlist to get early access.
Top comments (0)