Skip to main content
Accessibility.com, LLC
Category: Compliance and Reporting

Barrier

Also known as: Accessibility barrier, Digital barrier
Simply put

In digital accessibility, a barrier is anything that blocks or hinders a person with a disability from perceiving, understanding, navigating, or interacting with digital content or services. Just as a physical barrier can prevent someone from entering a building, a digital barrier can prevent someone from completing a task on a website or app. Barriers may arise from design choices, missing information, or technical implementations that do not work with assistive technologies.

Formal definition

A barrier is a condition within a product, environment, or content that prevents or impedes a person with a disability from accessing, operating, or benefiting from it on an equal basis. The general concept derives from the ordinary meaning of a barrier as something that blocks or hinders passage or movement. In digital accessibility practice, barriers commonly correspond to failures of accessibility principles, for example, content that is not perceivable, operable, understandable, or robust for users relying on assistive technologies. Barriers can be technical (such as controls that cannot be reached by keyboard or elements without programmatic names), informational (such as images lacking text alternatives), or interactional (such as time limits or interactions that cannot be completed with assistive technology). This entry describes the general concept and is not legal advice; whether a specific barrier constitutes a compliance failure depends on the applicable standard, jurisdiction, and evolving regulation and case law, and readers should consult qualified counsel where appropriate.

Why it matters

The concept of a barrier sits at the center of digital accessibility because it reframes accessibility problems in terms of their practical consequence: whether a person with a disability can actually complete a task. A barrier is not merely a technical imperfection but a condition that blocks or hinders someone from perceiving, understanding, navigating, or interacting with digital content or a service. Just as a physical barrier such as a step or a locked door can prevent someone from entering a building, a digital barrier can prevent someone from reading information, submitting a form, or purchasing a product online.

Identifying barriers matters because their presence, rather than the intent behind them, is what determines the impact on users. A barrier may arise from a design choice, from missing information, or from a technical implementation that does not work with assistive technologies, regardless of whether the creator intended to exclude anyone. Because barriers are defined by their effect on people, they provide a user-centered lens that complements, and sometimes reveals gaps not caught by, checklist-style or automated conformance testing. Automated tools detect only a portion of potential barriers, so manual review and testing with assistive technology are generally needed to find barriers that affect real use.

Whether any specific barrier also constitutes a legal compliance failure is a separate question that depends on the applicable standard, jurisdiction, and evolving regulation and case law. This entry describes the general concept and is not legal advice; organizations facing questions about legal obligations should consult qualified counsel.

Who it's relevant to

Accessibility engineers and QA testers
Those responsible for evaluating products use the concept of a barrier to focus testing on real user impact rather than on abstract rule violations alone. Because automated tools catch only a portion of issues, engineers commonly combine automated checks with manual review and assistive technology testing to surface technical, informational, and interactional barriers.
UX and product designers
Barriers frequently originate in design decisions, such as interactions that assume a mouse, missing text alternatives, or time limits. Designers who understand how barriers form can prevent them earlier in the process, when they are typically less costly to address.
Compliance officers and business leaders
Barriers describe the practical gaps between a product and equitable access for users with disabilities. Leaders can use the concept to prioritize remediation by user impact, while recognizing that whether a given barrier represents a compliance failure depends on the applicable standard and jurisdiction.
Legal counsel
Counsel may encounter the term when assessing how a product affects users with disabilities. Because this entry describes a general concept and not legal obligations, whether any specific barrier amounts to a compliance failure should be evaluated against the relevant authority, current regulation, and case law.

Inside Barrier

Digital Barrier
Any aspect of a website, application, document, or digital service that prevents or hinders a person with a disability from perceiving, understanding, navigating, or interacting with content on an equal basis with others.
Perceptual Barrier
Obstacles that stop users from perceiving content, such as images without text alternatives, video without captions, or insufficient color contrast, which can affect users who are blind, have low vision, or are deaf or hard of hearing.
Operational Barrier
Obstacles that prevent users from operating an interface, such as functionality that requires a mouse and cannot be completed with a keyboard, or interactive elements that are not exposed to assistive technology.
Cognitive Barrier
Obstacles related to understanding, such as unclear instructions, inconsistent navigation, or complex language, which can disproportionately affect users with cognitive or learning disabilities.
Relationship to WCAG
Many barriers correspond to failures of specific WCAG success criteria; identifying a barrier often involves mapping it to the relevant criterion and conformance level (commonly Level AA is cited as a target). Note that conformance and the absence of barriers are not identical concepts.

Common questions

Answers to the questions practitioners most commonly ask about Barrier.

Does removing accessibility barriers from a website guarantee legal compliance?
No. Removing identified barriers reduces the likelihood of exclusion and is a sound practice, but it does not guarantee immunity from legal claims. Legal compliance in the US is shaped by statutes such as the ADA, applicable regulations, agency guidance, and evolving case law, and courts and settlements have often referenced WCAG as a benchmark rather than treating barrier removal as a fixed legal safe harbor. Barrier removal should generally be paired with ongoing testing and, where appropriate, review by qualified legal counsel. This is not legal advice.
Can automated testing tools detect all accessibility barriers?
No. Automated tools detect only a portion of accessibility issues, such as certain missing attributes or some color contrast problems. Many barriers, like a control that is technically labeled but confusingly worded, an illogical focus order, or content that is unusable with a screen reader, require manual evaluation and testing with assistive technologies to identify. Relying on automated checks alone commonly leaves significant barriers undetected.
How do you identify accessibility barriers in a digital product?
Barrier identification generally combines multiple methods: automated scanning to flag detectable issues, manual expert review against relevant WCAG success criteria, testing with assistive technologies such as screen readers and screen magnifiers, keyboard-only navigation testing, and, where feasible, testing with people with disabilities. Using these approaches together helps surface barriers that any single method would miss.
How should teams prioritize which barriers to fix first?
Prioritization commonly considers the severity of the barrier's impact on users, how many users or how many key tasks are affected, and whether the barrier blocks a task entirely versus making it harder. Barriers that prevent users from completing essential functions, such as logging in, checking out, or accessing critical information, are often addressed first, while less severe issues may be scheduled into ongoing remediation.
Who is responsible for addressing barriers in an organization?
Addressing barriers is typically a shared responsibility spanning designers, developers, content authors, quality assurance testers, and product owners, often coordinated by an accessibility lead or program. Because barriers can be introduced at any stage, from design decisions to content updates, embedding accessibility across roles and workflows is generally more effective than assigning it to a single person or a one-time review.
How can teams prevent new barriers from being introduced over time?
Preventing new barriers generally involves integrating accessibility into the development lifecycle rather than treating it as a final check. Common practices include building accessible components, incorporating accessibility acceptance criteria, running automated checks in continuous integration, conducting periodic manual and assistive technology testing, and training content authors. Because digital products change frequently, ongoing monitoring is typically needed to catch barriers introduced by new features or content.

Common misconceptions

If a page passes automated accessibility testing, it is free of barriers.
Automated tools detect only a portion of potential barriers. Many issues, particularly operational and cognitive barriers, are only surfaced through manual review and testing with assistive technologies.
Removing barriers guarantees legal compliance and immunity from claims.
Reducing barriers generally improves accessibility and can lower legal risk, but no measure guarantees compliance or immunity. Requirements evolve through regulation and case law, and readers should consult qualified legal counsel; this is not legal advice.
A third-party overlay or widget will automatically eliminate barriers.
Overlay and widget vendor claims are marketing terminology and are distinct from established standards. Such tools may not remove underlying barriers and can introduce new ones; barrier remediation generally requires addressing the source content and code.

Best practices

Combine automated testing with manual review and testing using assistive technologies such as screen readers and keyboard-only navigation to surface barriers that tools cannot detect.
Map identified barriers to the relevant WCAG success criteria and note the applicable version and conformance level, using Level AA as a commonly cited target.
Prioritize remediation of barriers that block core tasks, such as keyboard-inoperable controls or content not exposed to assistive technology, before addressing lower-impact issues.
Address barriers at their source in the content and code rather than relying on overlays or widgets that may not remove underlying obstacles.
Include people with disabilities in usability testing to identify perceptual, operational, and cognitive barriers that conformance checks alone may miss.
Document the applicable legal authority for your context (for example, Title II or Title III of the ADA, or Section 508 for covered federal contexts) and consult qualified legal counsel, recognizing that requirements evolve through regulation and case law.