Accessibility in Action: Recapping Our 8-Hour GAAD Marathon

Global Accessibility Awareness Day (GAAD) is always a significant moment to get people talking, thinking, and learning about digital access and inclusion. When we announced our Accessibility in Action Full-Day Livestream, we promised to move past abstract concepts and bring you directly into the daily, hands-on work of our team.

On May 21, 2026, we did exactly that. Accessible Web hosted an intense, 9-to-5 marathon of unfiltered testing and rapid-fire auditing.

Led by Ben, our Accessibility Services Team Manager, alongside our dedicated crew of specialists—Kelsie, Marc, Isabella, Hope, our team took the live components submitted by our viewers and put them through their paces. Between audits, our specialists shared deep-dives into core accessibility patterns they are passionate about and fielded live questions from our community.

If you weren’t able to catch the full 8-hour livestream, we have compiled a recap of the key blocks and the technical and cultural takeaways from the marathon. We analyzed a lot of code and components during the 9-to-5 marathon, so we aren’t stopping here. Keep an eye on our YouTube, social channels, and your inbox —we will be releasing more specialized highlight clips covering form labeling, layout tables, and accordion state fixes. More to come!

Key Takeaway Spotlight

We are breaking down the biggest lessons from the day into bite-sized videos. Check out this featured clip from one of our accessibility specialists highlighting a critical takeaway from the livestream:

Watch on YouTube for the full transcript.

Block 1: Navigation Disclosure Buttons

• The Submission: Disclosure Buttons in Navigation
• Expert Spotlight: Buttons vs. Links
  A common flaw across modern websites is an identity crisis between native links and buttons—especially when building complex, custom interactive widgets.
• The Key Takeaway: The rules of HTML are strict: use standard native links (<a>) when an interaction navigates the user to an entirely new page or a different destination on the current page. Use native buttons (<button>) when triggering an on-page change, such as expanding a navigation dropdown. If you rely on custom widgets, you must programmatically inject the necessary ARIA states (like aria-expanded=”true/false”) so screen readers can dynamically track whether a menu is open or closed.

Block 2: SVG Wheel

• The Submission: SVG Wheel Graphic
• Expert Spotlight: Layout Tables
  Visually striking layout elements, like circular informational wheels, are frequently organized on the back end by using structural tables to hold pieces of text in place.
• The Key Takeaway: HTML tables should be reserved exclusively for tabular data. When <table> tags are used simply to force text into visual layout columns, it completely breaks the reading order for screen reader users, forcing them to listen to cell properties rather than content. If a layout table must be used, it must be stripped of its data semantics by utilizing role=”presentation” or role=”none”.

Block 3: Support Guide Navigation

• The Submission: Navigation Bar
• Expert Spotlight: Emotion and Digital Accessibility Work
  Between analyzing complex code trees, the team paused to address an excellent question from the live chat regarding the human elements of web advocacy.
• The Key Takeaway: True digital accessibility isn’t merely an engineering exercise; it requires a great deal of emotional intelligence and cultural buy-in. Moving a legacy team or an entire organization toward inclusive design means building empathy and framing accessibility as a basic civil right rather than a dry administrative compliance checklist or an engineering burden fueled by the fear of being sued.

Block 4: Services Accordion

• The Submission: Services Accordions
• Expert Spotlight: Real-Time Community Vibes
  For this mid-day block, the specialists shifted the focus toward an open-mic format, taking the pulse of the audience chat and answering unscripted, rapid-fire accessibility questions.
• The Key Takeaway: Interactive widgets like expandable accordions fail completely if state changes aren’t explicitly passed to the accessibility tree. If a keyboard user cannot visually identify where their focus indicator is, or if a screen reader isn’t told that an accordion panel has opened, vital interactive services are hidden away from a massive percentage of your users.

Block 5: Product Carousel

• The Submission: E-Commerce Product Carousel
• Expert Spotlight: Accessible Form Labels
  Interactive sliding carousels often come packed with hidden elements, navigation dots, search filters, or pagination parameters meant to sort online store inventory.
• The Key Takeaway: Every input field and interactive indicator requires a programmatically determinable label. Without explicit HTML <label> tags or fallback aria-label elements attached to navigation arrows and dots, automated tools and screen readers will simply state vague values like “button” or “blank input,” completely disorienting e-commerce users who are trying to choose a product.

Block 6: Image Links & Contrast

• The Submission: Image Links & Heading Visual Contrast
• Expert Spotlight: Text Alternatives and Logical Headings
  This portion of the audit evaluated nested page architecture where graphic designs function entirely as structural hyperlinks.
• The Key Takeaway: When an image acts as a link, that image’s alt text serves as the accessible name for the destination. If the contrast inside that image text fails to meet WCAG standards, or if the alt tag is uninformative, the link becomes a complete dead end for keyboard or assistive technology users. Furthermore, maintaining a strict, logical heading hierarchy (<h1> through <h6>) remains the primary way screen reader users skim a website.

Block 7: “Submit a Request” Form

• The Submission: Contact & Ticket Request Form
• Expert Spotlight: The Language of Digital Accessibility
  Web forms are historically error-prone when it comes to reporting field errors or guiding a user through dynamic parameters.
• The Key Takeaway: The vocabulary we select to communicate required fields, errors, and validation warnings matters. Using explicit, plain language alerts combined with programmatic attributes (like aria-describedby or aria-invalid=”true”) removes ambiguity. It transforms a frustrating, error-prone submission process into a predictable, intuitive workflow.

Block 8: Customization Grid

• The Submission: Sizing and Color Selection Options
• Expert Spotlight: Dynamic Selection Patterns
  Our final live audit of the marathon examined custom grid patterns where online shoppers select retail specifications, such as choosing product sizing or jersey colors.
• The Key Takeaway: Choosing variations on a product page must dynamically update state attributes in the background. If a box changes color visually to signify it has been selected, that shift must be instantly mirrored programmatically (such as updating aria-selected or aria-checked). If these indicators stay hidden from the accessibility tree, a buyer cannot reliably verify what they are adding to their shopping cart.

Accessibility in Action

As you look at the digital barriers across your own company websites, digital products, or agency portfolios, don’t let the scale of the work freeze your momentum. This is especially true given recent federal updates. While the DOJ recently extended the compliance dates for the ADA Title II ruling out to April 2027 and 2028, your underlying legal liability hasn’t paused. State-specific accessibility statutes remain in full effect, and providing an inaccessible digital experience continues to be an active legal risk.

(To understand why you cannot afford to put your accessibility workflows on the back burner during this extension window, read our full breakdown: The ADA Title II Deadline Moved—But Your Liability Didn’t.)

If our 8-hour marathon proved anything, it’s that accessibility is an ongoing commitment to progress over perfection. It is never a static, one-time checklist. True inclusion requires a continuous rhythm of auditing, monitoring, and remediation.

How Accessible Web Can Help

You don’t have to wait for the next Global Accessibility Awareness Day marathon to figure out where your digital assets stand. Our RAMP platform is built around a comprehensive Compliance Center engineered to act as your continuous roadmap to WCAG 2.1 AA conformance. Use RAMP to establish an official, defensible paper trail of your remediation progress, run automated scans across your pages, and deploy built-in feedback forms to catch user barriers before they turn into liability claims.

• Schedule a Consultation: Let our team of specialists help you build a budget, inventory your digital footprint, and prioritize your remediation.
• Start a Free 14-Day RAMP Trial: Gain access to automated scanning, and map your long-term roadmap to compliance today.

Digital accessibility is a fundamental part of a successful online experience, and we are here to help you ensure that every member of your audience can fully engage with your digital presence.