Forem: ShaynaProductions

The Modalities of Accessibility

ShaynaProductions — Wed, 29 Apr 2026 12:15:00 +0000

There are nights when I have dreamt of a perfect world where, among other wishes, equitable access is a concern for everyone involved in developing a website. Unfortunately, the world I dream of is not the world we live in.

I remember a contract where a graphic designer took it upon themselves to develop a help module in React since no team had the capacity to take it on. During peer review, I discovered issues with the module in screen readers and a keyboard trap. When I raised them, the designer flat-out refused to fix them, telling me during a meeting called to address the situation, "I don't care about blind people."

I was shocked but not surprised. In the world we live in today, caring about accessibility often only happens when someone personally knows someone affected by a specific disability. In Agile development, a world of sprints, tickets, and the pressure to "move fast and break things," teams tend to push out incomplete components designed to work along the "happy path" and, when confronted with the fact that their work isn't available to those with disabilities, offer to come up with the plan to fix accessibility later.

The work of identifying specific disabilities and explaining how to address issues related to essential needs is often overlooked. The reality is that these issues rarely get resolved in a way that genuinely helps those who need it most. When accessibility is addressed at the end rather than built into the process from the start, the users who need it most end up suffering.

Let's face it, as developers and designers, we love the new, shiny aspects of our craft, and many of us, it seems, aren't conversant with the foundational structures that support accessibility. Making sure our content is available to everyone seems to be a feature everyone is content to let languish in the backlog.

Over the years, I've had the most success educating developers about accessibility when I've stopped leaning into guilt and compassion and focused on the nuts-and-bolts of what is necessary. And this means conceptualizing the Web Content Accessibility Guidelines differently.

Commonly referred to as WCAG, the guidelines are an international standard adopted by many countries. Within the United States, it has been adopted under Section 508 of the Rehabilitation Act, which requires federal websites operated by the Executive Branch to be accessible, and Section 504 of the same act, which requires organizations receiving federal funding or assistance to ensure their websites are accessible. This includes state agencies and publicly funded education systems, as well as public companies that receive federal financial assistance. Additionally, although not explicitly written into the law, U.S. courts have consistently upheld that websites run by private companies should also be subject to the same accessibility standards, through a variety of cases and appeals.

The WCAG guidelines and success criteria are deliberately vague to remain relevant in a rapidly changing environment. The same standards apply whether the medium is a PDF, a page, or an application. The guidelines can be intimidating, and given their organization, they don't always make much sense to a developer who's been given a ticket that simply lists "must meet WCAG 2.x" as an acceptance criterion. Where to start? How to implement?

WCAG seems to be a dark hole into which developers and designers fear to fall. I want to propose another way of looking at the requirements through the lens of modalities and our physical abilities.

The WCAG guidelines are grouped into four principles: Perceivable, Operable, Understandable, and Robust, collectively referred to as POUR. For the moment, I want to focus on the first two principles.

Perceivable

All the information we receive comes through our physical senses. Of the senses available to us, three —vision, hearing and touch— are used to consume digital information. We read text, look at images and videos on a screen, and hear music and speech through speakers. We can even experience the digital world through touch: the vibrations of a game controller or the raised dots from a braille printer. While many of us have access to all three senses, some have access to only two, and still others to only one.

The common denominator is that each of the three senses we use to perceive content on a computer is mediated by a peripheral device. We use screens, external or wired in to view, speakers, separate or integrated to hear, and still other devices such as a game controller or braille printer to feel.

So, perceivability can be achieved through peripherals, and to make content perceivable, we have to ensure it is available via a specific peripheral that accommodates one of the three senses.

WCAG's first principle is Perceivability. All information and user interface components must be presentable to users in ways they can perceive. We can accomplish this by making sure all content is seen and heard. Audio content should include transcripts for screens; video content should include descriptions and captions, along with transcriptions for those who cannot hear.

Screen readers are software programs that read the underlying content that ultimately displays on a screen. When coded structurally and semantically, the content on a screen can be perceived through different peripherals, such as audio from a speaker, or reduced to raised dots on a bar for reading through a braille printer.

When considered through this filter, it becomes obvious that our code needs to target two peripherals: screens and screen readers.

Most of the guidelines under the perceivability principle are mainly the responsibility of groups outside of front-end development. Media accessibility, be it text alternatives, transcriptions, audio descriptions and captioning, typically would be the responsibility of content producers and creators. It's not a developer's responsibility to oversee those requirements; it's just to write code that makes them available.

How something is perceived on the screen, from theming, colors, layout and displays is in the purview of the design team. It's their responsibility to ensure that those with vision impairments can perceive the same information as those with perfect vision.

Front-end developers do have some responsibility for perceivability. The underlying HTML, for example, should be semantic and well-structured. They are responsible for ensuring that metadata, such as state changes and relationships, is available to screen readers through HTML and ARIA attributes.

Operable

Just as we use peripherals associated with our physical senses to perceive, we use other peripherals associated with movement to operate and interact. Sites can be interacted with through peripherals, such as a mouse or trackpad (known as pointers); we also interact through keyboards, and increasingly we use our voice.

We can then specify that our sites must be operable via peripherals that support pointing devices, keyboards, and voice.

Front-end developers bear the greatest responsibility for operability, though designers have some considerations as well, particularly regarding resizing, image flashing, headings and labels.

Voice

Using our voice to control how we interact with websites is becoming increasingly common. Windows 11 and Macs have built-in programs, and some browsers offer plugins and settings for voice interaction. Not everyone using their voice to control a site has a disability; situational and convenience also rank high.

The most important aspect of operating a site via voice is ensuring that the words displayed on the screen are also programmatically associated with the component or element. This means the visual label and programmatic name must include the same words. It doesn't mean the words need to be exact; the preference is to append any differences rather than prepend them.

WCAG 2.5.3 Label in Name (A) requires that the visual label for a control be a trigger for speech activation.

Consider the following code.

First Name: <input name="firstname />

Wrong (contrived, but still bad)

In this case, the "First Name" field has no association with the input, so any voice-operating user will become frustrated when they cannot trigger the input to fill out the form.

<label for="firstName>First Name</label><input name="firstname" id="firstName />

Better

A user could enter their first name through their voice because the label is correctly hooked up to the input.

Since labels and displayed text are outside a developer's control, the responsibility for ensuring the component name matches the displayed label lies with whoever is responsible for text enhancements. A developer's responsibilities here are mainly to notice when something doesn't meet the requirement and to request an enhancement from the responsible parties, whether the design team or the content owner.

Any component where an aria label changes the wording shown must still include the visual wording for voice control to work, and whoever is responsible for the underlying wording and labeling must be aware of the issue.

Pointers

Pointers can include mice, trackpads, joysticks, and basically anything you can do with a finger or two or three. Many assistive technology devices mimic a simplified single-pointing device, usually a mouse event.

When implementing handlers, it's important to understand that some devices require mouse events, while others require pointer events, and to ensure your handler works in all cases. React supports a synthetic event handler onPointerDown that fires when a pointer is clicked on a tag or element.

Keyboard

When it comes to keyboard usage, there are really two distinct sets of considerations. Screen readers on desktop computers require keyboard use, which presents different considerations than those for users who rely on a screen and keyboard for navigation.

Keyboard with Screen Readers

Every screen reader uses specific keyboard keys for all of its operations. There are keyboard commands that allow users to bring up lists of interactive elements, move through tables, skip to the next heading or link, and move through forms.

Every screen reader uses different keys and key combinations for their users to navigate and interact with content, so care must be taken not to interfere with these keys when implementing your own. Reference guides for the most popular screen readers can be found at Deque University Screenreaders page.

For the most part, navigation outside the screen reader's key commands is handled by the Tab and Shift+Tab keys. Some screen readers limit the arrow keys to specific component types, such as select elements and radio groups, while others expose and allow their use in other custom components.

Keyboard with Screen

With all the focus on accessibility for people who are blind, those who use a keyboard and screen combination can sometimes feel left out. Several assistive technologies mimic a keyboard, including on-screen keyboards activated by a switch, head and eye tracking, and sip-and-puff devices.

Anyone using a screen should be able to navigate solely through the keyboard. Except for text inputs (single or multi-line), the most commonly used keys are Tab, Enter, Space, Escape and the arrow keys.

Both screen/pointer and screenreader/keyboard users have a variety of ways of navigating to the content they are interested in. Screen-using keyboard users are the only users forced to navigate a web page linearly. They can benefit from bypassing common elements, such as header elements or long lists of interactive elements.

When considering operability for these users, it's the interactive, focusable elements that deserve our attention.

The basic interactive elements within HTML are <a />, < button />, <input />, <select />, and < textarea />. HTML elements are coded to be accessible and should be used rather than rolling your own.

<div role="button" onClick={handleClick >Click Me < /button > does not in fact equal <button onClick={handleClick}>Hello</button>

Without a tabIndex=0, the div cannot retain focus. None of the basic accessibility and functionality of a native button is present in a div that calls itself a button, which makes it even more frustrating for a user. A div with a role of button that only uses the onClick event will not respond when a user presses the Space or Enter keys. Each event type must be handled when creating your own custom component from divs.

It is far better to use native HTML elements rather than cobbling together your own.

Understandable and Robust

POUR's last two principles, Understandable and Robust, must be understood within the modalities of perceivability and operability. For instance, when allowing a user to switch to a different language, the lang attribute in the < html/> tag must be updated. A screen reader must know which language to use to speak with the language's natural inflections and pronunciation, rather than sounding like someone just learning the language.

Similarly, if an error is identified and described to a user, it must be created in a way that is perceivable on the screen and through the screen reader.

Consider tying accessibility to peripherals rather than to user disabilities. A ticket clearly defining acceptance criteria based on a peripheral is much clearer to a front-end developer than having them memorize which disabilities require which interactions.

As professionals, it's our responsibility to ensure a website is fully perceivable on screen and with screen readers, and operable with pointing devices and keyboards. It shouldn't matter which devices a user chooses, or why they choose them, whether it's convenience or a disability. Our sites should just work.

This article sets the stage for what comes next. Applying responsibility and the modalities of accessibility when building an accessible component.

Join me as I start working on a universally accessible main navigation component for my site. I'll be building out a GitHub repository and discussing what it takes to build this component over a series I call "Guide to creating an accessible navigation component".

Are you ready? Buckle up.

Who is actually responsible for Web Accessibility?

ShaynaProductions — Tue, 28 Apr 2026 12:15:00 +0000

Who is responsible for making sure software is accessible? If your short answer is the front-end development team, I'm sorry to say that your software will never be universally accessible, because many accessibility decisions are made long before a developer begins working on a component. Architecture, design, and, yes, requirements all play a part in ensuring that whatever software is developed is perceivable and operable by people with differing characteristics.

In all the agile teams I've been a part of, the process of creating a feature or component typically involves the project owner assessing needs, which (if deemed necessary) are then handed off to the software architect, and then to the data and design team/member(s), which (with or without front-end developer input) provide a visual design. Tickets are dispatched to different teams, and development commences.

As a front-end developer, I am usually assigned stories with a design document or a Figma link, along with acceptance criteria. Rarely does any of this include accessibility information, and I haven't yet encountered someone well-versed in accessibility being included in the decisions made before tickets are written or handed off.

Even if accessibility is considered before tickets are written, suggestions about it are usually met with swift and sometimes fierce pushback because the changes necessary to implement them affect a delivery date that was committed to without considering what it takes to create an accessible feature. When tickets mention accessibility in the acceptance criteria, it's typically a generic bullet point: "must meet WCAG 2.x."

Front-end requirements tend to focus primarily on the physical sense of sight, with little input on how to make something perceivable to someone who lacks that sense. It's easier to demonstrate screen and mouse interactions during sprint demos and other agile ceremonies, since keyboard navigation doesn't translate well in either virtual or physical meetings, and screen reader demonstrations tend to be ineffective and leave stakeholders without a clear understanding of what has been achieved.

True accessibility cannot be achieved if the first reference to it appears in a front-end development ticket.

Trying to implement accessibility into a component when neither the design nor the back-end architecture has considered it will result in one of two outcomes: giving up after multiple test failures, or kludging the code to address impossible-to-fix issues aimed at passing an accessibility audit rather than helping actual users. A common example would be a requirement to describe user-uploaded images with an alt attribute when no database field is available to store the information. At best, a front-end developer can add generic alt text to pass an automated audit, but the actual requirement to describe an image so that someone who cannot see it has the same understanding as someone who can is never addressed.

Requiring a developer to navigate between an inaccessible Figma design and the requirements to pass an accessibility audit places an undue burden on the party least able to rectify the situation.

Implementing accessibility requires the knowledge and cooperation of everyone involved in the creation. From the project owners who define the business features to the back-end engineers who handle the data, as well as the designers, software architects, tech leads, content creators, developers, and testers. And while not everyone needs to be an expert in overall accessibility, they do need to know their responsibilities and gain expertise in those areas.

Real accessibility requires those who assess the needs and gather the requirements to include requirements mapped to the appropriate WCAG success criteria when determining how a particular feature should be perceived and operated.

Real accessibility requires the work of back-end engineers to ensure that dynamic images, charts, and graphs derived from database data also store and send the information necessary to describe those items.

Real accessibility requires reasonable time limits and budgets to account for accessibility requirements when determining roadmaps.

Real accessibility requires content owners to ensure that, if textual, the content they provide conforms to proper HTML semantic structure. If the content medium is audio/visual, it is accompanied by proper captioning, descriptions, transcriptions, and other related requirements for audio, images, and video.

Real accessibility requires those writing tickets to write user stories and acceptance criteria in a way that both developers and testers can follow.

Real accessibility requires those involved in design to truly understand the perceivable guidelines in the Web Content Accessibility Guidelines (WCAG) and apply them in their designs.

Real accessibility requires someone to be responsible for determining the phrasing of labels and text, including errors, descriptions, and headings that may or may not be visible on the screen.

Real accessibility requires developers who understand the importance of accessibility and their role in ensuring components are semantically structured. They should be able to implement WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) properties and states correctly, and be responsible for supporting proper keyboard handling within complex components.

Real accessibility requires testers who know how to test across different accessibility scenarios, who can use a screen reader and the accessibility tree to ensure a user who lacks the physical sense of sight has an equitable experience as one who can see a screen.

Real accessibility takes a company and community-wide effort. Whether it's a team-wide push or one person wearing all the hats, accessibility needs to be at the forefront of everyone's mind from the beginning of development to the very end.

Right now, I'm like many of you, trying to survive the fallout happening in IT. I'm currently partnering with a friend on a website that hosts a constantly expanding universe of short stories. My friend is the content owner and has implemented their requirements, and I'm responsible for everything else. As the sole requirements gatherer/software architect/developer/designer/tester, it's my responsibility to ensure accessibility is considered at every step of the process.

Hat Order

Hat order is important. A tester's hat does me no good if there's nothing to test yet, and I can't develop a component until I know what I'm supposed to be building. So, really, the first hat I have to put on after deciding what I'm going to build is that of a product owner.

Business Analyst/Requirements Gatherer 🖊

Whether it's a standalone component or a feature, accessibility needs to be quantified. Requirements should be linked to Acceptance Criteria, and, ideally, those related to accessibility should also be linked to WCAG success criteria and best practices.
Depending on company culture, requirements may be gathered in one place before any work begins, or gathered incrementally; however, all acceptance criteria for a particular user story should be in place a few sprints before design or development work begins.

Software Architect 👷🏼

A software architect is responsible for ensuring consistency throughout the website and for considering the architecture of a component and its relationship within the entire project. A software architect would be the first to review any requirements/acceptance criteria and add any necessary information. They would participate in design reviews to ensure the design itself is accessible and review pull requests for adherence to accessibility norms.

Content Creators/Producers 🎙️

Content creators are responsible for ensuring that all audio, video, and textual content available through the website or application is accessible to everyone through proper semantic structure, captioning, audio description, and transcription. Proper labeling of interactive content is necessary to enable operability via voice.

Designers 🎨

Designers are responsible for what is shown on the screen. There is no amount of development in the world that can overcome an inaccessible design. The design team is responsible for the color contrast ratio between the foreground and background, and for state changes that occur when focus or hover actions interact with an interactive object.

Depending on the team structure, they may or may not be responsible for the visual text labels and icon descriptions shown. If they are, they should also be responsible for labeling any text aimed toward screen readers.
The design can be created in a prototyping environment such as Figma and sent back to the developer for application. If it is feasible and the CSS can be decoupled from the scripting code, designers could apply the CSS themselves.

Backend Engineers ⌨️

Backend engineers are responsible for guaranteeing that the information necessary to describe an object whose data or location is stored in a database also includes fields to hold the descriptions. When raw data is used to generate a chart or other visually oriented component, textual descriptions based on the data are also generated and sent to the front end.

Frontend Developers 👩🏻‍💻

A frontend developer implements the actual component or feature, using their knowledge of Semantic HTML structure and WAI-ARIA to create a semantically structured component that is operable across keyboard and touch peripherals.

Developers are responsible for adhering to the acceptance criteria and ensuring the required WCAG guidelines are implemented. Developers should understand how browsers implement the accessibility tree and, ideally, test their code with screen readers and accessibility testing tools such as Accessibility Insights for Web.

Testers 👩🏻‍💻

Whether programmatic or human, a tester is responsible for making sure the tested item complies with the stated acceptance criteria. Screen readers and other accessibility testing tools, such as ZoomText or Accessibility Insights, may be used to test overall accessibility and specific acceptance criteria.

When everyone is responsible for accessibility, the burden is shared. Not everyone needs to be an expert in everything that makes up accessibility, but each role needs to be an expert in their particular area.

Accessibility as a Layered Process

While it's important to keep accessibility in mind from requirements gathering through testing, for the actual implementation, I've found it helps to build everything in layers over a series of sprints.

Conversations over architecture, accessibility and design need to happen early in the process. Once a base structure is agreed upon, a front-end developer can create a clickable, semantically structured prototype that includes the basic requirements for screen reader perceivability and deliver it, along with minimal CSS, to the design team, who will work on screen perceivability. This prototype should be clear enough visually to help the developer implement the remaining features.

When visual considerations take precedence, developers are more concerned with delivering something that matches the design than with how it operates. Minimal styling, even if it's ugly, helps developers focus on how the component operates, knowing the true design can be applied later in the process.

Depending on the complexity of the component or feature, multiple tickets may be created, each with acceptance criteria mapped to the requirements, creating a contract between what a developer creates and what testing accomplishes. Toward the end of the process, the design can be implemented and tested against the WCAG perceivability and operable navigability guidelines.

I'm going to demonstrate this process in a series of articles in which I implement a main navigation component that can be used for both desktop and mobile presentations.

Are you ready to follow me on this journey? Buckle Up.

A Longer Introduction

ShaynaProductions — Tue, 21 Apr 2026 12:10:00 +0000

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.