Auditing a Page and Building an Accessible Team

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.

A structured audit

W3C’s evaluation methodology, WCAG-EM, gives the shape. Here it is applied to Ticketly:

1. Scope and target. “Ticketly web app, WCAG 2.2 Level AA, latest Chrome, Firefox and Safari, NVDA and VoiceOver.” Writing it down stops the audit from sprawling, or from quietly skipping the hard parts.
2. Explore and sample. List the key flows: find an event, book tickets, pay, manage a booking. Choose representative pages, and include each complete process end to end. WCAG conformance covers whole processes, and many failures, like lost focus after a step or re-asking for the email address, only show up between pages.
3. Automated scan. Run axe on every sampled page and state: dialogs open, menus expanded, form errors showing, dark theme on. Fix or log the results; they are the cheap ones.
4. Keyboard pass. Every flow, without a mouse, using the checklist from Testing with a Keyboard and Screen Readers.
5. Screen reader pass. The same flows with NVDA and Chrome, VoiceOver and Safari, and VoiceOver on iOS for the mobile layout.
6. Visual and content checks. 400% zoom and 320px reflow, text spacing, non-text contrast, reduced motion, alt text quality, headings, link text, language of parts.
7. Report and prioritise. Each finding with its location, steps, WCAG criterion, severity and a suggested fix.
8. Fix and retest the same flows, then update the accessibility statement.

Prioritising what you find

A first audit of a real product often lists dozens or hundreds of issues. Rank them by what they do to people:

• Critical: blocks a key task for some users. An unlabelled card number field, a keyboard trap in the payment dialog, a CAPTCHA with no alternative.
• Serious: the task is possible but very hard. Missing headings on a long page, errors that aren’t announced.
• Moderate: friction and confusion. Vague link text, low contrast on secondary text.
• Minor: polish. A decorative icon announced as “graphic”.

Then 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.

Building it into the team

Audits find problems after they are built. Lasting accessibility comes from catching them at every stage, at the point where they are cheapest to fix.

Design. 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.

Components. 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.

Content 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.

Where Ticketly ended up

Ticketly 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.

Samir booked his tickets for Harbour Lights himself this year, in under two minutes, without phoning anyone. That is the whole point.