A Longer Introduction

This introduction could perhaps be more aptly titled as "Who am I and why am I here?" While I posted a shorter intro in the introductory thread, I think it's easier to use my first article to give you some insight into myself and my motivations.

My name is Sandra Clark, and through my company, Shayna Productions, I offer accessibility consulting services, including identifying, explaining, and resolving accessibility issues, as well as educating designers, developers, and testers on their accessibility responsibilities. My goal is to help teams work together to create actual accessible websites.

I am also a front-end developer with a focus on React and TypeScript, and I strive to create truly accessible components and applications. That's been my focus throughout most of my career, first as a contractor developing dynamic applications for various local, state and federal government agencies as well as for small, medium, and large companies in the private sector. I've gone through it all, from working full-stack on solo and small-team projects to being one of many front-end developers on multiple teams working on larger projects. I've worked with both waterfall and agile methodologies, and I've experienced situations where each approach can be beneficial and where they fall short.

My early years in programming were spent with the first web language to enable dynamic server-side sites, ColdFusion. It was groundbreaking in its time and was one of the few programming communities that were welcoming of women and actively recruited women speakers for its conferences. I was one, speaking at yearly conferences and to some user groups, focusing on accessibility and the foundations it's built upon—HTML, CSS and eventually WAI-ARIA.

As fewer companies needed ColdFusion programming, I moved into front-end development, specifically with React, which reminded me of the first framework I used. React allows me to build larger components from smaller ones, and for the most part, makes it easy to add accessibility when the website/application architecture allows it, of course.

I've been working in the React/TypeScript ecosystem for the past eight years. I appreciate structure and organization, and I'm comfortable with its paradigms, having wrapped my head around nested components in the first framework I ever used.

I'll say straight out that I'm not a fan of AI, especially when it comes to crafting accessible solutions. There are no training materials that can push LLMs to have a visceral understanding of the human condition, nor is there any way for AI to have compassion; requirements when considering how to code something every human can perceive and interact with. While not every designer or developer exhibits these characteristics, the fact that we are all human means we have the capability, even when we don't have the desire, qualities that AI lacks.

During my career, I've met a lot of people in the industry, and for the most part, whether they work as developers, designers, testers, program managers, scrum masters or even system architects, most of them are ignorant of accessibility and where the requirements for it lie in their area of expertise.

Accessibility seems like a dark hole that few want to dive into. It's not that most people don't care about accessibility when building websites or apps. It's that they don't think about the fact that other people may use the web differently than they are used to, or they have no idea what the requirements are or how to implement them. The WCAG guidelines are deliberately vague, and well, there's always some new shiny tech that grabs people's attention instead of boring HTML and keyboard functionality.

By the time a front-end developer is tasked with creating a new component, most of the architectural decisions that affect a site's accessibility have already been made. Those early decisions, whether it be routing to what comes from the back-end and even theming and design, have a huge impact on what a front-end developer can and can't do to create a truly accessible product. I've spent years working to improve a website whose original architects made decisions without considering accessibility, and even when I raised the specific issues, leadership was unwilling to change anything.

Over the years, I've learned to serve as a translator between architecture, design, development, and accessibility. And it's been necessary, especially when the only nod to accessibility is a ticket that serves as either a definition of done or acceptance criteria, which usually states something like "must meet WCAG 2.2".

Almost every tech person on the teams I've been a part of has little to no idea what WCAG means, beyond asking, "This is about blind people, right?" Many people don't fully understand what it takes to implement accessibility in whatever app or component they're building. I've also found that very few testers I've encountered, other than those I've had the opportunity to mentor, have known how to test accessibility.

"Must meet WCAG" places most of the responsibility for accessibility on developers and testers, without considering the other roles necessary to achieve it. Responsibility is placed without adequate training or guidance on how to meet the guidelines or determine whether they have been met. And even if the guidelines are met, many companies pay little to no attention to implementing accessibility in a meaningful, actually helpful way.

I live and breathe accessibility; I've been tasked with interpreting audit results for management and developers, drafting remediation suggestions for tickets, and pair-programming with developers to explain the issue and how to fix it.

I've been placed on special teams to find and fix accessibility issues right before major releases, a costly and unreachable goal. Especially when the requirement for the application to be accessible was part of the contract and known from the very beginning.

And I've learned a few things along the way.

Accessibility isn't achieved when a company pulls in every developer for a tech debt sprint and requires them to fix every vaguely worded accessibility-tagged ticket, only to ignore the issue once again until the next time tech debt is addressed. Tickets rerouted to the design team tend to stay in the backlog because it's "too hard" to actually fix the issues, for example, when it comes to a corporate primary color choice that will never meet contrast-ratio requirements.

Accessibility is achieved when everyone involved in creating a component, page, or application treats it as a foundational core principle to be considered during every stage of the design and development process.

Many of the decisions made early on, those that require concordance between the front and back end, need to keep accessibility in mind during the decision-making process. After all, allowing a user to upload an image without also providing the ability to store descriptive text actively impairs accessibility. Similarly, choices made by design, especially if they are at the forefront of the requirements a developer has to work with, may or may not improve accessibility, and non-visual perceivability may not even be considered.

I'm currently between contracts, not under any NDA and heads deep in a collaboration with a friend on the second iteration of their website, NudgeStories.com. The first version is a heavily customized WordPress site that pleases neither of us, but does gather the content for the second version: a headless WordPress back-end serving data to a React front-end. It's been a lot of fun settling back into being a full-stack developer as well as the architect and designer.

I want to use this platform to explore what it means to create a truly accessible website, one available to as many people as possible, regardless of how they choose to consume the content, and share what I've learned over the years as I've emphasized accessible development.

I'm currently working on a series on creating a universally accessible navigation component for React, and I hope the community finds it useful.

I hope you follow me, and I look forward to interacting with you.