GAAD 2025

Published May 18, 2025 by Maureen Holland

This past Thursday marked the 14th annual Global Accessibility Awareness Day (GAAD). In honour of the event, London Web Standards held a series of accessibility-focused talks at the University of Greenwich.

All three talks are available their fully captioned and transcripted glory on YouTube if you'd prefer to jump over there. If you want a text recap, read on!

Web accessibility, in terms and tools you already know, Matthew Atkinson

Matthew gave a wonderful introduction to the accessibility tree, a subset of the document object model (DOM) with information that is useful to assistive technology (AT). Using dev tools, we can inspect an element (i.e. a form field) and see the following information:

Name
Description
Role
State

If you’re new to web accessibility, ensuring interactive controls are properly named is a great place to start. Having empty or duplicate names is a terrible user experience. How else would you know what form field you’re filling or button you’re clicking? If a distinctive visible text label is not possible, you can use aria-labelledby with multiple ids to provide a unique name (be mindful of order of precedence when using this technique).

Another useful starting point is to check your landmarks. This is something you can do with a screen reader (using rotor command or element list). Matthew also has a Landmarks browser extension. This check improves navigability of the DOM and serves as a reminder that certain elements can be pulled out of context (so their names need to make sense independent of their surrounding content). Note: multiple links named “click here” would fail this check.

Shift left on accessibility, Geri Reid

Geri shared an “Accessibility Cycle of Sadness” flow diagram, annotated with the costs of accessibility fixes at particular steps.

An illustrated flow diagram called 'Accessibility Cycle of Sadness' starts with Plan, then Design, Build (with approximately $350 cost to fix accessibility issue at this stage), QA ($450 cost), Release, Audit ($800 cost), Accessibility Issues, Bug Tickets, and back to Design and Build.

Unsurprisingly, the longer you wait to assess and address accessibility, the higher the cost of fixing issues. But the real sadness part of this cycle is that it puts a great deal of pressure on the accessibility person or team in your organization. Being siloed and only brought in at the last minute to answer the question, “Is this accessible?” will ruin everyone’s day.

It’s not accessibility that slows you down.
It’s surprise accessibility.

The key to avoiding surprise accessibility is to plan for it. Front-load product and design discussions with questions about it. How might this affect people with accessibility needs? What don’t we know? Build in time for research and investigations. Use a resource like atomica11y to bake accessibility into your definition of done. Annotate your designs with accessibility information. Ask the following questions before development:

What happens with zoom or font size increase?
How does it work with no mouse?
What happens when I interact?
What if I prefer reduced motion?
How would a screen reader announce this?

This approach of “shifting left” will look different for every organization. But the outcome should be the same: more accessible products shipping on time and on budget.

The problem with ‘pixel perfect’ design, Craig Abbott

Craig gave a quick breakdown of the history of pixel-based design and the differences between physical, digital, and CSS pixels. He made a compelling case for why “pixel perfect” design is not suited to modern web design. Ultimately, it’s an attempt to assert too much author control over a medium designed for user control.

User preferences are not static.

Users may choose to zoom. But zoom doesn’t persist across websites and makes everything bigger. To allow chosen font sizes that persist across the web, browsers give users a font size setting. No user has ever preferred a “pixel perfect” designed site over their own settings.

Because we don’t know what the user’s font size will ultimately be, we need to let go of exact pixel measurements and embrace a systematic approach, where sizes scale proportionally to any base font size. Scales produce harmony. This is as true in music as it is in visual design. Designing in systems allows us to be responsive to user preferences in addition to providing consistent CSS rules that save developer time and sanity.

Closing comments

An attendee made two important points as the event was wrapping up:

There’s no substitute for lived experience. Testing with screen readers is great but testing with screen reader users is better.
An accessibility statement on a web page should always include a feedback mechanism. It should be easy to report an accessibility issue.