Skip to main content
Wallyax

Wallyax Blogs

Articles & Podcasts

Practical writing on digital accessibility - for designers, developers, and compliance teams.

Compliancearticle

Accessibility Risk Is Product Risk: Why Compliance Belongs in Roadmaps

This article explains why accessibility risk should be treated as product risk. It shows how inaccessible forms, dashboards, checkout flows, portals, and other digital experiences can create user friction, compliance exposure, procurement blockers, support demands, and release risk. It also explains how product teams can bring accessibility into roadmaps through audits, prioritization, remediation planning, design reviews, QA checks, documentation, and ongoing accessibility governance.

Accessibilityarticle

What the ADA Title II Deadlines Mean for Platforms That Work With Government Clients

This article explains what the ADA Title II web and mobile accessibility deadlines mean for private platforms and vendors that work with state and local governments. It covers the 2027 and 2028 compliance dates, WCAG 2.1 Level AA requirements, why vendor-managed tools may come under procurement review, and how SaaS companies, agencies, and digital service providers can prepare through audits, remediation, VPATs, accessibility documentation, and ongoing testing.

UXarticle

Accessibility Widgets Break Your Website Instead of Fixing It

This article explains why accessibility widgets should not be treated as a complete accessibility solution. It covers what widgets can do, where they fall short, and how they can interfere with screen readers, keyboard navigation, focus order, mobile layouts, forms, and assistive technologies. It also explains why relying on widgets can create a false sense of compliance and why real accessibility must be built directly into the website through WCAG-aligned design, development, testing, and remediation.

Accessibilityarticle

Why a 100 Google Lighthouse Score Does Not Mean Your Website Is Accessible

A Google Lighthouse Accessibility score of 100 is a useful indicator, but it should not be treated as proof that a website is fully accessible or compliant. Lighthouse can automatically detect common issues such as missing alternative text, poor color contrast, unlabeled controls, and inaccessible names, but many WCAG 2.1 and WCAG 2.2 requirements depend on context and human judgment. Problems involving keyboard focus, screen reader announcements, meaningful alternative text, dynamic content, form errors, and complete user journeys can remain even when automated tests pass. Tools such as Axe DevTools and the WAVE accessibility checker can provide additional insights, but they also cannot replace manual testing. A stronger accessibility compliance process combines automated testing, manual WCAG reviews, assistive technology testing, and evaluation of the tasks users actually need to complete.

Accessibilityarticle

Backrooms Is the perfect metaphor for an inaccessible web

This article uses the recent Backrooms movie as a metaphor for the inaccessible web, comparing confusing digital experiences to endless liminal spaces with poor direction, weak contrast, broken navigation, and no clear way out. It explains how accessibility issues affect real users and gives practical ways teams can make websites easier to navigate, understand, and complete.

Accessibilityarticle

WCAG AAA Explained - Web Content Accessibility Guidelines Beyond AA

This article explains WCAG AAA in the Web Content Accessibility Guidelines and how it differs from AA, with specific notes on WCAG 2.1 and WCAG 2.2. It highlights the kinds of “extra” requirements AAA introduces (like enhanced contrast, stricter timing controls, and stronger help and error prevention), how to assess feasibility, and how teams can use AAA as a targeted strategy instead of an all-or-nothing goal.