a11yConf Girona 2025: A First-Hand Account

Truly designing with people in mind means that when someone needs help in an auditorium, they don’t have to stand up, search for a volunteer, or interrupt a talk. It means they can bring their phone close to an NFC tag on their chair, discreetly request assistance, and receive help in less than a minute. It means credentials include relief and braille, not as a last-minute addition, but as a natural part of the design. It means guide dogs have their space and no one is surprised by their presence.

This past weekend, the 2025 edition of a11yConf took place in Girona, an event that brought together development professionals, designers, people with disabilities, and companies to discuss accessibility from real experience. Beyond the legislative framework of the EAA or the technical implementations of ARIA, events like these demonstrate that accessibility is not an audit checklist: it’s a different way of understanding development, design, and technology.

An Event That Practices What It Preaches

Upon arriving at the Parc Científic i Tecnològic de la Universitat de Girona, you immediately notice this is different. The care for accessibility is evident in every detail:

• The event title itself included relief and braille
• Credentials also had relief to easily locate the QR code and each attendee’s information
• Several guide dogs accompanied their people, establishing the inclusive atmosphere from the start

But there was something that particularly fascinated me: every seat in the auditorium had NFC tags. Each tag linked to a web application from which any attendee could discreetly request assistance, and the volunteer team would arrive immediately.

This use of NFC for accessibility opens up a world of possibilities we should explore in other contexts: imagine bank branches, university campuses, or retail stores where anyone can request personalized assistance from their location without having to move, search for staff, or explain their needs out loud.

The technology was there, but seeing it applied so elegantly and functionally was a revelation.

The Keynotes That Define the State of Accessibility

There are two conversations every company should be having right now about accessibility: what the law says and what we should demand from design before writing a single line of code. The two opening keynotes addressed precisely these topics, and both made it clear that we keep making the same mistakes: thinking that accessibility is a technical problem solved at the end of the project.

EAA: When Legislation Is Explained Well

Olga Carreras’ keynote on the EAA (European Accessibility Act) was, without exaggeration, one of the best talks of the day. Olga has the gift of turning a dry topic like legislation into something understandable, practical, and even entertaining.

She spoke about:

• Laws affecting digital accessibility
• The famous EAA and its transposition process into national legislations
• Products and services affected by the regulation
• Deadlines and obligations companies must meet

“That a talk on legislation turns out so engaging says a lot about the speaker’s quality”

It’s a talk that deserves a complete review once Sirviendo Código publishes it. Special mention also goes to her book on web accessibility and WCAG 2.2, an essential reference for any professional in the field.

Design as a Pillar of Accessibility

The second keynote, “Beyond the Code. Design Decisions That Make the Difference” by Berta Nicolau, was a profound reflection on design’s role in building accessible products.

The central message: accessibility challenges must be identified from the earliest phases of the project, and design needs to exhaustively document these scenarios before they reach development.

Problems aren’t born in the code.

This phrase perfectly summarizes reality. As developers, we tend to think that accessibility is solved by writing good HTML and adding ARIA attributes. But many barriers are already present in design decisions: insufficient contrasts, confusing visual hierarchies, interaction flows that don’t consider assistive technologies.

Technical Learning: When Theory Meets Reality

We can perfectly know the specifications of semantic HTML and have exhaustive documentation on ARIA. But until you see someone navigating with a screen reader through an interface you thought was correct, you don’t really understand where the problems are. The talks after the coffee break focused precisely there: on the gap between what developers believe works and what users actually experience.

Seeing Is Believing: Screen Readers in Action

“Chronicle of Incorrect Markup” reviewed fundamental concepts of semantic HTML and correct labeling. But the most valuable part was the live demonstration: watching Georgiana use a screen reader and understanding firsthand how a person with visual impairment navigates the web.

It’s something we should all experience at least once. It completely changes your perspective on what it means to create truly accessible interfaces. What for us is a simple button without a label, for a screen reader user is an insurmountable obstacle.

ARIA: The Sixth Sense of Accessibility

Mia Salazar’s talk, “I See ARIA Attributes,” was hilarious and tremendously instructive. Using The Sixth Sense as a narrative thread, she explained:

• Common myths about ARIA and when it’s really necessary
• Frequent implementation errors that worsen the experience
• Best practices and use cases where ARIA adds real value

If you’re interested in deepening your knowledge of ARIA, this talk is essential when it’s published.

NVDA for Developers: A Transformative Workshop

In the afternoon, I attended the workshop “NVDA for Developers: Listen to What Your Interface Hides,” conducted by José Manuel Delicado.

Precisely in October, we launched Orbitant’s public Knowledge Sharing sessions with a session on “Web Accessibility.” In it, we discussed the use of tools like NVDA and other assistive tools. It won’t be our last session, as our team is quite committed to accessibility in development.

However, seeing how José Manuel uses and explains NVDA from his experience as a real user is a completely different level. He showed us:

• Keyboard shortcuts and navigation flows that users actually use
• Common errors that an expert user immediately detects but go unnoticed in automated audits
• The abysmal difference between a “technically accessible” interface and a truly usable one

The most valuable part of the workshop were the direct conversations with accessibility experts:

• Understanding real challenges: talking with people with different degrees of visual impairment about their daily frustrations navigating the web makes you understand that we’re not talking about checkboxes in an audit, but real barriers that limit access to essential services.
• Validating technical decisions: as a software architect, I often make decisions about frameworks, components, and design patterns. Being able to contrast those decisions with real users of assistive technologies gives you a perspective that no article or documentation can offer.
• Identifying blind spots: discovering that solutions I considered “accessible” had problems that only an expert user would detect. For example, excessive use of ARIA that confuses more than it helps, or navigation structures that technically work but are exhausting to use.

These moments of direct conversation are what truly transform your way of working and make you understand why accessibility cannot be an optional task at the end of the sprint.

React Native: Accessibility Has Its Own Challenges

Juanjo Montiel and Víctor Borrego’s talk on React Native accessibility was revealing. Despite some technical setbacks, the content was exceptional.

I learned a great deal about:

• The proper use of accessibility roles and their differences between iOS and Android
• How native components handle accessibility differently from their web equivalents
• Critical points where it’s easy to create barriers without realizing it

As a developer with primarily web experience, I was surprised by how different—and sometimes more challenging—ensuring accessibility in React Native can be. Platform fragmentation, differences in how VoiceOver and TalkBack interpret roles, and the ecosystem’s lower maturity make it easier to end up with an inaccessible app.

If you work with React Native, this talk is essential when it becomes available.

Our Participation: Apogee and Accessibility in Internal Tools

The day closed with lightning talks, when we had the opportunity to present Apogee, the bot we’ve created at Orbitant for giving karma.

Apogee is a tool that allows us to foster a culture of recognition and collaboration in our team through a karma system that integrates accessibility from its conception.

Why were we chosen for these lightning talks of just 5 minutes? Because Apogee isn’t just a gamification tool: it’s an example of how accessibility should be present even in companies’ internal tools. The bot works perfectly with screen readers, has clear and descriptive commands, and its Slack interface is designed with our team’s diversity of abilities in mind.

The presentation was well received, and several members of the organization congratulated me afterward. Beyond the recognition, what was important was demonstrating that accessibility isn’t just for customer-facing products: it starts at home, in our own tools and processes.

a11yConf: The Event the Community Needed

I couldn’t attend all the talks (the event had parallel tracks with simultaneous content), but all the material will be published soon thanks to the excellent work of Sirviendo Código.

This edition of a11yConf has been a milestone for the accessibility community in Spain. A necessary space where professionals, people with disabilities, and committed companies could share knowledge, challenges, and solutions.

Thank you, a11yconf, for creating this space and allowing us to be part of it.