Ten years ago I started sharing a desk with Samir, a backend developer who is blind and uses the NVDA screen reader. In his first week he tried to book a train ticket on a well-known site. He got as far as the seat map, a grid of clickable boxes that his screen reader announced as nothing at all, and gave up. He phoned the call centre and paid a booking fee for the privilege. That site’s developers were not careless people. They had never watched anyone like Samir use it.
\nThis course is about closing that gap, with code. You won’t learn a list of rules to recite; you will learn how disabled people actually operate a web page, and the specific HTML, CSS, JavaScript and ARIA that make your pages work for them.
\nThe World Health Organization estimates that about 1.3 billion people, around one in six, live with a significant disability. That number alone makes accessibility a mainstream concern, but it undercounts the people who benefit. Disability is often temporary or situational:
\nWhen you design for the left column, the people on the right get the benefit for free. Captions were built for Deaf viewers; today a large share of social video is watched with the sound off.
\nEvery year WebAIM runs an automated scan of the home pages of the top million websites. The 2026 run found detectable WCAG failures on 95.9% of them, with an average of 56 errors per page. The striking part is how ordinary the errors are. Six categories make up almost all of them: low-contrast text, images without alt text, form inputs without labels, empty links, empty buttons and a missing page language. None of these needs a specialist. Each takes minutes to fix once you know to look.
\nNotice that every one of them lives in the page’s own markup and styles. That is why this course never reaches for an “accessibility mode” toggle or a third-party overlay script: a second mode drifts out of date, and the default page, the one most disabled people land on, stays broken. You fix the source, and every user gets the fix.
\n\nThroughout the course you will audit and repair Ticketly, a single-page booking site for Harbour Lights, a weekend music festival. Ticketly looks fine with a mouse. Under the surface it has all six WebAIM classics, plus a seat picker that only responds to clicks, a “Book now” modal that leaves keyboard focus behind on the page, error messages that appear silently, and an Arabic event title read aloud with an English voice.
\nEach lesson takes one slice of Ticketly. Section 2 rebuilds its structure with semantic HTML. Section 3 makes it fully keyboard and screen-reader operable. Section 4 fixes what people see and read. Section 5 tests the result with axe, a keyboard, VoiceOver and NVDA, and turns the lessons into habits for a whole team.
\nBefore you change a line of code, though, you need to know what the people using Ticketly are using to reach it. The next lesson looks at assistive technologies and the accessibility tree they read.
\n","toc":[{"id":"sec-1","text":"Who you are building for","level":2},{"id":"sec-2","text":"The state of the web","level":2},{"id":"sec-3","text":"Meet Ticketly","level":2}],"takeaways":["About 1.3 billion people, roughly one in six, live with a significant disability, and many more face temporary or situational limits.","Accessibility barriers fall into a few families: seeing, hearing, moving, and understanding or remembering.","The WebAIM Million 2026 found detectable WCAG failures on 95.9% of the top million home pages, most of them in six simple categories.","Accessibility is a quality attribute of the code you write, like performance or security, not a separate feature bolted on at the end."],"further":[{"title":"W3C WAI: Introduction to Web Accessibility","url":"https://www.w3.org/WAI/fundamentals/accessibility-intro/"},{"title":"W3C WAI: How People with Disabilities Use the Web","url":"https://www.w3.org/WAI/people-use-web/"},{"title":"The WebAIM Million","url":"https://webaim.org/projects/million/"}],"quiz":[{"q":"A delivery driver reads Ticketly on a phone in bright sunlight and can barely see the light-grey prices. Which kind of limitation is this?
","options":[{"text":"A situational limitation that good contrast would fix for everyone","why":"Correct. The driver’s eyes are fine; the environment creates the barrier, and the same fix (stronger contrast) helps people with low vision too."},{"text":"Not an accessibility issue, because the driver has no disability","why":"Accessibility is about barriers in the interface, not diagnoses. The grey text fails people with and without a disability."},{"text":"A permanent visual impairment that needs a screen reader","why":"Nothing here is permanent, and a screen reader is the wrong tool for someone who can see the screen once contrast improves."}],"answer":0},{"q":"According to the WebAIM Million, which problem shows up on the most home pages?
","options":[{"text":"Missing document language","why":"It is in the top six, but it appears on about 13.5% of pages, far fewer than contrast failures."},{"text":"Empty buttons with no accessible name","why":"Empty buttons are common (about 30.6%), but they are not the most frequent failure."},{"text":"Low-contrast text","why":"Correct. Low contrast appeared on 83.9% of the home pages tested in 2026, the most common failure every year of the study."},{"text":"Keyboard traps in modal dialogs","why":"Keyboard traps are serious, but automated scanners can’t reliably detect them, so they are not counted in this ranking."}],"answer":2},{"q":"Why does this course fix Ticketly’s markup rather than adding an “accessibility mode” toggle?
","options":[{"text":"Because toggles are banned by WCAG 2.2","why":"WCAG has no rule against toggles. The issue is that a separate mode tends to lag behind the main site and still leaves the default experience broken."},{"text":"Because accessibility lives in the same HTML, CSS and JavaScript everyone uses, so fixing the source helps every user at once","why":"Correct. Semantic markup, labels and focus handling are properties of the page itself; there is no second page to maintain."},{"text":"Because screen readers ignore JavaScript, so a toggle would never run","why":"Screen readers run in ordinary browsers with JavaScript enabled. The problem with a separate mode is maintenance and quality, not script support."}],"answer":1}],"exercise":null,"words":689,"readMinutes":3}