(Part 1) In Conversation with Becky Gibson, ARIA MVP

You might know Becky Gibson’s name from her work building the foundation of Accessible Rich Internet Applications (ARIA), or maybe it’s because she partnered with W3C and contributed multiple techniques to WCAG 2. Perhaps you’ve seen her speak, teach, or train with Knowbility. If you’ve met her at CSUN, you know she’s passionate about making Web and mobile applications usable for people of all abilities.

Bottom line: If your path has crossed hers, you know what a powerhouse she is. With 30 years of diverse experience in corporate and open-source development, Becky has dedicated half of her career to results-oriented Web Accessibility evangelism that has impacted products, customer strategies, and industry standards.

And if you don’t know Becky, you’re in luck. Evinced sat down with her to discuss how ARIA came to be, the evolution of digital accessibility, what she would have done differently in the past 20 years in tech, and what’s in store for the future. We hope you enjoy our conversation as much as we did. This is part one, please find part two here.

There are many roles people embody in the digital accessibility space. Please introduce yourself and describe your role(s) and relationship with digital accessibility. 

I’ve been working full-time on accessibility since 2004, but it took a little while to get there. 

For the majority of my career, software engineering is what I did. First, I owned the print system for Lotus 123, and then Lotus was acquired by IBM. When IBM started requiring their projects to be accessible in the early 2000s, I learned about accessibility. There was a group at IBM called Emerging Technologies with an accessibility niche, which I joined in 2004. 

While working with Emerging Technologies, I partnered with two colleagues, Rich Schwerdtfeger, and Aaron Leventhal, to make JavaScript accessible, and our work became the foundation for Accessible Rich Internet Applications (ARIA). I became an evangelist for making websites accessible, sharing what we had learned and developed with internal teams at IBM and industry events, such as CSUN. Later, at IBM, I worked as the accessibility lead on the acquisition team before moving on to accessibility roles at other tech companies. 

In the early and mid-2000s, I also worked with the World Wide Web Consortium (3C) Web Accessibility Initiative (WAI) as a developer and wrote techniques included in the Web Content Accessibility Guidelines (WCAG) 2.0. I’ve consulted start-ups on accessibility and worked with Knowbility on accessibility standards and education. 

As a founding collaborator and evangelist for ARIA, can you please share what working on such groundbreaking technology was like? 

The Web as we know it today started to emerge in 2004; people were beginning to use scripting and JavaScript to make websites more interactive.

The problem was that screen readers didn’t understand any of that JavaScript, so people using screen readers couldn’t access those pages. The screen reader didn’t know there was a tab panel or a really cool drop-down instead of a standard select. So a colleague, Rich Schwerdtfeger, suggested we figure out how to add more of these properties into HTML to get screen readers and browsers to understand them. That was really the beginning of Accessible Rich Internet Applications (ARIA).

Meanwhile, another IBM colleague, Aaron Leventhal, was working on Firefox and accessibility. So the three of us went through this exercise together – how do we make a tab Control? How do we make a tree control, and what kind of roles, properties, and states do we need? 

We then went out with a prototype, collaborating with a now-defunct screen reader company, to test what we called dynamic HTML (DHTML) accessibility. When it showed signs of success, we started evangelizing it internally with IBM teams interested in incorporating DHTML accessibility into their project, and we went to CSUN to share with the greater community. 

During this time, I also started working with the Web Accessibility Initiative (WAI) within the W3C. I joined the working group tasked with writing the Web Content Accessibility Guidelines. Some of the techniques I wrote are included in the WCAG 2.0. 

Back to ARIA – Rich, Aaron, and I wanted to make this technology ubiquitous; we wanted to share it. So Rich convinced IBM to give DHTML accessibility open source for the W3C. He and Aaron joined the W3C working group, which renamed DHTML accessibility to ARIA. I was still partnering with the W3C as a developer but was working on more front-end development with the WCAG group. 

That’s really how ARIA came to be. There was an accessibility initiative from IBM, and then Aaron, Rich, and myself worked to figure it out before sharing it with the world. 

Digital accessibility is a newer term and one we find ourselves explaining frequently. How would you define digital accessibility?

It’s just providing access to everyone. We should get access to all people and be aware that everybody is unique on the Web. We must understand the various technologies that people use to access it. 

Accessibility tends to focus on blindness because that touches on so many accessibility issues. Blindness impacts keyboard controls, has extra speaking points, and uses ARIA. 

Still, accessibility is not necessarily making accommodations but designing for usage through various senses. Creating an accessible digital experience means including everyone based on the senses, whether it’s touch on mobile for people with hand tremors, solutions for Deaf and hard of hearing, or text-to-speech or speech-to-text for those that need it. 

What influenced you to pursue work in the digital accessibility space?

I was working on business software for IBM when the opportunity presented itself. It meant changing my team and work environment – my new team would be completely virtual and based in different offices.  

What pushed me was being honest with myself and acknowledging that I wasn’t interested in building email or spreadsheet software. I wanted to do something that affected people more and had a personal quality. It was more rewarding to do something that helped people who are disadvantaged in our society through no fault of their own. 

That motivated me to take that step out of my comfort zone.

The arrival of mobile products forced accessibility to evolve to meet users on smartphones, tablets, and other devices. What can you share about that evolution from a tech aspect?

While I didn’t work on many initiatives for mobile accessibility, I worked on a product called PhoneGap, now known as Apache Cordova. The issue was that people didn’t want to build for both Web and mobile platforms, so this idea of hybrid apps came up. 

With hybrid apps, developers can write most of the app in web technologies, but there’s a gap between what the web technology can do and the content stored on the mobile device. A start-up called PhoneGap developed a way to write libraries that could be built and compiled into application code, which then had access to the device settings. So, when I worked with PhoneGap, I included accessibility in the development.

But Apple did and is doing great work to make technology accessible. I still believe iOS is the more popular mobile platform because it is so accessible. It has been just a big, huge boon. You know, an innovation that helps everyone also helps people with disabilities. I remember going to CSUN, and a company was showing these big boxes that you could bring along to give you directions while you were walking on the street right. Now, folks can do that with their phones. And you don’t have to see it – your phone will tell you the directions. Not only did mobile open up opportunities for people with disabilities but also for people who couldn’t afford a whole computer. Today, so many services come through the phone interface. 

Unfortunately, companies still don’t make their apps accessible, nor their websites.

Why don’t companies incorporate accessibility into their apps and websites? 

The biggest issue is that people don’t know what they don’t know. My pet peeve is the lack of awareness, and what I’m trying to get involved in now is bringing accessibility into our education system. 

For example, people might know what screen readers are, but they still need to learn how people use them. They just haven’t been exposed to it. You know, in college and school, students learn programming. All these boot camps teach web development, but they don’t include accessibility. They don’t even have the basics you can do with HTML, like putting a label on your form element. They don’t even talk generally about accessibility. That’s where the biggest issue is: people don’t know. 

And then, when they do know about accessibility, often they aren’t given adequate time to get it right. I’ve seen it at many companies – developers going for quick fixes or thinking they can drop ARIA into the code, which will magically give them complete keyboard support. It doesn’t work that way, and we have to start the conversation sooner and on broader terms.

Does the lack of information come from a more fundamental level, perhaps that sometimes developers don’t understand HTML semantics? Maybe HTML has been abused by different people working on the same project for years.

Oh yeah, that’s <div> soup, right? Everyone starts with a <div>. Often developers will make the code do what they want it to using CSS or toolkits. But these end up being add-ons, incomplete solutions. When accessibility isn’t included from the beginning, you must constantly go in and make changes. A lack of awareness makes for extra work in the end. 

Have you noticed a shift in perception, attitude, and knowledge among dev teams regarding accessibility? When handed accessibility tasks; some developers embrace the challenge, some push back.

Some definitely embrace it. It’s a challenge, right? That’s what I always thought – to me, developing was like puzzles. 

But I remember when I was working at IBM, somebody said, “Becky, why do we have to do all this extra work? I mean, there really aren’t that many people that have a disability. So why are we taking all this extra time and effort to make it work for just a few people?”

It was like banging my head against the wall. Because what I always think is, “what if this was you? What if you lost your vision? What are you going to do if you can’t see the screen?”

So, one thing I do when speaking about accessibility is get a demo from a native screen reader user. I want the audience to see the speed at which a screen reader user typically navigates the internet. That helps people understand there are real people behind these projects. The point isn’t to make developers feel pity for people with disabilities but respect. It’s not like you’re trying to build empathy. You’re trying to build understanding. I want developers to think, “I can make a difference in these people’s lives by doing the right thing.”

—

Continue the conversation and read part two of our interview here.