Over seventeen lessons you have repaired Ticketly one slice at a time. An audit is how you prove the whole thing works, and how you find what slipped between the slices. Then comes the harder problem: keeping it that way when five developers, two designers and a marketing team change it every week.
\nW3C’s evaluation methodology, WCAG-EM, gives the shape. Here it is applied to Ticketly:
\nA first audit of a real product often lists dozens or hundreds of issues. Rank them by what they do to people:
\nThen weight by traffic and flow: a serious issue in checkout outranks a moderate one on the careers page. Fixing ten critical issues in the booking flow does more for disabled customers than fixing a hundred minor ones elsewhere.
\n\nAudits find problems after they are built. Lasting accessibility comes from catching them at every stage, at the point where they are cheapest to fix.
\nDesign. Annotate designs with the information developers can’t see in a picture: the heading structure, landmarks, focus order, accessible names for icon buttons, error messages, what moves and its reduced-motion alternative. Verify colour tokens against contrast ratios once, so every screen inherits them. Design focus and error states, not just default and hover.
\nComponents. A shared component library is the biggest lever you have. If the Dialog, Tabs, Button and TextField components are accessible, every feature built from them starts accessible, and a fix in one place fixes everything.
Development. Lint with eslint-plugin-jsx-a11y, run axe in component and end-to-end tests, and make a two-minute keyboard check part of every pull request. Locating elements by role and name in tests, as Playwright and Testing Library encourage, keeps names honest.
QA and definition of done. A story isn’t done until it works with a keyboard and has been checked with one screen reader. Accessibility bugs go in the normal backlog with normal severities; a separate list tends to become the list nobody schedules.
\nContent and procurement. Editors write alt text and plain-language copy; train them, and give the CMS a required alt field. When you buy third-party widgets such as a payment form or a chat tool, ask for an Accessibility Conformance Report and test it yourself, because their barriers become yours.
\n\nTicketly now has landmarks and a heading outline, real buttons and links, labelled forms with announced errors, considered alt text and a proper pricing table. It works from the keyboard with a skip link and visible focus, has a native booking dialog, ARIA tabs and live status messages, passes contrast, reflows at 400% zoom, respects reduced motion, names every control and pronounces its Arabic correctly. Most importantly, it has axe in CI and a team that checks with a keyboard before merging.
\nSamir booked his tickets for Harbour Lights himself this year, in under two minutes, without phoning anyone. That is the whole point.
\n","toc":[{"id":"sec-1","text":"A structured audit","level":2},{"id":"sec-2","text":"Prioritising what you find","level":2},{"id":"sec-3","text":"Building it into the team","level":2},{"id":"sec-4","text":"Where Ticketly ended up","level":2}],"takeaways":["An audit has a defined scope and target, a representative sample including complete flows, automated plus manual testing, and a prioritised report.","Prioritise by impact on real tasks; a blocker in checkout outranks a dozen minor issues on the About page.","Accessibility lasts when it is part of every stage, from design annotations and accessible components to lint rules, CI scans and a definition of done.","Accessibility bugs are bugs; keep them in the normal backlog with normal severities, not in a separate list that never gets scheduled."],"further":[{"title":"W3C WAI: WCAG-EM Overview (Website Accessibility Conformance Evaluation Methodology)","url":"https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/"},{"title":"W3C WAI: Planning and Managing Web Accessibility","url":"https://www.w3.org/WAI/planning-and-managing/"},{"title":"W3C WAI: Developing an Accessibility Statement","url":"https://www.w3.org/WAI/planning/statements/"}],"quiz":[{"q":"Your audit of Ticketly found 60 issues and you have one sprint. Which should be fixed first?
","options":[{"text":"The 30 low-contrast footer links, because they are the most numerous","why":"Volume isn’t impact. Footer links are rarely the reason someone can’t buy a ticket."},{"text":"Whatever axe reported, because automated findings are the most objective","why":"Some of the most serious problems, like a focus trap in checkout, are never reported by axe. Prioritise by impact, not by source."},{"text":"Issues on the About page, because they are easiest and show quick progress","why":"Quick wins have a place, but leaving checkout broken means disabled customers still can’t complete a purchase."},{"text":"The unlabelled card number field and the keyboard trap in the payment dialog, because they block purchases","why":"Correct. Blockers in the most important flows come first; they stop people from completing the task at all."}],"answer":3},{"q":"Why should an audit sample include complete processes, such as the whole booking flow, and not only individual pages?
","options":[{"text":"Because WCAG conformance requires every page in a process to conform, and failures often appear between steps","why":"Correct. WCAG’s conformance requirements cover complete processes, and focus handling, error recovery and redundant entry only show up when you move through them."},{"text":"Because automated tools can only scan multi-page flows","why":"Automated tools scan individual pages and states. Flows matter because of what a person experiences between steps."},{"text":"Because single pages are always accessible","why":"Single pages fail all the time. The point is that testing pages alone misses problems that only appear across a flow."}],"answer":0},{"q":"Which practice does the most to keep Ticketly accessible as new features ship?
","options":[{"text":"A full external audit every two years","why":"Audits are valuable checkpoints, but two years of unchecked changes will reintroduce most of the problems."},{"text":"Accessibility in the definition of done, with accessible shared components, axe in CI and a keyboard check before merging","why":"Correct. When every feature passes through the same gates, accessibility is maintained continuously instead of repaired periodically."},{"text":"A separate “accessibility backlog” reviewed at the end of each quarter","why":"A separate backlog signals that these are optional extras and tends to be deprioritised. Accessibility bugs belong in the normal backlog."}],"answer":1}],"exercise":{"kind":"order","items":["scope","sample","automated","keyboard","screen-reader","visual-content","report","retest"],"title":"Plan Ticketly's audit","prompt":"You have been asked to audit Ticketly against WCAG 2.2 AA before the festival’s ticket launch. Put the audit steps in the order you would carry them out.
\n","hints":["You can’t choose pages until you know what you are auditing against and which flows matter.","Do the cheap, fast automated checks before the slower manual passes, so the manual testers aren’t distracted by missing labels.","Testing ends with a sweep of the visual and content checks the tool and the two passes don’t cover. The report comes after all testing, and the work isn’t finished until fixes are retested."],"explanation":"An audit starts by fixing its scope and target, so everyone agrees what “done” means. The sample then picks representative pages and complete flows. Automated scans come first among the tests because they are fast and clear away the obvious problems. The keyboard pass precedes the screen reader pass because keyboard failures (unreachable controls, traps) block screen reader testing too. Visual and content checks cover what neither tool reveals. The report prioritises by impact, and the cycle closes with fixes, a retest of the same flows and an updated accessibility statement.
\n","checkLabels":{},"itemText":{"scope":"Agree the scope and target: WCAG 2.2 AA, the browsers and assistive technologies, and the key flows","sample":"Choose a sample: home, event page, checkout and account pages, plus the complete booking flow","automated":"Run axe on every sampled page and state, including open dialogs and form errors","keyboard":"Do a keyboard pass through every flow: reach, see, operate, escape","screen-reader":"Repeat the flows with NVDA and Chrome, VoiceOver and Safari, and VoiceOver on iOS","visual-content":"Check 400% zoom, text spacing, reduced motion, alt text quality, headings and language","report":"Write findings with location, WCAG criterion, severity and fix, and prioritise blockers in key flows","retest":"Fix the issues, retest the same flows and update the accessibility statement"}},"words":895,"readMinutes":4}