Artwork for podcast Web Access Club
Discovering web accessibility
Episode 129th August 2022 • Web Access Club • Prae Songprasit
00:00:00 00:17:42

Share Episode


Web creators’ first encounter with accessibility is often at work; be it through a project, discussions, or during research.

In this episode, I share how I discovered the world of web accessibility, what I learnt along the way, and why I wanted to learn more about it.


  • 00:00 - Intro
  • 01:29 - Working as a front-end developer
  • 04:11 - Learning to code for keyboard interaction
  • 06:18 - Looking for reasons for semantic HTML
  • 09:06 - Stumbling upon screen readers, and disabilities
  • 11:42 - Failing at advocacy
  • 14:30 - A chance to understand more about disabled users
  • 17:26 - Credits and outro

Links to resources mentioned in the episode:

Transcript for this episode.


You can follow this show on Twitter, Facebook, Instagram, and Youtube.

Each episode, show notes, and transcripts are available on

Support this show, and help me pay the bills on Buy me a coffee.


Sawasdee-ka, kia ora and hello.

Welcome to Web Access Club, a podcast about accessibility for web creators. I'm Prae, a New Zealand based UX engineer, who is learning to make accessible web products.

In this episode, I'm going to share how I kind of slid into the world of web accessibility.

I only started openly advocating for making accessible web experiences at work a few years ago.

When I speak to someone about my work these days, I was often asked:

"How did you get into web accessibility?"

And here's my problem. I can't pinpoint the exact moment I stepped in. So I've never been able to give an answer that I was happy with.

My answers usually falls along the lines of "I kind of just did" or that "well, it's a natural part of front-end practice, I guess".

For many web creators I know, their first experience with web accessibility is actually through some accessibility project, where the product they're working on needed to be made compliant with the web access content guideline, or the WCAG in short.

But I was already on the journey when I started my first accessibility project at work. So I had to think back a little further.

After retracing my steps. I think I became more aware of accessibility during my third year of web development career.

Working as a front-end developer

At the time, I was a front-end web developer working in a digital agency that focuses on UX and service design. My agency has a small in-house development team that maintains some sites for long term clients.

My day to day work normally included coding up designs and maintaining responsive websites with HTML, CSS, and a little bit of JavaScript.

I'll then work with back-end developers to integrate those template files with our customer's content management systems, known as a CMS.

What energized me about front-end web development, was turning a designer's vision into the best possible user experience it could be in practice.

I was always joking that my job was actually resizing the browser and testing sites on five devices on a good day, or on eight devices on a bad one. Though in all seriousness, there's a reason why I had to do it. Those designs do need to work in as many places as possible. A designer sets the direction, but I'm the one who's responsible for the final experience that our customers get.

I loved having that level of ownership, and collaboration, and trust with our designers. But occasionally I'll be involved in the UX research in the capacity of a note taker at a user interview, or I even ran some prototype usability sessions myself.

Seeing how people interact with designs and understanding their context, was one of the most interesting things about my job. It gave me a mental model of how users interact with my interfaces, and it really changed the way I code up designs.

For example, I noticed that a user was struggling to tap on the navigational links in the prototype. I realized that the hit area was actually smaller than their fingertips. So I learned to create visual space between those links using CSS padding around links instead of the margin.

Using padding increases the links hit area without actually changing the visual design. So that is a different way of achieving the same design, but also improving the user experience.

I became particularly careful about some types of layouts and interactions, because of all these UX research sessions that I was involved with.

I believe it helped me become a better developer and in hindsight, I was already learning to improve accessibility of my code. Even though mentally, I was mainly focusing on touch devices, and variety of viewport sizes.

Learning to code for keyboard interaction

Then I was put on a project which added yet another dimension to my practice.

In this project my team was responsible for designing an internal tool for a client. As a part of the delivery package, we will also to start a design system for them. This internal tool was a web app with loads of form fields, and it was more interactive than anything I've done up until that point.

In the past users for this app had to complete their task with the old school command line interface.

It was hoped that the new uI will be way more user friendly, help reduce errors, and it's easier to onboard new staff onto the tool. We realized pretty quickly. That in order for existing users to navigate the new app, as efficiently as the old one, it needs to work with a keyboard.

A lot of my energies went into really understanding how to interact with basic form fields, using a keyboard. I also learned how to code out keyboard accessible versions of custom form elements that our designers came up with.

CSS Tricks, Mozilla Developer Vetwork and Smashing Magazine websites were permanently up on my screen. And my appreciation for pattern libraries and design systems grew from there.

Unfortunately, we were an agency. Projects run on a fixed time and budget. It was clear that a project like creating a design system needs to be done iteratively and in-house, I decided that I want to be allowed to craft these systems and experiences, and left my last company to join a product company.

In the new team that I joined, they still kind of operated like an agency inside a company, and maintained a somewhat interactive website. We focused on shipping new features for internal stakeholders because the site was pretty new at the time.

So even though I got more ownership and time, it wasn't realistic for me to create design systems or throw myself at optimizing for micro interactions. It simply wasn't my team's priority.

Looking for reasons for semantic HTML

But, oh my goodness. There were so many

and everywhere and rarely a semantic HTML in sight. I focused on sneaking in little improvements into the HTML templates where possible, but some improvements does require significant changes to the template and the way the data was displayed.

Since I'm now working with a bigger and more formal team who hasn't worked with a front-end developer before. I needed to justify why those improvements were important.

By that time I was already using semantic HTML5, like