Digital Accessibility

Understanding accessible websites, documents, software, mobile technology, and digital information

What Digital Accessibility Means

Digital accessibility means that websites, mobile apps, software, electronic documents, and other digital tools are designed and built so that people with disabilities can perceive, understand, navigate, and interact with them. This includes people who are blind or have low vision, are Deaf or hard of hearing, have limited mobility or dexterity, or have cognitive, learning, or neurological disabilities.

Digital Accessibility and Disability Access

Digital accessibility is one part of a much broader picture of accessibility and disability access, which also includes the built environment, transportation, communication supports, and assistive technology. A website or app can be technically functional yet still create real barriers if it cannot be used with a screen reader, cannot be operated without a mouse, or does not work with the switch access, AAC, or magnification tools a person relies on. Digital accessibility work is most effective when it is considered alongside these other forms of access, not as a separate, disconnected effort.

Websites and Web Applications

Websites and web applications are often the most visible part of digital accessibility work. An accessible site is typically built with well-structured headings and semantic HTML, so that screen reader users can navigate by landmarks and sections rather than reading the page top to bottom. It can be operated fully by keyboard, with a visible focus indicator showing where a person is on the page. Images that convey meaning have text alternatives, color is never the only way information is conveyed, and text has enough contrast with its background to be read by people with low vision. Content also needs to work when a person zooms in, uses a screen magnifier, or overrides fonts and colors with their own settings. These are common technical practices, not a fixed checklist; the right approach depends on the specific site, its content, and how people actually use it.

WCAG and Accessibility Standards

The Web Content Accessibility Guidelines, or WCAG, are a set of technical standards published by the World Wide Web Consortium (W3C), the international organization that develops standards for the web. WCAG is organized around four principles: content should be perceivable, operable, understandable, and robust. It has several versions currently in use, including WCAG 2.0, 2.1, and 2.2, and three conformance levels, A, AA, and AAA, with AA being the level most commonly referenced. WCAG itself is a technical standard, not a law. It becomes a legal requirement only when a specific law or regulation adopts it, and different laws may point to different WCAG versions and levels. Later sections of this page describe some of the laws and regulations that reference WCAG.

Section 508 and Federal Technology

Section 508 of the Rehabilitation Act is a federal law that requires United States federal agencies to make their information and communication technology accessible, including websites, software, electronic documents, and hardware. It generally applies to federal agencies themselves, and to organizations that develop technology under contract with them; it does not, on its own, apply to private businesses, nonprofits, or state and local governments. The U.S. Access Board, an independent federal agency, maintains the Revised 508 Standards, which incorporate WCAG success criteria as part of their technical requirements. Because Section 508 and WCAG are connected but distinct, a product built to meet Section 508 is often, though not automatically, well aligned with WCAG as well.

ADA and Digital Accessibility

Title II of the Americans with Disabilities Act prohibits disability discrimination by state and local government entities. In 2024, the U.S. Department of Justice issued a rule under Title II specifically addressing web content and mobile applications, requiring covered entities to meet WCAG 2.1 Level AA. In April 2026, the Department of Justice issued an Interim Final Rule extending the original compliance dates, based on each entity's population in the 2020 Census: April 26, 2027 for entities with a population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments. The rule also includes five narrow exemption categories, such as archived content and preexisting documents. Title II applies to state and local government entities; it does not, on its own, extend these specific requirements to private businesses.

Accessible Documents and PDFs

Digital accessibility also extends to documents such as PDFs, Word files, and slide presentations, which are often shared on websites, by email, or alongside a webpage. A document is more accessible when it has a clear heading structure that lets a reader jump between sections rather than reading everything from top to bottom, and a logical reading order so that screen readers and other assistive technology present the content in the order it was meant to be read, which matters especially in documents with columns, text boxes, or complex layouts. Specifying the document's language helps screen readers use correct pronunciation. Meaningful images and charts benefit from short, descriptive alternative text, while purely decorative images generally do not need it. Links work best with descriptive text that explains where they lead, rather than a raw web address or the words "click here." Sufficient color contrast between text and its background helps readers with low vision or color vision differences, and tables are easier to navigate when they use real table structures with defined header rows rather than spacing or tabs used to imitate a table's appearance. Fillable forms are more accessible when each field has a label that is programmatically associated with it, and interactive content should also be operable using a keyboard alone. For PDFs specifically, the file needs to be "tagged," meaning its underlying structure identifies headings, paragraphs, lists, and other elements to assistive technology; an untagged PDF, even one that looks well organized visually, can be difficult or impossible for a screen reader to interpret correctly. Built-in accessibility checkers, such as those in Adobe Acrobat, Microsoft Word, and PowerPoint, can help identify some issues automatically, but passing an automated check does not guarantee that a document is fully accessible; a brief manual review, such as checking the document's structure or reading it with a screen reader, can catch issues that automated tools miss.

Mobile Applications and Devices

Mobile applications raise many of the same accessibility questions as websites, but through a different technical framework. Apple's iOS includes the VoiceOver screen reader, and Android includes TalkBack; both rely on developers labeling buttons, images, and controls so they can be announced correctly. Touch targets need to be large enough to activate reliably, and an app should keep working correctly when a person changes platform-level settings, such as larger text, high contrast, or reduced motion. Custom controls built specifically for an app, rather than a device's standard buttons and menus, do not automatically carry accessibility information and typically need it added manually. Apple and Google each publish their own accessibility guidelines for developers, and the ADA Title II digital accessibility rule described earlier applies to mobile apps as well as websites.

Digital Accessibility and Assistive Technology

Digital accessibility and assistive technology work together, and neither fully replaces the other. Accessible design creates digital content that assistive technology can interact with correctly, while assistive technology gives people the tools to access that content in the way that works best for them. People who are blind or have low vision may use a screen reader, such as VoiceOver, TalkBack, JAWS, or NVDA, which reads on-screen content aloud or converts it to braille, or screen magnification software that enlarges part of the screen for easier viewing. People with limited mobility or dexterity may navigate entirely by keyboard rather than a mouse or trackpad, use switch access devices that allow a website or app to be operated with one or a few simple movements, or rely on voice control software that lets them navigate and enter text by speaking commands. Others may use alternative input devices, such as head pointers, eye-tracking systems, or specialized keyboards, in place of a standard mouse and keyboard. Built-in accessibility features on phones and tablets, including screen readers, magnification, voice control, and switch control, extend many of these same capabilities to mobile devices. People who use augmentative and alternative communication, or AAC, may also rely on digital tools, including dedicated speech-generating devices or AAC apps, to communicate, and the accessibility of the websites and apps they use can affect how independently they can access information alongside everyone else. When digital content is built following accessible design practices, these tools tend to work as intended; when it is not, even well-designed assistive technology can be blocked by inaccessible code, missing labels, or content that cannot be reached by keyboard. For more detail on some of these tools, see Screen Readers, Screen Magnification and Visual Access, Switch Access, Alternative Keyboards, and Communication & AAC.

Video, Audio, and Multimedia Accessibility

Video, audio, and other multimedia content raise accessibility considerations that text alone does not. Captions provide a text version of a video's spoken dialogue and important sounds, allowing people who are Deaf or hard of hearing, and anyone in a sound-sensitive or noisy environment, to follow along; captions work best when they are accurate, synchronized with the audio, and include speaker labels and relevant sound effects rather than dialogue alone. Transcripts offer a full text version of audio or video content that can be read independently of the media player, which benefits people using screen readers as well as anyone who prefers to skim or search the content. Prerecorded video that conveys information visually, such as on-screen action, text, or graphics not described in the audio, benefits from audio description, a narration track that describes important visual details during natural pauses in dialogue. Media players themselves need to be operable by keyboard, with accessible play, pause, and volume controls, and should avoid automatically starting video or audio with sound, since unexpected sound can interfere with screen readers and be disruptive or disorienting. Content that flashes more than a few times per second can trigger seizures in people with photosensitive epilepsy and should be avoided altogether. Live video, such as webinars or streamed events, is more accessible with live captioning, and some audiences also benefit from sign language interpretation alongside captions and transcripts.

Software and Desktop Application Accessibility

Desktop and native software applications rely on operating system accessibility frameworks, such as UI Automation on Windows or the Accessibility API on macOS, which let assistive technology identify buttons, menus, and other controls and announce them correctly. Applications built with standard, built-in interface controls generally inherit a good baseline of accessibility, while custom-drawn or highly customized controls often need extra work to expose their name, role, and state to assistive technology. Every feature and function needs to be reachable and operable using only a keyboard, with a visible focus indicator that shows which control is currently active, since not everyone can use a mouse or trackpad. Error messages, notifications, and status updates should be announced to screen reader users automatically rather than only shown visually, and settings that let a person adjust text size, color contrast, or window layout can make an application usable for more people. Accessibility is often easier to build in from the start of development than to add later, since retrofitting custom controls or restructuring an interface after launch can require substantially more work.

Forms, Online Transactions, and Interactive Content

Online forms, applications, and transactions need to be usable by people who navigate with a keyboard, a screen reader, or other assistive technology rather than a mouse. Every form field needs a programmatically associated label, so a screen reader announces what information belongs in that field, and instructions or formatting requirements, such as a required date format, should be stated before the field is reached rather than only in placeholder text that disappears when typing begins. When a form is submitted with an error, the error needs to be clearly identified in text, associated with the specific field it concerns, and describe how to fix it, rather than relying on color alone to show what went wrong. Custom interactive widgets, including dropdown menus, date pickers, sliders, and expandable sections, need to be fully operable by keyboard and to communicate their name, role, and current state to assistive technology, since these custom controls do not automatically inherit the accessibility that standard HTML form elements provide. Forms and online sessions that time out for security reasons should warn the user before expiring and offer a simple way to extend the session, since some people need more time to complete a form. Visual CAPTCHAs that ask a user to identify distorted text or images can block people with visual, cognitive, or learning disabilities entirely, so an accessible alternative, such as an audio option or a non-visual verification method, needs to be available. Online transactions and checkout flows benefit from a clear, logical step order, visible progress indication, and the ability to review and correct information before final submission.

Cognitive and Learning Accessibility

Cognitive and learning disabilities affect how people process, understand, and remember information, and digital accessibility for this group often depends more on clear design and content than on any single technical feature. Simple, consistent navigation that stays in the same place across pages helps people know what to expect and reduces the mental effort needed to find something. Plain, direct language, short sentences, and clearly defined or avoided jargon make content easier to understand for people with cognitive or learning disabilities, as well as for many other readers. Breaking long content into shorter sections with descriptive headings allows a person to process information in smaller pieces and to locate a specific section again later. Giving people control over time limits, or removing them where they are not essential, matters for anyone who needs more time to read, think, or complete a task. Reducing unnecessary distractions, such as auto-playing content, unexpected pop-ups, or busy layouts, helps people who are easily distracted or overwhelmed by competing information stay focused on the task at hand. Consistent, predictable design, where similar elements look and behave the same way throughout a site or app, reduces the amount a person has to relearn on every new page. Supporting text with icons, images, or other visual cues can help some readers, while a straightforward option to have content read aloud benefits people who find listening easier than reading. No single design choice addresses every cognitive or learning disability, since needs vary widely from person to person, but clear, consistent, and uncluttered design tends to benefit this group broadly, along with many other users.

Evaluating and Testing Digital Accessibility

Evaluating digital accessibility usually involves both automated and manual methods, since each catches different kinds of problems. Automated testing tools can quickly scan a website, app, or document for certain technical issues, such as missing alternative text, insufficient color contrast, or improperly structured headings, across many pages at once. These tools are useful for catching common, well-defined problems early and often, but they can only detect a portion of possible accessibility barriers, generally estimated at less than half of all issues, since many barriers depend on context and human judgment that automated scans cannot evaluate. Manual testing complements automated tools and includes methods such as navigating an entire page or task using only a keyboard to confirm every control can be reached and operated, and using a screen reader to check that content is announced in a logical, understandable order. Reviewing color contrast and layout at different zoom levels or text sizes can reveal problems that are not obvious at a default view. Testing with real assistive technology users, when possible, often surfaces practical, real-world barriers that technical checks alone can miss, since people who use screen readers, switch access, or other tools every day bring direct experience that no automated or expert review can fully replace. Accessibility testing works best as an ongoing part of design and development, rather than a single check performed only at the end of a project, since catching issues early is generally easier and less costly than fixing them after a website, app, or document has already been built and launched.

Authoritative Resources

For more information about digital accessibility laws, standards, and technical guidance, see the following resources: the World Wide Web Consortium's WCAG Overview, Section508.gov, the U.S. Access Board's ICT Accessibility Standards, the U.S. Department of Justice's ADA Title II Web Accessibility Rule Fact Sheet, and ADA.gov's Web Accessibility Guidance.

About This Page

This page provides a national, general-audience overview of digital accessibility, including relevant laws, technical standards, and practices in the United States. It is prepared by Accessibility Clinic, Inc. as educational information only, is not legal advice, and does not guarantee that any specific website, application, or document meets a particular standard or legal requirement. Digital accessibility laws, technical standards, and best practices continue to evolve, and specific legal requirements can vary by sector, jurisdiction, and technology, so nothing on this page should be read as a determination that any particular website, app, or document is or is not compliant with a specific law or standard. This page is also not a substitute for an individualized accessibility evaluation or audit conducted by a qualified professional. For individualized guidance, consult a qualified accessibility professional or an attorney, or, for personalized support, visit AccessibilityClinic.org.