WCAG 2.2 — Accessibility Aidxn Ships by Default in 2026
Accessibility isn't a feature you ship later. WCAG 2.2 added three critical requirements: focus-visible rings for keyboard users, drag-and-drop alternatives, and minimum 44x44px target sizes for touch. Aidxn baseline ships all three by default. Semantic HTML first, keyboard navigation on every page, focus rings that don't suck, alt text that describes images (not "image.jpg"), and axe-core running in CI to catch defects before merge. Real bugs spotted in client builds. Plus Australian Disability Discrimination Act compliance pressure means inaccessible sites aren't just ethically wrong — they're legally risky. This post covers why accessibility pays, WCAG 2.2 essentials, the 5 patterns every site needs to ship, how to automate audits, and six FAQ answers so you don't have to guess.
♿⌨️✨
Accessibility is not a tax. It's the minimum viable product. An inaccessible site isn't inclusive — it's incomplete. A page that requires a mouse breaks for keyboard-only users (estimated 5–8% of your audience). A video without captions locks out deaf visitors. Missing alt text hides images from screen readers and Google's image search. And a button with a 24x24px hit area is untappable for anyone with tremors or on mobile with fat fingers. These aren't edge cases. They're 15–20% of your potential audience you're turning away. WCAG 2.2 (released September 2023) raised the bar: focus-visible is mandatory, drag alternatives are required, and target sizes jumped to 44x44px minimum. Aidxn sites ship with all three baked in. Not as an afterthought. Not as a checklist item. As the default.
Why Accessibility Pays (Beyond Ethics)
Ethical argument first: one in four Australians have some form of disability. One in six Australians are older adults with vision or hearing loss. Accessibility is inclusion. If you're not building for them, you're excluding real people who want to buy from you, read your content, and use your product. That's wrong.
Business argument: inaccessible sites leak revenue. If 15% of your potential audience can't use your site, you're leaving 15% of conversions on the table. A SaaS landing page doing $100k/month at 2% conversion rate is missing 3–4 conversions per day from accessibility issues alone. That's $3–4k/month in lost ARR. For a $1M/year SaaS, that's $36–48k/year from just fixing focus rings and target sizes.
SEO argument: Google rewards semantic HTML and good alt text. Screen readers and Google's crawlers read the same markup. A site built with proper heading hierarchy (`
`, `
`, `
` in order), semantic buttons instead of divs with click handlers, and alt text on every image ranks better because Google understands your content faster. Accessibility and SEO are the same audit.
Legal argument (AU context): The Australian Disability Discrimination Act (DDA) and the Disability Standards for Accessible ICT 2015 require website accessibility. Courts have upheld this — websites are covered. Lawsuits are rare but they happen. Startup insurance doesn't cover DDA claims. Fix accessibility now, avoid the risk later.
WCAG 2.2 Essentials (What Changed)
WCAG 2.0 shipped in 2008. WCAG 2.1 added mobile accessibility in 2018. WCAG 2.2 (2023) tightened three areas based on 15 years of real-world data:
1. Focus Visible (Level AA)
Keyboard users need to see where they are on the page. Every interactive element — button, link, form field, slider — must have a visible focus ring when you tab to it. No invisible focusables. :focus-visible CSS pseudo-class shows focus only when keyboard navigating (not mouse clicking, which is noise). Minimum ring contrast: 3:1 against adjacent colors. Aidxn default: 2px solid blue ring with 4px outline offset. No way to miss it.
2. Target Size (Level AAA → AA)
Click/tap targets must be 44x44px minimum (was AAA-only, now AA requirement). This is the size of a fingertip on a phone. Buttons, links, form fields, radio buttons, checkboxes — all 44x44 minimum. Marketing sites often ship with 24x24px buttons "for design"? Not anymore. 44x44 is not negotiable. It's not ugly if your design is good. Aidxn sites hit the target.
3. Draggable Elements (Level A)
If your UI has drag-and-drop (reorder cards, drag sliders, file uploads with drag zones), you must provide a keyboard alternative. Users who can't use a mouse can't drag. Offer arrow keys, a text input field, or buttons to move items. Same functionality, different input. Velocity X sites don't usually have heavy drag UI, but if you're building a dashboard or design tool, this is mandatory.