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

,

, and

in my day to day work. I assumed that meaningful or semantic HTML is a commonly known best practice, and not following it is against the industry best practice.

I also understood that it was important to label things for search engine optimization purposes. Many of my previous project success metrics were, after all, reliant on a lot of SEO statistics. But perceived best practices and SEO simply weren't good enough reason to spend developers and testers valuable time.

A lot of these major template rework needed to be done in authenticated experiences, where a user need to be logged in to see the content. Which means these pages shouldn't come up in a search engine in the first place. So the SEO argument kind of fell flat on its face.

As for following the industry's best practice, there are just that: best practices. A guideline of what good looks like, but no real value to the user.

So to most people on my team asking to rework an existing functioning template with semantic HTML was a bit like a developer's vanity project. But that did make me wonder. Was there another reason why semantic HTML is the best practice.

I realized that I didn't know HTML as deeply as I thought I did since I just couldn't explain why it was so important. All I had were actually questions that needed answers. Like:

Why should I put alt text on some images, and none on others? How do I even write a useful one anyway?

What is the difference between

to

? Why do we need HTML headings when you can actually just style anything to look like headings?

The nav HTML element doesn't at all seem beneficial to SEO. So what is it actually for other than code readability?

Why is link with empty # or href so bad? Doing this was actually the best practice, according to the documentation for Salesforce platform that I was working on.

Stumbling upon screen readers, and disabilities

As I searched for reasons to justify the semantic markup improvements, I actually found screen readers.

I was vaguely aware that screen readers exist and that people use them. But I never stopped to think about how screen readers actually work, and the needs of its users.

Because I was simply trying to understand the purpose of HTML. I settled with very basic understanding of screen reader.

At the time understood that screen readers were software that blind people use to use their devices, screen readers, read text on the screen. And that is why you need to provide alternative text to describe images using alt tag. Screen readers just weren't smart enough to read images without manually providing alternative description attached to an HTML image.

I learned that semantic HTML gave additional context and purpose to the page for screen reader. The way designers use some visuals to communicate purpose of specific types of UI for sighted users.

I was vaguely aware that screen reader users know they're onto a new section or group of content, or perhaps even sub content, via the use of

to

HTML tags, and
HTML5 tag. Screen readers don't care if you start a
tag as a heading, as it focuses on HTML, not CSS.

So now it does seem a lot more obvious to me why the new semantic HTML tags exist.

Take for example, how does a blind person knows that a list of links is actually the site's global navigation, and not simply just a part of the page content?
HTML5 tag actually helps with that.

So how does a screen reader user know if clicking on something would actually take them to a page, versus interacting with something on the page?

Well, link tag was actually designed for linking related contents, and

Share Episode

Shownotes

Transcripts

Follow

Chapters

Video

More from YouTube