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.