Why Accessibility Matters

13/08/2025

Reading Time: 12 minutes

Gülce Bulut

Gülce Bulut

Product Owner

Creating accessible digital products is not just a technical goal, it’s a commitment to building better experiences for everyone. As product owners, we are uniquely positioned to support and guide inclusive design throughout the product lifecycle. From shaping early requirements to coordinating with design, development, and QA teams, our decisions influence how accessible a product truly becomes.

This guide is here to help you understand why accessibility matters, what your role involves, and how to make it a natural part of everyday product work. Because when we build with accessibility in mind, we design for everyone and not just for the majority.


1. What is Accessibility?

Accessibility means designing a product, environment, or system in a way that allows people to use it equally and effectively, regardless of their physical abilities or limitations. It’s about removing barriers that might prevent someone from interacting with a digital experience; whether that person has a permanent disability, a temporary condition, or is simply using a device in a constrained environment.

First and foremost, as product people, but also as anyone contributing to a digital product, accessibility starts with empathy. Whether you’re a designer, developer, tester, or product owner, thinking about diverse user needs is everyone’s responsibility. When we build with a broader range of experiences in mind, we not only create more products, but also we create better experiences for all.

According to the World Health Organization, over 1 billion people, around 16% of the global population, live with some form of disability. And that number doesn’t even include people facing temporary limitations (like a broken arm) or situational ones (like using a phone in bright sunlight). Designing for accessibility means designing for the real-world diversity of the human experience.

2. Why Accessibility Matters

Accessibility is not just a technical requirement; it’s a strategic advantage.

It allows us to reach a much broader audience, including people with permanent disabilities, those experiencing temporary limitations, or anyone affected by situational constraints, like using a mobile phone in bright sunlight or with one hand. By considering these realities, we show users that we care about their experience. It’s a simple but powerful message: “We designed this for you, too.” That alone builds trust and loyalty.

At the same time, legal obligations around accessibility are growing. Countries like the United States and members of the European Union have already made digital accessibility a legal requirement. In the U.S., the Americans with Disabilities Act (ADA) and Section 508 establish clear standards for digital platforms. In Europe, the European Accessibility Act (EAA) will make accessibility mandatory for a wide range of digital services by 2025. We’ve already seen how regulations like the General Data Protection Regulation (GDPR) have influenced digital practices far beyond their borders.

Accessibility rules follow a similar path: starting local, becoming global. Teams that align early with accessibility standards avoid last-minute compliance issues and build more resilient products in the long run.

Beyond compliance, inclusive products reach more users, many of whom are underserved by today’s digital experiences. While accessibility isn’t a direct search engine optimization ranking factor, practices like semantic HTML and meaningful alt text help search engines better interpret content. Teams that prioritize accessibility at the beginning tend to produce more structured, maintainable work. Thinking through edge cases early reduces bugs and leads to clearer design decisions. One study by Forrester’s has shown that companies investing in accessibility benefit from stronger brand perception, wider market reach, and higher user satisfaction.

And ultimately, accessibility is simply the right thing to do. Digital access is a human right. As creators of digital products, it’s our responsibility to ensure that what we build works for everyone.

3. The Importance of Accessibility for Digital Products

In the physical world, making environments accessible often requires large-scale planning, infrastructure changes, and long timelines. Making public transportation or buildings fully accessible can take years and usually involves multiple stakeholders and government policies. But in the world of digital products, we’re in a different position.

Digital products are uniquely adaptable. We can design our interfaces that respond to different user needs, offer multiple ways to interact, and adjust dynamically to assistive technologies. A small change, like adding a meaningful label or improving contrast, can have a big impact on someone’s ability to use a feature.

Another major advantage is that digital products are never truly finished. Accessibility improvements don’t require full redesigns or massive budget changes. Teams can act on feedback quickly, test iteratively, and roll out fixes in days rather than months or years. This ability to evolve makes accessibility easier to maintain.

What also makes accessibility more achievable today is the availability of technical resources. Most modern frameworks and platforms offer accessibility support by default. There are automated testing tools, built-in accessibility features, and established standards like ARIA and semantic HTML. In other words, we’re no longer lacking tools, we just must use them intentionally.

Still, when accessibility is overlooked, the impact is very real. Being unable to enter a store or use public transport is an exclusion, and the same goes for not being able to use a banking app, submit a government form, or access online healthcare. A 2025 WebAIM study found that 94.8% of the world’s top one million home pages had at least one accessibility issue. Unfortunately, it shows that many websites people rely on every day still fail to meet basic accessibility expectations.

For anyone building digital products, accessibility shouldn’t be a secondary concern.

4. Global Accessibility Regulations You Should Know

Accessibility isn’t just a matter of best practice anymore; it’s becoming a legal requirement in many parts of the world. For anyone involved in building or owning digital products, being aware of these regulations is essential.

Whether you’re planning to scale internationally or just want to build more responsible, future-proof products, knowing what’s expected can help you make smarter decisions earlier.

Now let’s look at some of the key global regulations shaping how digital products are expected to meet accessibility standards.

WCAG: The Technical Foundation Behind Most Laws

The Web Content Accessibility Guidelines (WCAG) are developed by the World Wide Web Consortium (W3C) which is the international body that sets global web standards.

WCAG provides clear guidance on how to design and develop digital products that work for everyone, including people with disabilities. It’s built around four core principles: Perceivable, Operable, Understandable, and Robust.

Most international accessibility laws, including those in the U.S., European Union, and others, reference WCAG 2.1 as the baseline for compliance.

So before diving into legal frameworks, it’s helpful to understand that WCAG is the common thread behind them all.

European Union: European Accessibility Act (EAA)

The European Accessibility Act (EAA) is set to take effect on June 28, 2025, and it aims to ensure that a wide range of digital services are accessible to all users, including those with disabilities. The scope of the regulation includes e-commerce platforms, banking services, mobile applications, public sector websites, and ATMs.

The act references the EN 301 549 technical standard, which is built on the Web Content Accessibility Guidelines (WCAG). Importantly, the EAA applies to both public and private sector digital services, making accessibility a shared responsibility across industries. Despite the upcoming enforcement date, many websites across Europe still fall short of compliance.

According to the 2025 WebAIM Million study, 94.8% of top homepages had detectable accessibility failures, with the most common issues being missing alternative text and insufficient color contrast.

United States: ADA & Section 508

In the United States, digital accessibility is primarily governed by two key frameworks: the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. Although the ADA does not explicitly mention digital platforms, U.S. courts increasingly interpret it to apply to websites and mobile applications, setting legal expectations for businesses to provide equal digital access.

Section 508, on the other hand, requires all federal agencies and their digital services—including websites and software—to meet defined accessibility standards. Both frameworks reference the Web Content Accessibility Guidelines (WCAG) as the technical foundation for compliance.

Despite these legal expectations, the implementation gap remains significant. A 2024 scan by AudioEye, analyzing over 40,000 enterprise websites, found that only 3% were considered fully accessible.

Other Countries

While the European Union and the United States have set some of the most comprehensive digital accessibility frameworks, other countries are also making progress. In many regions, laws exist but are less detailed or inconsistently applied. Below are a few notable examples where local regulations are more clearly defined or have influenced accessibility practices on a national level.

In Canada, the Accessible Canada Act mandates accessibility in government and federally regulated sectors. It focuses on removing barriers in seven priority areas, including information and communication technologies. Although its primary focus is on the public sector, it sets a precedent for digital inclusion more broadly.

Australia enforces the Disability Discrimination Act, which includes websites under its scope. Several high-profile legal cases, most notably Maguire v. Sydney Organizing Committee for the Olympic Games (2000), have reinforced that inaccessible digital services may be considered discriminatory, prompting many organizations to adopt accessibility practices voluntarily.

In countries such as India, Israel, and the United Kingdom, accessibility laws exist and are largely aligned with international guidelines. For instance, the UK’s Equality Act covers digital services and has led to significant improvements in public-facing websites. India and Israel also have formal legislation referencing inclusive access, though the level of enforcement and public awareness can vary.

Accessibility in Türkiye

In Türkiye, accessibility for public sector digital services has largely been guided by government-issued circulars and sector-specific frameworks. The 2020/1 Presidential Circular requires public institutions to make their websites accessible, while the Digital Transformation Office’s Accessibility Guide provides recommendations for implementation, though it does not carry legal enforcement power.

Moreover, there are two notable developments:

Banking Services Accessibility Regulation, issued by the Central Bank of Türkiye, came into force on January 1, 2021. It mandates that banks ensure their branches, ATMs, call centers, internet banking, and mobile banking apps are accessible to users with disabilities.

While this is one of the few clear legal frameworks in the country, enforcement remains limited. As of now, there is no publicly known enforcement case, and compliance levels vary significantly across institutions.

More recently, in June 2025, a new Presidential Circular (No. 2025/10) was published, further reinforcing the national framework for accessible digital services. It emphasizes that both public websites and mobile applications must be accessible to all users, not just specific groups.

It also established a national monitoring commission under the Ministry of Family and Social Services, tasked with overseeing accessibility audits and coordinating efforts with agencies like TÜBİTAK, Türksat, and the Ministry of Transport.

This circular reflects how fast the regulatory landscape is evolving. Even while this guide was being written.

5. What Product Owners Should Pay Attention to in Accessible Product Development

1. Benchmarking and Discovery

In early-stage research and exploration, accessibility often gets overlooked in favor of features, visuals, or market fit. However, what a team chooses to benchmark against shapes their assumptions about what good looks like. If accessibility is absent from competitor products, it can easily be deprioritized internally.

Product owners can bring accessibility into the conversation early by asking:

  • “Can this product be used without sight, hearing, or touch?”
  • “Are screen readers or alternative inputs supported?”
  • “Is accessibility part of their value proposition?”

Even raising these questions helps the team consider inclusion from day one.

2. Requirements Definition

This is the phase where functionality is defined, and expectations are agreed upon, not just internally, but often in alignment with stakeholders. Including accessibility at this point helps establish it as a shared expectation from the outset.

When negotiating scope or defining priorities, product owners can help ensure that accessibility is part of the conversation and not something added later. Asking questions like:

  • “Does this requirement assume ideal user conditions?”
  • “Should we define how this works for users who can’t rely on visuals or gestures?”

By aligning with stakeholders on these expectations early, product owners help set a more inclusive baseline for the entire product team.

3. Design and User Experience

Accessibility starts to take shape visually during the design phase. This step is critical, not just because it affects how a product looks, but because it shapes how different users will experience it.

The user experience team plays a key role here. Product owners rely on them to provide clear guidance on how screens should behave when used with screen readers, keyboards, or alternative inputs. This includes describing reading order, contrast ratios, alt text, and focus behavior.

Product owners are not expected to provide these specifications, but they are expected to recognize when they’re missing and ask:

  • “Will this screen make sense when read aloud?”
  • “Is color the only way we’re communicating meaning here?”
  • “Do we need to clarify interaction feedback for different use contexts?”

Designs should come with accessibility notes when appropriate. Product owners can help ensure this happens and that decisions made in the UX process are clearly communicated downstream.

4. Business Analysis

Writing business analysis plays a key role in translating product requirements into detailed use cases and scenarios including exceptions and edge cases.

This is where accessibility can be embedded in how the product is meant to behave under different user conditions.

In business analysis, you can consider doing:

  • Write user stories that reflect diverse needs
  • Include accessibility checks in flow charts or acceptance logic
  • Clarify behavior for non-ideal or constrained scenarios (e.g. screen reader users, one-handed interaction)

When accessibility is part of the logic, it naturally finds its way into the implementation.

5. Walkthroughs and Planning Sessions

Walkthroughs are key opportunities to align expectations before any code is written. Product owners can make accessibility a natural part of these sessions by checking for gaps and asking thoughtful questions.

With developers, that could mean:

  • “Are we using a component that supports keyboard and screen reader behavior?”
  • “Do we need to verify the focus handling for this interaction?”

With QA, product owners can ask:

  • “Do you have what you need to test this with screen readers or keyboard-only navigation?”
  • “Are there known limitations to our test tools or scenarios?”

Bringing these questions forward shows that accessibility isn’t an afterthought, it’s part of delivering complete work.

6. Development and Implementation

While developers are the ones writing the code, product owners still influence which items get built, how they’re prioritized, and how challenges are resolved.

At this stage, product owners can:

  • Reinforce accessibility expectations from previous steps
  • Support the use of accessible design systems or UI libraries
  • Encourage developers to raise questions when component behavior is unclear
  • Make sure accessibility-related bugs are logged and addressed like any other issue

Even if product owners don’t handle implementation directly, they help keep the focus steady and consistent.

7. Testing and Delivery

Testing isn’t only about verifying that something works, it’s about ensuring it works for everyone. Accessibility testing should be part of the standard QA process, not a separate checklist.

Still, accessibility testing is not yet consistently practiced across teams. According to Deque’s 2022 State of Accessibility report, only 14% of organizations said their QA teams include accessibility checks as a standard part of every release. This highlights a clear opportunity for improvement, and product owners can play a key role by reinforcing these checks during planning and review.

Product owners can support this by:

  • Including accessibility checks in acceptance criteria
  • Asking QA teams if they have what they need to test screen reader behavior, keyboard navigation, and visual clarity
  • Encouraging that accessibility issues are logged and treated like any other bug

Simple tests, such as navigating with a keyboard, using a screen reader, or checking focus states, can catch many common issues before release.

8. Post-Launch and Regulation Awareness

Accessibility doesn’t end with delivery. Regulations evolve, teams shift, and user expectations change. Product owners should help ensure that accessibility remains visible after release, not just as a one-time effort, but as something that’s tracked and improved over time.

Especially for outsourced or client-facing teams, product owners should clarify expectations early in the process:

  • “Are there specific accessibility expectations or regulations we need to meet?”
  • “Do requirements differ based on the target regions (e.g. Türkiye, EU)?”
  • “Should accessibility be demonstrated or verified during reviews or demos?”

These discussions can help teams scope work accurately and avoid misunderstandings later. Product owners may also help keep stakeholders and project managers informed, flag new regulatory changes, and ensure the product continues to meet the expected standard.

According to Level Access’s 2023 Global Accessibility Trends Report, over 60% of product teams have had to adjust their product roadmaps in response to shifting accessibility expectations or regulations—reminding us how important it is to keep accessibility visible, even after delivery.

Considering everything we’ve covered so far, responsibilities and collaboration, let’s walk through an example of how accessibility can come to life during a typical sprint.

Example of Sprint Flow: Accessibility in Action

Imagine a standard two-week sprint. The team is working on a new “Notification Preferences” screen for a mobile banking app. Here’s how accessibility shows up at different moments, especially through the eyes of the product owner.

Sprint Planning:

The product owner presents the goal and reviews a new feature. During this session, they reminded the team that accessibility will be part of the scope like any other functionality.

Design Review & Handoff:

The UX team shares the Figma file. It includes contrast-checked color use and accessible label suggestions. The product owner notices that some of the toggle buttons don’t have visible labels and asks if VoiceOver will read them clearly.

Analysis & Story Writing:

The product owner writes the user story, including accessibility-related acceptance criteria.

Walkthrough with the Development & QA Teams:

During the story walkthrough, the product owner highlights expectations. Teams raise questions, which are clarified with the UX team.

Development:

A development flags that a modal doesn’t follow the focus order. The product owner helps clarify and reprioritize.

QA & Review:

QA runs their standard flow and basic accessibility checks. One accessibility bug is found and fixed within the sprint.

Sprint Demo:

The product owner calls for accessibility efforts. The team delivers a complete, inclusive experience.

To better illustrate how product owners interact with different teams to ensure accessibility, the following diagram outlines typical collaboration flows across a digital product team. It shows where accessibility responsibilities are shared, how communication flows between the product owner and other roles, and what each team typically contributes to the process.

Collaboration Map for Accessibility in Product Development

Figure: Collaboration Map for Accessibility in Product Development

Key Takeaways

Throughout this article, we’ve looked at how accessibility fits into the way digital products are built: from research and design to analysis, development, testing, and delivery. We’ve also seen how it’s not just about what we build, but how teams work together to build it.
For product owners, that means keeping accessibility visible, not necessarily by knowing every detail, but by helping others think about it at the right time. That could be asking questions during a design review, making room for accessibility in a walkthrough, or making sure criteria reflect more than just functionality.

Accessibility isn’t just a good practice anymore.

In many regions, including Türkiye and the EU, it’s becoming a legal expectation. Regulations like the European Accessibility Act have clear deadlines, and even in countries where requirements are still evolving, awareness is increasing. Following these developments helps us build products that are not only useful, but responsible.

Considering all the information that we’ve given above, keeping accessibility in mind as you shape decisions, write stories, or lead discussions can make a real difference. And when teams start including accessibility as part of their normal thinking, it gets easier for everyone.

In the end, accessibility becomes everyone’s job when we treat it like part of the product, not a separate task.

References

Don’t miss out the latestCommencis Thoughts and News.