Accessible and honest teaching
No scare tactics about lawsuits, just clear reasons and fixes. The regulatory overview was balanced and helped me brief our product lead.
Browse
Learn the WCAG 2.2 criteria that matter most, test with keyboards and screen readers, and design components everyone can use
Created by Owen Gallagher
Accessibility is often treated as a checklist that someone runs at the end of a project. By then fixes are expensive and the team is tired. This course teaches you to design and test for WCAG 2.2 level AA as part of normal work, so accessible interfaces become the default rather than a late rescue.
We start with how WCAG is structured and which success criteria cause the most real problems: contrast, keyboard access, focus visibility, labels, error handling and target size. You will then learn a testing routine that combines automated tools with manual checks using a keyboard, browser zoom and screen readers such as VoiceOver and NVDA.
The course suits designers, front end developers and QA engineers who already build interfaces and want to do it accessibly. Code examples use plain HTML and a little ARIA, so they apply whatever framework you use. The final section covers how to keep accessibility alive in a design system and what current regulations, such as the European Accessibility Act, mean for digital teams.
Accessibility specialist and UX writer teaching inclusive, clear interfaces
I work on accessibility and content design for web and mobile products. I audit interfaces against WCAG, test with screen readers and keyboards, and write the words people see in buttons, forms and error messages.
I teach these two skills together because they overlap more than most people expect: a clear label helps a screen reader user and everyone else. My courses cover practical WCAG 2.2 testing, accessible patterns for common components, and writing microcopy that is short, specific and kind.
I keep the tone practical. You will test real pages, rewrite real copy and learn to explain accessibility issues to a team in a way that gets them fixed.
No scare tactics about lawsuits, just clear reasons and fixes. The regulatory overview was balanced and helped me brief our product lead.
I had installed NVDA before and given up after five minutes. The short command list and the side by side comparison with VoiceOver finally made testing feel doable.
Labels, hints and error messages are now part of my first draft in Figma. The annotation kit is something our developers specifically thanked me for.
The content is accurate and useful, but some lessons move fast if you are new to ARIA. I had to rewatch the menus and tabs lesson twice.
The plain language walk through of the new criteria was the clearest I have read. I wish there were a few more React examples, but the HTML ones translate easily.
We now run the keyboard pass and axe on every pull request. The audit report template helped me group issues by component, which cut the number of tickets a lot.
The dialog and focus management lesson fixed a long standing bug in our app. The section on tables felt a little short.
As a designer I appreciated that half the course is about decisions made before code. Target size and focus ring guidance is now in our design system.
The contrast, keyboard and screen reader checklists are printed on my desk. I found three blockers in our sign up flow the same afternoon.