6 Questions for Eric Eggert
by @yatil@yatil.social and @j9t@mas.to (@frontenddogma@mas.to) on , tagged interviews, accessibility, eaa, legal (toot this?)
Eric Eggert is a long-time specialist in web accessibility. Before the COVID-19 pandemic, he was a speaker at conferences in Europe and the U.S. Between 2013 and 2020, he worked at the World Wide Web Consortium (W3C) as part of the Web Accessibility Initiative (WAI). There he contributed to educational information about the Web Content Accessibility Guidelines 2 (WCAG 2), mostly the Quick Reference and the Web Accessibility Tutorials for developers. He also implemented the latest WAI redesign. In addition, he has a blog and a newsletter. His work is supported by gracious Steady memberships. Eric works with his life companion Sandra in northern Rhineland-Palatinate, their small consultancy Outline works on various accessibility-related projects, for example the German translation of WCAG 2.1. His main social media is Mastodon, where you can find him at @yatil@yatil.social.
Jens: Hi Eric, nice to welcome you here! What are you working on these days?
Eric: Since 2021, I work with Axess Lab for clients of all shapes and sizes to prepare them for accessibility requirements. Typically, I spend about 60% on accessibility testing and 40% on accessibility education, but of course, there are fluid boundaries between these things.
For me, generally, any touchpoint with a client, be that a sales email, a report, a meeting, or a training, is an education opportunity. There are always ways to inform people why we are doing what we are doing, and why they should be doing what we require from them. For example, many of our clients have heard of screen readers—undoubtedly, one of the most important assistive technologies—but are often unaware that websites and applications need to support much broader needs than “just” screen reader users. In this case, I point them to the excellent WAI resource How People With Disabilities Use the Web, which has recently been enhanced with videos.
Jens: What led you into the field of accessibility?
Eric: I’m a frontend web developer, and I learned the craft in the early 2000s when we just called it web design. Because of the limitation of dial-up Internet access, I printed out A List Apart articles while online and read them offline. I immediately became interested in standards and what they are supposed to do. It helped that we got new CSS tricks every other week that kept us entertained, even if many were techniques to make up for browser’s limited implementations.
Accessibility always played a role in standards circles, and when I moved to Vienna, Austria, to study, I organized a small meetup called WebMontag where I met Shadi Abou-Zahra who worked for W3C/WAI back then. From there, I quickly became part of the great Accessible Media bubble, a cross-disability initiative for accessible technology.
Growing up as a child with asthma, I also lived with a disability for some time. I used to think that those experiences hadn’t influenced me a lot, but recently, I can see that they did: I vividly remember that a neighbor in my age group had to go to a different school because he was a wheelchair user. I had trouble getting up the stairs sometimes because of asthma, but with the right accommodations, my participation in regular school was no problem. For example, I was allowed to stay in the upstairs classroom during the main pollen season. For my neighbor, the only accommodation was going to a school far away, which made everything in his life more complicated.
I found that unjust as a child, and I want to think that the experience sharpened my sense to recognize unjust, and especially ableist, behavior as an adult.
Jens: What excites you the most about your work?
Eric: Accessibility enables users to use a product like everyone else. My job is to ensure basic human rights, rights that are violated every day. And while I’m passionate about ensuring human rights, my day-to-day work sometimes has the glamour of clearing out a garage. There is nothing particularly exciting about telling the 200th person that their alternative texts are bad or that they need to add skip links, and maybe, please, stop putting <button> elements inside <a> elements.
The rewarding moments excite me, like when you notice that a client has done their research, or understood the requirements well, or when they go beyond the minimum. Teaching is the most inspiring aspect of my work, which is why I try to educate in any interaction I have with clients. In addition, setting up students who are new to accessibility and the Web with the needed background, to make the right decisions in the future, is always great.
Jens: What development in accessibility do you find most positive these days? What are you most concerned about?
Eric: Accessibility has never been easier to learn about and implement, so much that was a hassle just a few years ago is now easy. Take dialogs, for example. In the past, you had to build your own dialog, using generic HTML elements and ARIA (Accessible Rich Internet Applications) attributes and roles and implement the keyboard navigation correctly, to make a dialog accessible. Now, we can use the native <dialog> element, and it brings all the default accessibility features you would want if you invoke it with showModal().
As for concerns: So many people work in abstraction layers on the Web. Your React, your Tailwinds, and whatever the latest technology often limit making use of the good, sensible defaults of the web platform. Remember, any new feature of the web platform goes through an accessibility review, so it is as accessible as it can be.
The other concern is “generative AI” as a replacement for baking accessibility into solutions. Yes, image recognition can be a good last-resort technology, but it can never replace the intentional, situational alternative text that the author of a document can provide. And yet, some people think this is sufficient, but it mostly shows the disregard towards the needs of disabled people.
Jens: In Europe, due to the European Accessibility Act (EAA), accessibility gets some renewed attention. What’s your take on the EAA, and how people are responding to it?
Eric: The EAA is the first time that accessibility requirements are legally binding for private companies selling products and services on the Web to consumers. This is important because there used to be limited ways as a disabled consumer to ensure that a service worked for you.
The current legislation is relatively limited (you have to have a certain minimum revenue to fall under it, for example, and it mostly applies to ecommerce), but it will encourage better websites and apps overall.
As with GDPR (General Data Protection Regulation), companies try to hold out and do the least they can get away with. That’s obviously not a winning strategy, and some players, especially the big ones, seem to be working on their accessibility. Unfortunately, that often means addressing issues that could have been avoided with better planning and more knowledge about accessibility during the whole process.
One large ecommerce provider I work with struggles through their adaption to accessibility because there are certain interaction models that are just difficult to make accessible. But because the planning and design has already happened, it is difficult for the organization to go back and design them in an accessible way from the ground up. Even when that approach would be cheaper, quicker, and qualitatively better.
Most who will be affected by the EAA will be surprised that just telling the engineering team to make it accessible did not, in fact, make it magically accessible.
The good thing about the EAA is that it is based on the same foundations that have existed since the Web Content Accessibility Guidelines 2.0 (WCAG) were released in 2008. And while there are some additional requirements, anyone who has learned about accessibility in the past 15 years can put their knowledge to use.
Jens: If frontend developers could change one thing about their work, what would it be?
Eric: Listen to disabled people and how they use their technologies. Understand why it is important to strive for solutions that are not only baseline accessible, but robust and delightful. And try to reduce the abstraction that you work with. Maybe that’s not possible in your regular work, but perhaps there is a side project that is a training ground for exploring native APIs and web platform technologies. It was never that easy to make fun, beautiful, engaging content that is accessible and performs well.
Jens: Let’s hope many peers heed this advice! Thank you for your time, Eric!