Discovering web accessibility

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.

Links to resources mentioned in the episode:

• CSS-Tricks
• Smashing Magazine
• Mozilla Developer Network (MDN)
• Web Content Accessibility Guidelines (WCAG) version 2.1
• Digital Accessibility Foundations by W3C

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 <div> and <span> 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 <nav>, <header>, and <aside> 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 <h1> to <h6>? 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 <h1> to <h6> HTML tags, and <section> HTML5 tag. Screen readers don't care if you start a <p> 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? <nav> 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, <a> link tag was actually designed for linking related contents, and <button> tag was designed for form submission and interaction within the page.

After all that reading, I started to recall that a senior front-end developer in my previous role was passionately adding aria labels to navigation menu.

At the time, it didn't occur to me why it was so important for her to do so. Now it started to dawn on me that she was making that menu much more screen reader friendly, when the standard HTML elements just weren't suitable for the job.

Failing at advocacy

Armed with this knowledge, I told my team that Hey, screen reader was the reason. They had no other reaction than "Ah okay, log a ticket and put it in our backlog, and we'll look at it at some point".

Looking back, I was naive and too new to advocacy. The way I was, I wouldn't have been able to convince anyone to prioritize the work. I didn't know enough about web accessibility and I wasn't able to weave together an impactful enough narrative, or tie together with any existing initiatives that we were already doing.

The way I was pitching it, I was telling my team that we're ignoring the blind community, that we need to do the right thing, the moral thing. But the reality is that we can't make software that works a hundred percent for everyone.

Companies and projects try to solve for as many use cases as possible, focusing on problems that impact a sizeable groups of users with a clear return on investment. Which is why, web creators have to live with knowing that our site or app won't look perfect in every device.

We published a list of supported devices, operating systems and browser, to help us triage issue when they come in. If we support the issue, then we fix it sooner. If we don't, they usually need to make a pretty compelling case for it to get prioritized.

By telling my team that they're ignoring the blind community, which is actually a small percentage even within the disability community, I'm setting that narrative up for failure. The task would never get prioritized this way. I'm effectively asking the team to prioritize this over more than 50% of our other uses that they're already aware of.

Did that make me want to scream and shake the sense into people?

Of course it did, but thank goodness that I didn't. Cuz vilifying teammates is the worst thing that I could have done to convince anyone to join my course.

So I resigned to learning more about disabilities alone. I still shared what I learned about accessibility during our knowledge sharing sessions when possible.

Afterwards, people would tell me that "oh, it's fascinating", something they'd "never thought of before, "thank you"

But then they wouldn't do anything about it. It was just business as usual.

After a while, I did manage together a couple of more front-enders around the cause, and we continued to make improvements wherever we could. But since we were kind of sneaking things in, the progress was quite slow and actually frustrating.

A chance to understand more about disabled users

As I was becoming discouraged, the management suddenly told us:

"Hey, we need to make our product accessible. It needs to be compliant with the web content accessibility guideline version 2.1 AA".

I was definitely too overjoyed that an accessibility project has landed in our lap. I was bouncing around completely oblivious to how my teammates were reacting. Later I would learn that this level of energy for something that people were unsure and scared of, actually puts them off more than actually getting their buy-in.

Luckily we had a more senior front-end developer who had experience working with WCAG before. They were asked to lead the analysis on the efforts that will be involved to get our product up to standards.

While someone else was working on the "how". I was searching for ways to get people and my team to learn more about accessibility: to help them understand the why, and to go beyond the compliance mindset.

In my search, I stumbled upon digital accessible foundations by W3C. It's a free 16 to 20 hours, self-paced online, that was designed to give non-technical and technical foundations for people to make digital technology accessible.

What I liked about this course was that it did a great job at introducing the why behind digital accessibility, and it provided visuals and descriptive overview of how people with disabilities use assistive technologies.

This was where I also learned that there were more assistive technologies than just screen readers. And that around one in five, or one in four depending on where you get your stats, live with some sort of disability. This number makes digital accessibility way more justifiable, than catering for just the blind uses.

Because UX has always been at the heart of how I approach coding. I wondered how can I understand disabled people better?

I felt that understanding more about the users will help me cater for their needs. Like the way I understood and automatically catered for sighted users who uses touch devices.

I suspect that this would help me deepen my front-end craft, and I was excited to see where this interest would take me.

So that was a start on my accessibility journey: from coding responsive static sites, to enabling touch, to keyboard, interaction, to screen readers, and then finally, to discovering the entry into digital accessibility.

What was your journey like?

Drop me a line at hi@webaccessclub.com. I'd love to hear your story.

Next time. I'm going to share how and what I learned about disability culture, during my mission to understand disabled users better.

Outro

You can follow Web Access Club on Twitter, Facebook, and Instagram.

Show notes, resources and transcripts are available on webaccessclub.com.

If you like this episode, please tell a friend, leave a review, and subscribe wherever you get your podcast.