Gen Herres of Easy Alley Guide makes the case that web accessibility is not a charity project or a luxury reserved for enterprise budgets — it is a measurable business necessity that directly affects client revenue, customer service overhead, and legal exposure. Her central argument is that most agencies and freelancers avoid accessibility because they assume it requires a prohibitively large investment. She dismantles this assumption by presenting a focused, ten-test framework that can be audited and remediated on a homepage in approximately four hours of billable work.
The session is structured around the 80/20 rule: roughly 80% of accessibility failures originate from 20% of the WCAG criteria. Rather than attempting a full WCAG audit (which can cover 50 or more criteria), Herres proposes starting with three categories of questions — Can people read it? Can people use it? Can people get help? — and running a small, high-impact set of tests within each. The framework is practical, tool-driven, and designed to be learnable by people across a range of skill levels and budgets.
She backs the framework with a concrete client case study showing a 48% year-over- year revenue increase and a 94% reduction in customer service issues following an accessibility engagement. She also addresses legal context across the US, Australia, and the EU, and closes with advice on documentation, contracts, and liability protection.
Key takeaways
- 01A focused ten-test accessibility audit of a homepage can be completed in approximately four hours, split into two two-hour blocks, making it an affordable service offering for small clients.
- 02The 80/20 rule applies directly to WCAG: 20% of the criteria account for 80% of the failures most websites exhibit. Start there.
- 03Real business results are achievable: Herres's client saw a 48% increase in year-over-year revenue and a 94% drop in customer service issues after accessibility work was completed.
- 04Legal requirements exist in the US (ADA), Australia (Disability Discrimination Act), and the EU (European Accessibility Act), and they are evolving — accessibility compliance is increasingly a legal expectation, not just a best practice.
- 05AI-generated websites frequently omit skip links because the training data for most AI models contained websites that lacked them. This is a known, specific failure mode to watch for.
- 06Clear, descriptive link text and logical heading structure benefit not only users with disabilities but also SEO and AI comprehension of a website.
- 07The WAVE tool and the AXE extension serve different purposes: AXE reports definitive failures; WAVE casts a wider net of potential issues. Understanding this distinction prevents over-or under-scoping a remediation effort.
- 08An accessibility statement in the footer — including a commitment to accessibility, a description of built-in features, and a clear path to reach a human — is a critical element for both legal compliance and reducing escalation to lawyers or social media.
- 09Demonstrating ongoing effort matters legally. A recent lawsuit was dismissed because the defendant maintained an accessibility log showing a multi-year history of testing and remediation.
Why Accessibility Is Not Optional
Herres opens by addressing the most common objection from agencies working with small clients: the cost. The assumption in the industry is that accessibility work costs $10,000, $20,000, or more, making it unreachable for the average small business website client. Her session is explicitly aimed at dismantling this assumption.
She frames accessibility not as a technical checkbox but as a direct lever on client revenue.
The core insight is that many vague usability complaints — "I can't find anything," "the text is hard to read," "I don't know what I can click on" — are actually measurable accessibility failures with specific, testable criteria. Accessibility converts fuzzy user frustration into pass/ fail answers that clients can understand and buy into.
Her strongest framing: "If you're ignoring it, you are evicting customers."
The Real Numbers: A Client Case Study Herres shares data from a real client engagement to anchor the business case. After completing accessibility work: Revenue increased 48% year over year.
Customer service issues decreased 94%.
The customer service reduction was particularly significant for operational reasons. Before the accessibility work, the client's support team was overwhelmed with people who could not complete the checkout process, could not identify products clearly, or could not find the information they needed. After the fixes, the friction was removed, customers could complete transactions independently, and the support team could redirect their capacity to handling the surge in new orders.
When the retainer renewal came up, the client's decision was immediate and enthusiastic.
They could look at their financials before and after and see the impact directly in their books.
The Legal Landscape
Herres provides a concise overview of accessibility law across the jurisdictions most relevant to English-speaking clients.
United States: Americans with Disabilities Act (ADA) In the US, the ADA applies to any public-facing entity. If a business serves the public, its entire digital presence — not just its website — must be accessible. Herres emphasises the breadth of this: the obligation is not limited to a homepage or a contact form. Any digital touchpoint is included.
Australia: Disability Discrimination Act Australia recently updated its Disability Discrimination Act to bring digital accessibility explicitly within scope. Herres notes that Australia uses a slightly higher bar than the US when measuring compliance — a different version of WCAG — which means Australian clients face a more stringent standard.
European Union: European Accessibility Act (EAA) The EAA is more limited in scope than either the US or Australian frameworks, but it still carries meaningful implications for businesses operating in the EU. Small enterprises may be eligible for an exemption, while large enterprises face specific mandatory language requirements in their accessibility statements.
The Broader Point Herres notes that many other countries have their own laws and that the legal landscape is evolving. She uses the California Invasion of Privacy Act as an example of how new legal frameworks can appear suddenly, with no precedent, and immediately create exposure. This is a reason to have broad umbrella liability language in contracts rather than trying to anticipate specific legislation.
The Social Good Argument Beyond legal compliance, Herres makes the point that accessibility laws exist to allow people to participate in society — to receive goods at home, attend live events, access services. She draws an analogy to curb cuts and automatic doors: these were originally installed for wheelchair users, but they benefit everyone. The shopping cart, the stroller, the person on crutches, the person with a sprained ankle — all of them benefit from what was originally a disability accommodation. The same is true online.
Who Is Actually Affected
Herres addresses the common misconception that accessibility is a niche concern affecting a small number of users.
In the United States alone, 26% of the adult population has a qualified disability — meaning that even with the best available correction, they cannot read the top letter of an eye chart.
That is a profoundly large proportion of potential customers.
She is also careful to distinguish between qualified disabilities and the much broader range of everyday challenges that do not meet the legal threshold but still affect how people use websites: Difficult environments: bright sunlight, coffee shops with background noise, reading on a phone outdoors.
Temporary situations: a sprained ankle, recovering from surgery.
Lifelong but unqualified conditions: colorblindness affects one in twelve men. Most colorblind individuals never mention it because they were discouraged from doing so when young. They learned early that disclosing the condition invited skepticism or ridicule, so the vast majority stay silent. This means the number of users affected by colorblindness is systematically underestimated by anyone relying on self-reported data.
The Framework: Starting With the 80/20 Rule
WCAG contains 50 or more criteria depending on the version (the US uses WCAG 2.1 with 50 criteria; Australia's higher bar pulls in additional requirements from a later version).
Attempting to go from zero to full compliance in one engagement is, as Herres puts it, like trying to climb Everest. It is not a realistic starting point.
Instead, she proposes focusing on the roughly 20% of criteria that account for 80% of what goes wrong. She organises this into ten tests across three categories.
The practical scope: each of the first two categories can be tested and remediated on a homepage in approximately two hours. The first time through, it will take longer as the practitioner is learning. She explicitly recommends discounting that first engagement to account for the learning curve — both as an ethical practice and as a sustainable business decision.
An additional benefit: many of the fixes for these specific tests affect global styles, the header, and the footer, which means the remediation work cascades across the entire site, not just the homepage.
Part One: Can People Read It?
This category contains five tests. These are the easiest to sell to clients because the desired outcome — that people can read the website — is intuitive and directly connected to client goals.
Test 1: Color Contrast
Text must be readable. Color contrast provides a specific, measurable criterion for what "readable" means, removing the subjectivity from what would otherwise be a vague complaint.
How to test:
- In Chrome or any Chromium-based browser, press Command + Shift + C and hover over text. The developer inspector will display a contrast ratio and a green checkmark when the ratio passes.
- Run the AXE web extension (free, from DQ). AXE flags definitive failures with high confidence. It also powers Google Lighthouse, so either tool can be used.
- Use the WAVE tool for a broader sweep. WAVE flags potential issues, which means it will
surface more results than AXE. The same site might show 16 errors in AXE and 35 in WAVE.
WAVE results always require manual review to determine which are actual failures.
Important manual checks:
- Placeholder text in form fields is never flagged automatically and must be checked manually.
- Text over image backgrounds cannot be reliably computed by automated tools. Manual checking is required at each breakpoint, since different portions of the image may be behind the text at different screen sizes.
Test 2: Are Links Obvious?
This issue is more common than it might seem. Herres describes testing pages by keyboard navigation and discovering links hidden inside blocks of text that were visually indistinguishable from the surrounding prose — no color difference, no underline, nothing.
Pass criteria:
- Links have a consistent, visible style that distinguishes them from non-linked text.
- Buttons look like buttons. If it has a border around it, users will treat it as a button. Non-buttons should not look like buttons.
- Color alone should not be the only differentiator for links.
- Hover states are not a WCAG requirement, but they are important for usability. If hovering over an element produces any visual change — a card grows, a background color shifts — users will expect that element to be clickable. If clicking does nothing, users will assume the website is broken.
Test 3: Clear Link Text
Link text should communicate exactly where the link goes without requiring surrounding context. Fifty instances of "Learn More" or "Try Now" scattered across a page all fail this test.
Pass examples: - "View the 2026 Transparency Report" - "About our staff" - "Read the case study from ACME"
Failures: - "Learn more" (learn more about what?) - "Click here" - Icon-only links with no text label Herres notes that this test has benefits beyond accessibility: clear, specific link text improves SEO and helps AI systems understand site structure and navigation.
Test 4: Heading Structure
Headings should create a logical outline for the page — effectively a table of contents. This matters for human readers who scan a page, for screen reader users who navigate by heading, for search engines, and for AI systems parsing the content.
How to test: Use the WAVE tool and click the Structure tab. The heading outline will be displayed, and WAVE will flag structural errors.
Pass criteria:
- One H1 per page.
- H2s used for major sections.
- H3 and H4 used for subsections as needed.
- H5 and H6 are almost never appropriate for real-world content and should not appear in standard page structures.
Failures:
- Jumping from H1 directly to H4, skipping levels.
- Using H5 or H6 purely for visual styling. CSS classes exist for that purpose.
Test 5: Autoplay
Autoplay video and looping animations are a significant accessibility problem. Herres describes having to manually block a video on Shopify's homepage in her browser because the looping, flashing content made it impossible for her to use the navigation menu. She has also experienced needing to physically raise her hand to block content on screen so she could read text in a different area of the page.
Pass criteria:
- Pause controls and stop buttons are present for any video or animation.
- Animations either run once and stop, or are user-initiated.
Failures:
- Looping video or animation with no stop or pause control.
- Background animations that cannot be turned off.
Beyond usability, looping animations can cause physical nausea in some users. This is a physiological response, not a preference.
Part Two: Can People Use It?
This category contains four tests. Three of the four affect the header, making them site-wide fixes.
Test 6: Skip Links
Skip links allow keyboard users to bypass the main navigation and jump directly to the page content. This matters enormously for large mega menus that can contain 30, 50, or even 80 items — keyboard users should not have to tab through every single one to reach the page content.
How to test:
- Click into the browser address bar.
- Press Escape (possibly twice in Chrome to exit URL bar interactions).
- Press Tab. A "Skip to content" link should appear. 4.
Press Enter. Focus should move to the main content area.
Herres recommends w3.org as a reference site for what correct skip link implementation looks like.
Pass criteria:
- Skip link is present and functional.
- Skip link has adequate color contrast (not light gray on white).
Failures: - No skip link at all. This is extremely common on AI-generated websites. Herres explains why: the training data for most AI models was composed of websites that did not
have skip links. The AI reproduces what it learned, so it omits them.
- Skip link exists in the code but is implemented incorrectly and does not function when activated with the keyboard.
- Skip link is hidden using incorrect CSS and is never visible, even when focused.
Test 7: Focus State
Keyboard users need a visible indicator of where they are on a page at any given moment.
The focus state is the web equivalent of the yellow line down the centre of a road — functionally essential, regardless of aesthetic opinion.
Pass criteria:
- A clear, visible focus indicator is present (typically a ring or outline).
- A double ring is ideal, as the inner and outer rings create contrast with each other, ensuring the indicator is visible against any background.
- Focus navigates correctly through carousels and interactive components.
- A consistent focus style across the site is ideal, though some variation is acceptable as long as the indicator is always clearly visible.
- Focus states must meet a 3:1 contrast ratio.
Failures:
- Focus leaves the visible viewport, often during carousel navigation, requiring 20 to 30 Tab presses to return to something visible.
- Focus indicators that are too light in color to meet contrast requirements.
- CSS outline: none applied to remove the focus ring because someone decided it was not visually appealing. This is a definitive accessibility failure, not a design choice.
Test 8: Keyboard Menu Navigation
One of the most common failures Herres observes on websites. Users must be able to navigate the entire main menu using only a keyboard.
How to test:
- Tab to the main menu.
- Press Space to open a dropdown. The dropdown should open.
- Tab through the dropdown items.
- Press Escape. The dropdown should close, and focus should return to the parent menu item.
- Continue navigating through the rest of the menu.
A helpful enhancement: dropdown indicators (such as a small arrow icon next to menu items) allow keyboard users to anticipate which items have submenus before interacting with them.
Many websites fail at multiple points in this sequence.
Test 9: Alt Text and SVGs
Alt text provides text alternatives for images, making them accessible to screen reader users and valuable for SEO. The key principle is that alt text is always context-sensitive: the same image may need different alt text in different situations.
The framing question: If this image were deleted from the page entirely, what information would be lost? That lost information is what belongs in the alt text. In some contexts, an
image of a girl with a dog might require specific detail (breed of dog, relationship, setting). In other contexts, the same image is purely decorative and should have empty alt text (so screen readers ignore it).
How to test: Use the Accessibility Insights for Web extension from Microsoft, available on any Chromium browser. Toggle on "accessible names" to see the alt text overlaid on images.
Empty alt text is shown as empty — assess whether that is appropriate for each image.
SVG-specific requirements: SVGs are not reliably caught by standard automated testing tools and require manual inspection.
- Decorative SVGs: must have aria-hidden="true" so screen readers skip them.
- Meaningful SVGs: must have a <title> element within the SVG, or another accessible label.
Test 10: Can People Get Help?
No website will ever be perfectly accessible. Errors occur. The critical question is whether users can easily report a problem and reach a human, or whether they have no recourse except to leave — or contact a lawyer.
How to test: Go to the site's footer and look for the word "accessibility." If it is not there, the site fails.
What an accessibility statement should include: 1. A stated commitment to accessibility.
- A description of the accessibility features built into the site.
- Clear instructions for how to reach a human if a problem is encountered.
- For sites serving the EU: relevant EAA language. Small enterprises can claim an exemption; large enterprises have specific mandatory content requirements.
Packaging and Pricing This as a Service
Herres breaks the ten tests into two billable blocks: Part 1 (Can people read it?): Five tests, approximately two hours to test and fix on a homepage. Correcting these issues frequently also improves the header, footer, and global styles across the site.
Part 2 (Can people use it?)
Four tests, approximately two hours. Three of the four affect the header, creating site-wide impact from a scoped engagement.
Accessibility statement: An additional deliverable that can be packaged separately or included.
The total is roughly four hours of work for a genuinely high-impact, defensible starting point. Herres is explicit that the first engagement will take longer as the practitioner learns the process, and she recommends offering a discount on that first project to account for the learning curve.
She emphasises repeatedly: doing these ten things well is more valuable than attempting a broader audit mediocrely. Start here, build the process into standard workflows, and expand later.
Tools Referenced
- Chrome DevTools (Cmd+Shift+C hover): quick color contrast check, free.
- AXE Web Extension (from Deque): definitive accessibility failures, free.
- Google Lighthouse: accessibility audit powered by AXE, free and built into Chrome.
- WAVE Tool: broader sweep of potential issues, free.
- Accessibility Insights for Web (Microsoft): alt text inspection and detailed auditing, free.
Documentation, Contracts, and Liability
The Q&A portion of the session produced useful guidance on protecting both the practitioner and the client.
Documenting Compliance Herres distinguishes between two levels of documentation: Limited scope reports: When work is scoped to specific pages or criteria, the documentation should clearly state the scope. Write a report covering the specific areas tested and the results.
Full accessibility assessments: As practitioners advance, they can produce comprehensive reports using tools like Accessibility Insights for Web from Microsoft.
These are detailed and thorough, but require deeper accessibility knowledge to produce accurately.
The key is that documentation must match the scope of the work. A report on a homepage audit should not be presented as a site-wide compliance certification.
Protecting Against Legal Claims Herres addresses this directly in response to an audience question. Her guidance: Contracts should make the client responsible for legal claims arising from their site.
Liability language should be written broadly, not narrowly. The California Invasion of Privacy Act emerged suddenly and with little precedent. New legal frameworks will continue to appear. Broad umbrella liability clauses provide more durable protection than clauses that try to enumerate specific laws.
The Importance of Ongoing Effort A specific case was raised: what happens if a site is shipped in good faith with an accessibility statement but a failure is later discovered? Herres's answer is that accessibility compliance is not a one-time event but an ongoing practice.
She cited a lawsuit that was dismissed by a judge because the defendant maintained an accessibility log — a documented, multi-year history of testing and making fixes based on those tests. The log demonstrated that accessibility was not a performance but an active, continuous commitment. Demonstrating that pattern of effort is what courts have found persuasive.
Herres noted that another speaker at the same summit (Amber Hines, in an earlier session) covered similar legal territory and recommended watching that session in conjunction with this one.
AI Prompt Resource
Herres offers a free AI prompt for accessibility testing at easyalleguide.com/summit. She tested the prompt across multiple AI tools and found that Claude was the only one that produced reliable results without hallucinating accessibility issues that did not exist on the sites being tested. Other AI tools fabricated failures. She uses the prompt specifically with Claude and does not recommend it with other models.
About the Speaker
Gen Herres is the founder of Easy Alley Guide, where she teaches web accessibility with a focus on making it affordable and achievable across a range of skill levels and budgets. She can be found at easyalleguide.com/summit for the resources mentioned in this session.
About the speaker
Gen Herres
Easy Alley Guide
Gen Herres is founder of Easy Alley Guide, where she teaches web accessibility with an emphasis on making it affordable and achievable for agencies and clients at any budget or skill level.