# data[].attributes.body
Access for All: Building Digital and Document Accessibility Skills from

# data[].attributes.attachment_link.title
Access for All: Building Digital and Document Accessibility Skills – Accessible Design Technical Assistance Portal

# data[].attributes.attachment_link.description
Originally presented February-April 2026 for the Association of University Centers on Disabilities’ Community Education and Dissemination Council (CEDC) .

# data[].attributes.body
WVU CED offers a 1-hour Creating Accessible Document training as part of their CED Ally Trainings found at https://cedwvu.org/education/ on a rotating schedule.

# data[].attributes.attachment_link.readable_text
The WVU CED provides education and training opportunities to University students, pre-licensed and practicing professionals, individuals with disabilities, family members, disability advocates and policy makers. The CED aims to change the landscape of disability education through:

1. Training and technical support for individuals with disabilities and their families

2. Continuing education for professionals

3. Interdisciplinary pre-service preparation for students

Request a Training
WVU CED Ally Trainings

Highly requested trainings focused on basic information about disabilities are offered virtually, once per month, on a rotating basis. Become a WVU CED Ally by completing all four trainings and get your name/your company's name included on our WVU CED Ally List. To learn about the trainings and to register, select the titles below.

Upcoming Trainings & Events at the CED

Intellectual and Developmental Disabilities 101 (IDD 101)

Participants will increase their awareness of a variety of intellectual and developmental disabilities as well as common barriers faced by these populations.

1.5 hours

Disability Etiquette Language

Participants will identify the influence that language has on the perceptions of individuals with disabilities and differentiate between person-first language and identity-first language. Considerations across all environments will be discussed.

1.0 hours

Creating Accessible Documents

Participants will identify common accessibility features such as accessible fonts and demonstrate the use of alternative text with Microsoft PowerPoint and Microsoft Word to better support low-vision and non-sighted readers. Learners will be able to create screen-reader, dyslexia, and color blindness friendly documents.

1.0 hours

Navigating Disability Services (Birth to Adult)

Participants will identify disability systems of support for ages birth through adulthood with consideration of the educational pathway and medical pathway in the state of West Virginia.

1.0 hours

WVU CED Disability Allies

Megan Vance, MSW/LGSW, Behavioral Health Navigator with Aetna Better Health of WV

Cassandra Stewart

Susan Buskirk, Valley Healthcare System IDD Waiver Program Manager

Courtney Lambert

Heather Shockney, Chief Operations Officer, West Virginia Women Work

Heather Clevenger, BS, LSW, Service Coordinator

Roxi Moss

Christine Feller, Program Manager of Services

Shannon M. O'Dell, RN

Kristy Comer, SSM

Follow the links below to learn more about the CED's educational and training offerings. If you have any questions about trainings or educational opportunities, please reach out to the CED Education Coordinator, Dr. Tori Gilbert: tori.gilbert@hsc.wvu.edu.

# data[].attributes.attachment_link.title
Education | Center for Excellence in Disabilities

# data[].attributes.attachment_link.description
The WVU CED provides education and training opportunities to University students, pre-licensed and practicing professionals, individuals with disabilities, family members, disability advocates and policy makers.

# data[].attributes.body
"How to: Accessible Documents", available online at https://wvats.cedwvu.org/how-to-accessible-documents/ and downloadable as a PDF or plain text version.

# data[].attributes.body
WebAIM Contrast Checker

# data[].attributes.attachment_link.readable_text
Normal Text

The five boxing wizards jump quickly.

Large Text

The five boxing wizards jump quickly.

Graphical Objects and User Interface Components

Web accessibility testing can be difficult! The experts at WebAIM can audit your web site and provide a detailed report to help you remediate accessibility and WCAG compliance issues.

Learn more about WebAIM Evaluation Services

Explanation

Enter a foreground and background color in RGB hexadecimal format (e.g., #FD3 or #F7DA39) or choose a color using the color picker. The Lightness slider can be used to adjust the selected color.

WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders). WCAG Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.

Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger.

Hint: Colorzilla is an excellent tool for extracting the color value from any page element. Additionally, WAVE can analyze contrast ratios for all page text elements at once.

Use our link contrast checker to evaluate links that are identified using color alone.

# data[].attributes.body
Adobe Color Contrast Analyzer

# data[].attributes.body
Colour Contrast Analyser (CCA)

# data[].attributes.attachment_link.title
Colour Contrast Analyser (CCA) - Vispero

# data[].attributes.attachment_link.description
Colour Contrast Analyser (CCA) Use Vispero’s free color contrast checker to optimize your content – including text and visual elements – for individuals with color-blindness or low vision impairments. Current version 3.5.5. Windows Mac Home Colour Contrast Analyser (CCA) One color contrast tool for all your WCAG color checking needs The color contrast checker can […]

# data[].attributes.body
Accessible Web Color Contrast Checker

# data[].attributes.attachment_link.readable_text
How it Works

Please select a foreground color and a background color. You can enter hex color codes or use the color selector tool (aka eye dropper in the color input element). The “WCAG Compliance Information” chart will tell you if the selected colors pass conformance.

Disclaimer and Additional Info

This contrast checker attempts to calculate contrast ratios as accurately as possible. There may be situations where a color combination meets the calculated ratio; but the element being checked still fails overall. This may be due to other visually related factors (ex. hover/focus states and effects, etc).

Refer to the following links for more details and specifics on contrast success criterion requirements:

Understanding Success Criterion 1.4.3: Contrast (Minimum)

Understanding Success Criterion 1.4.11: Non-text Contrast

Understanding Success Criterion 1.4.6: Contrast (Enhanced)

WCAG Compliance Results

WCAG AA and AAA Results

Element Type | AA | AAA
Small Text | |
Large Text | |
UI Components | |

# data[].attributes.attachment_link.title
Web Accessibility Color Contrast Checker - Meet WCAG Conformance

# data[].attributes.attachment_link.description
Use our free web accessiblity color contrast checker to check your website's color combinations against WCAG A, AA, and AAA requirements.

# data[].attributes.attachment_link.readable_text
Abstract

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.

WCAG 2.1 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.

WCAG 2.1 extends Web Content Accessibility Guidelines 2.0 [], which was published as a W3C Recommendation December 2008. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0. While WCAG 2.0 remains a W3C Recommendation, the W3C advises the use of WCAG 2.1 to maximize future applicability of accessibility efforts. The W3C also encourages use of the most current version of WCAG when developing or updating Web accessibility policies.

Status of This Document
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in theW3C technical reports index at https://www.w3.org/TR/.
This is a Recommendation of WCAG 2.1 by the Accessibility Guidelines Working Group. This incorporates errata and are described in the change log. At some point additional changes might be incorporated into an Edited or Amended Recommendation.

To comment, file an issue in the W3C WCAG GitHub repository. Although the proposed Success Criteria in this document reference issues tracking discussion, the Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org ( comment archive).

This document was published by the Accessibility Guidelines Working Group as a Recommendation using the Recommendation track.

W3C recommends the wide deployment of this specification as a standard for the Web.

A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.

This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 12 June 2023 W3C Process Document.

This section is non-normative.

Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

WCAG 2.1 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.1 builds on WCAG 2.0 [], which in turn built on WCAG 1.0 [WAI-WEBCONTENT] and is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. For an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview.

Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals. Work will carry on in this area in future versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.

Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility. For an overview of how these components of Web development and interaction work together, see:

Where this document refers to WCAG 2 it is intended to mean any and all versions of WCAG that start with 2.

The individuals and organizations that use WCAG vary widely and include Web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including overall principles, general guidelines, testable success criteria and a rich collection of sufficient techniques, advisory techniques, and documented common failures with examples, resource links and code.

Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust. See also Understanding the Four Principles of Accessibility.

Guidelines - Under the principles are guidelines. The 13 guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.

Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.1 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels can be found in Understanding Levels of Conformance.

Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.1 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria and allow authors to better address the guidelines. Some advisory techniques address accessibility barriers that are not covered by the testable success criteria. Where common failures are known, these are also documented. See also Sufficient and Advisory Techniques in Understanding WCAG 2.1.

All of these layers of guidance (principles, guidelines, success criteria, and sufficient and advisory techniques) work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

The WCAG 2.1 document is designed to meet the needs of those who need a stable, referenceable technical standard. Other documents, called supporting documents, are based on the WCAG 2.1 document and address other important purposes, including the ability to be updated to describe how WCAG would be applied with new technologies. Supporting documents include:

1. How to Meet WCAG 2.1 - A customizable quick reference to WCAG 2.1 that includes all of the guidelines, success criteria, and techniques for authors to use as they are developing and evaluating Web content. This includes content from WCAG 2.0 and WCAG 2.1 and can be filtered in many ways to help authors focus on relevant content.

2. Understanding WCAG 2.1 - A guide to understanding and implementing WCAG 2.1. There is a short "Understanding" document for each guideline and success criterion in WCAG 2.1 as well as key topics.

3. Techniques for WCAG 2.1 - A collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.

4. The WCAG Documents - A diagram and description of how the technical documents are related and linked.

See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.1 supporting material, including education resources related to WCAG 2. Additional resources covering topics such as the business case for Web accessibility, planning implementation to improve the accessibility of Web sites, and accessibility policies are listed in WAI Resources.

WCAG 2.1 meets a set of requirements for WCAG 2.1 which, in turn, inherit requirements from WCAG 2.0. Requirements structure the overall framework of guidelines and ensure backwards compatibility. The Working Group also used a less formal set of acceptance criteria for success criteria, to help ensure success criteria are similar in style and quality to those in WCAG 2.0. These requirements constrained what could be included in WCAG 2.1. This constraint was important to preserve its nature as a dot-release of WCAG 2.

WCAG 2.1 was initiated with the goal to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.1 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

WCAG 2.1 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 will be able to update content to WCAG 2.1 without losing conformance with WCAG 2.0. Authors following both sets of guidelines should be aware of the following differences:

WCAG 2.1 extends WCAG 2.0 by adding new success criteria, definitions to support them, guidelines to organize the additions, and a couple additions to the conformance section. This additive approach helps to make it clear that sites which conform to WCAG 2.1 also conform to WCAG 2.0, thereby meeting conformance obligations that are specific to WCAG 2.0. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.1 as their new conformance target, even if formal obligations mention WCAG 2.0, to provide improved accessibility and to anticipate future policy changes.

The following Success Criteria are new in WCAG 2.1:

The new success criteria may reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.

In order to avoid confusion for implementers for whom backwards compatibility to WCAG 2.0 is important, new success criteria in WCAG 2.1 have been appended to the end of the set of success criteria within their guideline. This avoids the need to change the section number of success criteria from WCAG 2.0, which would be caused by inserting new success criteria between existing success criteria in the guideline, but it means success criteria in each guideline are no longer grouped by conformance level. The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this. The WCAG 2.1 Quick Reference provides ways to view success criteria grouped by conformance level, along with many other filter and sort options.

WCAG 2.1 uses the same conformance model as WCAG 2.0 with a couple additions, which is described in the Conformance section. It is intended that sites that conform to WCAG 2.1 also conform to WCAG 2.0, which means they meet the requirements of any policies that reference WCAG 2.0, while also better meeting the needs of users on the current Web.

In parallel with WCAG 2.1, the Accessibility Guidelines Working Group is developing another major version of accessibility guidelines. The result of this work is expected to be a more substantial restructuring of web accessibility guidance than would be realistic for dot-releases of WCAG 2. The work follows a research-focused, user-centered design methodology to produce the most effective and flexible outcome, including the roles of content authoring, user agent support, and authoring tool support. This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0. The Working Group might also develop additional interim versions, continuing with WCAG 2.2, on a similar short timeline to provide additional support while the major version is completed.

This section lists requirements for conformance to WCAG 2.1. It also gives information about how to make conformance claims, which are optional. Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance. Understanding Conformance includes further explanation of the accessibility-supported concept.

The main content of WCAG 2.1 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [].

In order for a Web page to conform to WCAG 2.1, all of the following conformance requirements must be satisfied:

One of the following levels of conformance is met in full.

For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.

For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.

For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.

Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)

An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.

1. when any technology that is not relied upon is turned on in a user agent,

2. when any technology that is not relied upon is turned off in a user agent, and

3. when any technology that is not relied upon is not supported by a user agent

In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:

1.4.2 - Audio Control,

2.1.2 - No Keyboard Trap,

2.3.1 - Three Flashes or Below Threshold, and

2.2.2 - Pause, Stop, Hide.

For more information, including examples, see Understanding Conformance Requirements.

Conformance is defined only for Web pages. However, a conformance claim may be made to cover one page, a series of pages, or multiple related Web pages.

Conformance claims are not required. Authors can conform to WCAG 2.1 without making a claim. However, if a conformance claim is made, then the conformance claim must include the following information:

1. Date of the claim

2. Guidelines title, version and URI "Web Content Accessibility Guidelines 2.1 at https://www.w3.org/TR/WCAG21/"

3. Conformance level satisfied: (Level A, AA or AAA)

4. A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.

The Web pages may be described by list or by an expression that describes all of the URIs included in the claim.

Web-based products that do not have a URI prior to installation on the customer's Web site may have a statement that the product would conform when installed.

5. A list of the Web content technologies relied upon.

In addition to the required components of a conformance claim above, consider providing additional information to assist users. Recommended additional information includes:

A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata.

A list of the specific technologies that are " used but not relied upon."

A list of user agents, including assistive technologies that were used to test the content.

A list of specific accessibility characteristics of the content, provided in machine-readable metadata.

Information about any additional steps taken that go beyond the success criteria to enhance accessibility.

A machine-readable metadata version of the list of specific technologies that are relied upon.

A machine-readable metadata version of the conformance claim.

Sometimes, Web pages are created that will later have additional content added to them. For example, an email program, a blog, an article that allows users to add comments, or applications supporting user-contributed content. Another example would be a page, such as a portal or news site, composed of content aggregated from multiple contributors, or sites that automatically insert content from other sources over time, such as when advertisements are inserted dynamically.

In these cases, it is not possible to know at the time of original posting what the uncontrolled content of the pages will be. It is important to note that the uncontrolled content can affect the accessibility of the controlled content as well. Two options are available:

1. A determination of conformance can be made based on best knowledge. If a page of this type is monitored and repaired (non-conforming content is removed or brought into conformance) within two business days, then a determination or claim of conformance can be made since, except for errors in externally contributed content which are corrected or removed when encountered, the page conforms. No conformance claim can be made if it is not possible to monitor or correct non-conforming content;
OR

2. A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if the following parts from uncontrolled sources were removed." In addition, the following would also be true of uncontrolled content that is described in the statement of partial conformance:

1. It is not content that is under the author's control.

2. It is described in a way that users can identify (e.g., they cannot be described as "all parts that we do not control" unless they are clearly marked as such.)

A "statement of partial conformance due to language" may be made when the page does not conform, but would conform if accessibility support existed for (all of) the language(s) used on the page. The form of that statement would be, "This page does not conform, but would conform to WCAG 2.1 at level X if accessibility support existed for the following language(s):"

abbreviation

shortened form of a word, phrase, or name where the abbreviation has not become part of the language

1. initialisms are shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase

Not defined in all languages.

SNCF is a French initialism that contains the initial letters of the Société Nationale des Chemins de Fer, the French national railroad.

ESP is an initialism for extrasensory perception.

2. acronyms are abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word

NOAA is an acronym made from the initial letters of the National Oceanic and Atmospheric Administration in the United States.

accessibility supported

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
AND

2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:

1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
OR

2. The technology is supported in a widely-distributed plug-in that is also accessibility supported;
OR

3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;
OR

4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:

does not cost a person with a disability any more than a person without a disability and

is as easy to find and obtain for a person with a disability as it is for a person without disabilities.

alternative for time-based media

ambiguous to users in general

picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII)

assistive technology (as used in this document)

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;

screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;

text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

speech recognition software, which may be used by people who have some physical disabilities;

alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);

alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone

a time-based presentation that contains only audio (no video and no interaction)

switch back and forth between two visual states in a way that is meant to draw attention

blocks of text

more than one sentence of text

initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart"

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content

changes of context

major changes that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously

Changes in context include changes of:

conformance

satisfying all the requirements of a given standard, guideline or specification

conforming alternate version

version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or

2. the non-conforming version can only be reached from the conforming version, or

3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

See Understanding Conforming Alternate Versions

content (Web content)

context-sensitive help

contrast ratio

(L1 + 0.05) / (L2 + 0.05), where

correct reading sequence

any sequence where words and paragraphs are presented in an order that does not change the meaning of the content

visual angle of about 0.0213 degrees

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display. User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

platform event that occurs when the trigger stimulus of a pointer is depressed

The down-event may have different names on different platforms, such as "touchstart" or "mousedown".

a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety, or property

if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

extended audio description

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range

functionality

processes and outcomes achievable through user action

general flash and red flash thresholds

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or

2. the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

where:

A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

A red flash is defined as any pair of opposing transitions involving a saturated red

Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing distance) on a side does not violate the thresholds.

The working definition (as of 2022) in the field for "pair of opposing transitions involving a saturated red" is a pair of opposing transitions where, one transition is either to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. [ISO_9241-391]

human language

language that is spoken, written or signed (through visual or tactile means) to communicate with humans

phrase whose meaning cannot be deduced from the meaning of the individual words and the specific words cannot be changed without losing the meaning

In Japanese, the phrase "さじを投げる" literally translates into "he throws a spoon," but it means that there is nothing he can do and finally he gives up.

In Dutch, "Hij ging met de kippen op stok" literally translates into "He went to roost with the chickens," but it means that he went to bed early.

image of text

text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect

informative

for information purposes and not required for conformance

input error

information provided by the user that is not accepted

This includes:

1. Information that is required by the Web page but omitted by the user

2. Information that is provided by the user but that falls outside the required data format or values

keyboard interface

interface used by software to obtain keystroke input

A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.

A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.

keyboard shortcut

alternative means of triggering an action by the pressing of one or more keys

large scale (text)

with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

legal commitments

link purpose

nature of the result obtained by activating a hyperlink

information captured from a real-world event and transmitted to the receiver with no more than a broadcast delay

lower secondary education level

the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education

This definition is based on the International Standard Classification of Education [].

process or technique for achieving a result

media alternative for text

motion animation

text by which software can identify a component within Web content to the user

navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface

non-text content

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language

required for conformance

on a full-screen window

stopped by user request and not resumed until requested by user

pointer input

input from a device that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact

prerecorded

information that is not live

presentation

rendering of the content in a form to be perceived by users

primary education level

six year time period that begins between the ages of five and seven, possibly without any previous education

This definition is based on the International Standard Classification of Education [].

series of user actions where each action is required in order to complete an activity

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

programmatically determined link context

additional information that can be programmatically determined from relationships with a link, combined with the link text, and presented to users in different modalities

programmatically set

set by software using methods that are supported by user agents, including assistive technologies

pure decoration

serving only an aesthetic purpose, providing no information, and having no functionality

real-time event

event that a) occurs at the same time as the viewing and b) is not completely generated by the content

relationships

meaningful associations between distinct pieces of content

relative luminance

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

The "^" character is the exponentiation operator. (Formula taken from [].)

relied upon (technologies that are)

the content would not conform if that technology is turned off or is not supported

same functionality

same relative order

satisfies a success criterion

the success criterion does not evaluate to 'false' when applied to the page

set of web pages

collection of web pages that share a common purpose and that are created by the same author, group or organization

Examples include:

a publication which is split across multiple Web pages, where each page contains one chapter or other significant section of the work. The publication is logically a single contiguous unit, and contains navigation features that enable access to the full set of pages.

an e-commerce website shows products in a set of Web pages that all share the same navigation and identification. However, when progressing to the checkout process, the template changes; the navigation and other elements are removed, so the pages in that process are functionally and visually different. The checkout pages are not part of the set of product pages.

a blog on a sub-domain (e.g. blog.example.com) which has a different navigation and is authored by a distinct set of people from the pages on the primary domain (example.com).

sign language

a language using combinations of movements of the hands and arms, facial expressions, or body positions to convey meaning

sign language interpretation

translation of one language, generally a spoken language, into a sign language

single pointer

pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures

specific sensory experience

dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

status message

change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

1. The way the parts of a Web page are organized in relation to each other; and

2. The way a collection of Web pages is organized

style property

property whose value determines the presentation (e.g. font, color, size, location, padding, volume, synthesized speech prosody) of content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille display) by user agents

Style properties can have several origins:

User agent default styles: The default style property values applied in the absence of any author or user styles. Some web content technologies specify a default rendering, others do not;

Author styles: Style property values that are set by the author as part of the content (e.g. in-line styles, author style sheets);

User styles: Style property values that are set by the user (e.g. via user agent interface settings, user style sheets)

supplemental content

additional content that illustrates or clarifies the primary content

synchronized media

technology (Web content)

mechanism for encoding instructions to be rendered, played or executed by user agents

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

text alternative

Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.

platform event that occurs when the trigger stimulus of a pointer is released

The up-event may have different names on different platforms, such as "touchend" or "mouseup".

used in an unusual or restricted way

any software that retrieves and presents Web content for users

user-controllable

data that is intended to be accessed by users

user interface component

a part of the content that is perceived by users as a single control for a distinct function

user inactivity

any continuous period of time where no user actions occur

The method of tracking will be determined by the web site or application.

a time-based presentation that contains only video (no audio and no interaction)

object in which the user agent presents content

visually customized

the font, size, color, and background can be set

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

This section contains a listing of common user interface component input purposes. The terms below are not keywords that must be used, but instead represent purposes that must be captured in the taxonomy adopted by a webpage. Where applicable, authors mark up controls with the chosen taxonomy to indicate the semantic purpose. This provides the potential for user agents and assistive technologies to apply personalized presentations that can enable more people to understand and use the content.

The list of input type purposes is based on the control purposes defined in the HTML 5.2 Autofill field section, but it is important to understand that a different technology may have some or all of the same concepts defined in its specification and only the concepts that are mapped to the meanings below are required.

The following input control purposes are intended to relate to the user of the content and pertain only to information related to that individual.

name - Full name

honorific-prefix - Prefix or title (e.g., "Mr.", "Ms.", "Dr.", "Mlle")

given-name - Given name (in some Western cultures, also known as the first name)

additional-name - Additional names (in some Western cultures, also known as middle names, forenames other than the first name)

family-name - Family name (in some Western cultures, also known as the last name or surname)

honorific-suffix - Suffix (e.g., "Jr.", "B.Sc.", "MBASW", "II")

nickname - Nickname, screen name, handle: a typically short name used instead of the full name

organization-title - Job title (e.g., "Software Engineer", "Senior Vice President", "Deputy Managing Director")

username - A username

new-password - A new password (e.g., when creating an account or changing a password)

current-password - The current password for the account identified by the username field (e.g., when logging in)

organization - Company name corresponding to the person, address, or contact information in the other fields associated with this field

street-address - Street address (multiple lines, newlines preserved)

address-line1 - Street address (one line per field, line 1)

address-line2 - Street address (one line per field, line 2)

address-line3 - Street address (one line per field, line 3)

address-level4 - The most fine-grained administrative level, in addresses with four administrative levels

address-level3 - The third administrative level, in addresses with three or more administrative levels

address-level2 - The second administrative level, in addresses with two or more administrative levels; in the countries with two administrative levels, this would typically be the city, town, village, or other locality within which the relevant street address is found

address-level1 - The broadest administrative level in the address, i.e., the province within which the locality is found; for example, in the US, this would be the state; in Switzerland it would be the canton; in the UK, the post town

country - Country code

country-name - Country name

postal-code - Postal code, post code, ZIP code, CEDEX code (if CEDEX, append "CEDEX", and the dissement, if relevant, to the address-level2 field)

cc-name - Full name as given on the payment instrument

cc-given-name - Given name as given on the payment instrument (in some Western cultures, also known as the first name)

cc-additional-name - Additional names given on the payment instrument (in some Western cultures, also known as middle names, forenames other than the first name)

cc-family-name - Family name given on the payment instrument (in some Western cultures, also known as the last name or surname)

cc-number - Code identifying the payment instrument (e.g., the credit card number)

cc-exp - Expiration date of the payment instrument

cc-exp-month - Month component of the expiration date of the payment instrument

cc-exp-year - Year component of the expiration date of the payment instrument

cc-csc - Security code for the payment instrument (also known as the card security code (CSC), card validation code (CVC), card verification value (CVV), signature panel code (SPC), credit card ID (CCID), etc)

cc-type - Type of payment instrument

transaction-currency - The currency that the user would prefer the transaction to use

transaction-amount - The amount that the user would like for the transaction (e.g., when entering a bid or sale price)

language - Preferred language

bday - Birthday

bday-day - Day component of birthday

bday-month - Month component of birthday

bday-year - Year component of birthday

sex - Gender identity (e.g., Female, Fa'afafine)

url - Home page or other Web page corresponding to the company, person, address, or contact information in the other fields associated with this field

photo - Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field

tel - Full telephone number, including country code

tel-country-code - Country code component of the telephone number

tel-national - Telephone number without the country code component, with a country-internal prefix applied if applicable

tel-area-code - Area code component of the telephone number, with a country-internal prefix applied if applicable

tel-local - Telephone number without the country code and area code components

tel-local-prefix - First part of the component of the telephone number that follows the area code, when that component is split into two components

tel-local-suffix - Second part of the component of the telephone number that follows the area code, when that component is split into two components

tel-extension - Telephone number internal extension code

email - E-mail address

impp - URL representing an instant messaging protocol endpoint (for example, "aim:goim?screenname=example" or "xmpp:fred@example.net")

This section shows changes for WCAG 2.1 since its publication as a W3C Recommendation. These changes are also recorded as errata.

Changes since the W3C Recommendation of 05 June 2018:

In the Status of This Document the paragraph beginning "This document has been reviewed by W3C Members..." appears twice. The first instance of this paragraph has been removed.

In the Introduction, several (but not all) references to "WCAG 2.0" has been changed to "WCAG 2.1".

In the 0.5.2 Numbering in WCAG 2.1, the words "critera" and "ccriteria" have been changed to "criteria".

In 1.4.10 Reflow, the first note had a supernumary "Note" indicator which has been removed.

In 1.4.13 Content on Hover or Focus, the word "dismissable" has been changed to "dismissible".

In 4. Robust, repetition of the word "by" has been removed.

In 5.2.2 Full pages, the third note began with "New" which has been removed.

In 5.3.1 Required Components of a Conformance Claim the editorial note "In WCAG 2.0 this was a dated URI, which may need to be adjusted when this becomes a Rec." has been removed.

In the definition for keyboard interface, the second (of three) note has been changed to be an example of the first note, leaving only two actual notes.

In the definition for technology, the third note has been changed to be an example.

In 7. Input Purposes for User Interface Components, the word "county" has been changed to "country".

In 1.3.4 Orientation, the note referencing "binary display orientation" has been clarified to read "content is not necessarily restricted to landscape or portrait display orientation".

In a note in the definition of accessibility supported, references to "Conformance Criterion" were changed to "Conformance Requirement".

In the definition of relative luminance, the red threshold was updated from 0.03928 to 0.04045.

In 4.1.1 Parsing one note was deleted, and two notes were added, including: "This Success Criterion should be considered as always satisfied for any content using HTML or XML."

The full commit history to WCAG 2.1 is available.

This section is non-normative.
Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page.

Jake Abma (Invited Expert)

Shadi Abou-Zahra (W3C)

Chuck Adams (Oracle Corporation)

Amani Ali (Nomensa)

Jim Allan (Invited Expert)

Paul Adam (Deque Systems, Inc.)

Christopher Auclair (VitalSource | Ingram Content Group)

Jon Avila (Level Access)

Tom Babinszki (IBM Corporation)

Bruce Bailey (U.S. Access Board)

Renaldo Bernard (University of Southampton)

Chris Blouch (Level Access)

Denis Boudreau (Deque Systems, Inc.)

Judy Brewer (W3C)

Shari Butler (Pearson plc)

Thaddeus Cambron (Invited Expert)

Alastair Campbell (Nomensa)

Laura Carlson (Invited Expert)

Louis Cheng (Google)

Pietro Cirrincione (Invited Expert)

Vivienne Conway (Web Key IT Pty Ltd)

Michael Cooper (W3C)

Jennifer Delisi (Invited Expert)

Romain Deltour (DAISY Consortium)

Wayne Dick (Knowbility, Inc)

Chaohai Ding (University of Southampton)

Kim Dirks (Thomson Reuters)

Shwetank Dixit (BarrierBreak Technologies)

Anthony Doran (TextHelp)

E.A. Draffan (University of Southampton)

Eric Eggert (W3C)

Michael Elledge (Invited Expert)

David Fazio (Invited Expert)

Wilco Fiers (Deque Systems, Inc.)

Detlev Fischer (Invited Expert)

John Foliot (Deque Systems, Inc.)

Matt Garrish (DAISY Consortium)

Alistair Garrison (Level Access)

Michael Gower (IBM Corporation)

Jon Gunderson

Markku Hakkinen (Educational Testing Service)

Katie Haritos-Shea (Knowbility, Inc)

Andy Heath (Invited Expert)

Shawn Henry (W3C)

Thomas Hoffman (Educational Testing Service)

Sarah Horton (The Paciello Group, LLC)

Stefan Johansson (Invited Expert)

Marc Johlic (IBM Corporation)

Rick Johnson (VitalSource | Ingram Content Group)

Crystal Jones (Microsoft Corporation)

Andrew Kirkpatrick (Adobe)

John Kirkwood (Invited Expert)

Jason Kiss (Department of Internal Affairs, New Zealand Government)

Maureen Kraft (IBM Corporation)

JaEun Ku (University of Illinois at Urbana-Champaign)

Patrick Lauke (The Paciello Group, LLC)

Shawn Lauriat (Google, Inc.)

Steve Lee (Invited Expert)

Alex Li (Microsoft Corporation)

Chris Loiselle (Invited Expert)

Greg Lowney (Invited Expert)

Adam Lund (Thomson Reuters)

David MacDonald (Invited Expert)

Erich Manser (IBM Corporation)

Kurt Mattes (Deque Systems, Inc.)

Scott McCormack (Level Access)

Chris McMeeking (Deque Systems, Inc.)

Jan McSorley (Pearson plc)

Neil Milliken (Unify Software and Solutions)

Rachael Montgomery (Invited Expert)

Mary Jo Mueller (IBM Corporation)

Brooks Newton (Thomson Reuters)

James Nurthen (Oracle Corporation)

Joshue O Connor (Invited Expert)

Sailesh Panchang (Deque Systems, Inc.)

Charu Pandhi (IBM Corporation)

Kim Patch (Invited Expert)

Melanie Philipp (Deque Systems, Inc.)

Mike Pluke (Invited Expert)

Ian Pouncey (The Paciello Group, LLC)

Ruoxi Ran (W3C)

Stephen Repsher (Invited Expert)

Jan Richards (Invited Expert)

John Rochford (Invited Expert)

Marla Runyan (Invited Expert)

Stefan Schnabel (SAP SE)

Ayelet Seeman (Invited Expert)

Lisa Seeman-Kestenbaum (Invited Expert)

Glenda Sims (Deque Systems, Inc.)

Avneesh Singh (DAISY Consortium)

David Sloan (The Paciello Group, LLC)

Alan Smith (Invited Expert)

Jim Smith (Unify Software and Solutions)

Andrew Somers (Invited Expert)

Adam Solomon (Invited Expert)

Jaeil Song (National Information Society Agency (NIA))

Jeanne Spellman (The Paciello Group, LLC)

Makoto Ueki (Invited Expert)

Jatin Vaishnav (Deque Systems, Inc.)

Gregg Vanderheiden (Raising the Floor)

Evangelos Vlachogiannis (Fraunhofer Gesellschaft)

Kathleen Wahlbin (Invited Expert)

Can Wang (Zhejiang University)

Léonie Watson (The Paciello Group, LLC)

Jason White (Educational Testing Service)

Mark Wilcock (Unify Software and Solutions)

Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo.

This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and now under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

# data[].attributes.attachment_link.title
Web Content Accessibility Guidelines (WCAG) 2.1

# data[].attributes.attachment_link.description
Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities.

# data[].attributes.attachment_link.readable_text
On April 24, 2024, the Federal Register published the Department of Justice's (Department) final rule updating its regulations for Title II of the Americans with Disabilities Act (ADA). The final rule has specific requirements about how to ensure that web content and mobile applications (apps) are accessible to people with disabilities.

Purpose of this fact sheet: This fact sheet gives a summary of the rule. The summary is designed to provide introductory information about the rule's requirements, particularly for people who may not have a legal background. For more information, please read the full rule. The official version of the rule is published in the Federal Register.

Title II uses the term "public entities" to describe who it applies to, but in this fact sheet, we call these "state and local governments."

A regulation, also called a "rule," is a set of requirements issued by a federal agency for laws passed by Congress. When Congress passed the ADA, it gave the Department the authority to make regulations that explain the rights and requirements for Titles II and III of the ADA. A regulation usually has two parts. The first part is regulatory text. The second part provides information about the regulatory text and what it means, which is sometimes in an appendix in the rule.

How did the Department make this rule?

The Department made this rule using a process sometimes called "notice and comment rulemaking." As part of this process, the Department published a Notice of Proposed Rulemaking (NPRM). The NPRM was basically a first draft of the regulation. It let the public know about the requirements the Department was considering and gave an opportunity for feedback.

The Department got feedback from the public on the NPRM. Based on that feedback, the Department made changes to certain parts of the rule. A description of the feedback the Department got and how it updated the rule is available in the appendix in the rule.

Who has to follow the web and mobile app accessibility requirements in the rule?

Like the rest of Title II, the rule applies to all state and local governments (which includes any agencies or departments of state or local governments) as well as special purpose districts, Amtrak, and other commuter authorities.

State and local governments that contract with other entities to provide public services for them (like non-profit organizations that run drug treatment programs on behalf of a state agency) also have to make sure that their contractors follow Title II.

Examples of state and local governments include:

State and local government offices that provide benefits and/or social services, like food assistance, health insurance, or employment services

Public schools, community colleges, and public universities

State and local police departments

State and local courts

State and local elections offices

Public hospitals and public healthcare clinics

Public parks and recreation programs

Public libraries

Public transit agencies

For more information about the responsibilities of state and local governments under Title II, visit our State and Local Governments page.

The Reasons the Department Set Specific Requirements for Web and Mobile App Accessibility

State and local governments provide many of their services, programs, and activities through websites and mobile apps. When these websites and mobile apps are not accessible, they can create barriers for people with disabilities.

For example, individuals who are blind may use a screen reader to deliver visual information on a website or mobile app as speech. A state or local government might post an image on its website that provides information to the public. If the website does not include text describing the image (sometimes called "alternative text" or "alt text"), individuals who are blind and who use screen readers may have no way of knowing what is in the image because a screen reader cannot "read" an image.

Websites and mobile apps that are not accessible can make it difficult or impossible for people with disabilities to access government services, like ordering mail-in ballots or getting tax information, that are quickly and easily available to other members of the public online. Sometimes, inaccessible websites and mobile apps can keep people with disabilities from joining or fully participating in civic or other community events like town meetings or programs at their child's school.

This rule will help make sure people with disabilities have access to state and local governments' services, programs, and activities available on websites and mobile apps. This rule will also provide state and local governments with more clarity about what they have to do to comply with the ADA.

You can find more information about why the Department made this rule in the section of the rule called "Need for Department Action."

Highlights of the Requirements in the Rule

The rule's requirements for making web content and mobile apps accessible are highlighted below. The full rule explains these requirements in more detail.

Requirement: The Web Content Accessibility Guidelines (WCAG) Version 2.1, Level AA is the technical standard for state and local governments' web content and mobile apps.

This rule sets a specific technical standard that state and local governments must follow to meet their existing obligations under Title II of the ADA for web and mobile app accessibility.

WCAG, the Web Content Accessibility Guidelines, is a set of guidelines that say what is needed for web accessibility, such as requirements for captions for videos. WCAG is developed by the World Wide Web Consortium.

You can find more information about why the Department picked WCAG 2.1, Level AA as the technical standard for state and local governments' web content and mobile apps in the rule in the section of the appendix called "Technical Standard-WCAG 2.1 Level AA."

Requirement: State and local governments' web content usually needs to meet WCAG 2.1, Level AA.

Requirement: State and local governments' mobile apps usually need to meet WCAG 2.1, Level AA

Can state and local governments provide web content or mobile apps that follow a higher standard than WCAG 2.1, Level AA?

Yes, this rule does not stop a state or local government from using designs, methods, or techniques as alternatives to WCAG 2.1, Level AA if the state or local government can prove the alternatives provide the same or more accessibility and usability. The rule refers to this as "equivalent facilitation." The rule allows this so that state and local governments can have some flexibility, while also making sure that people with disabilities still have equal access to state and local government web content and mobile apps.

Example: There may be new web accessibility standards that are developed in the future, such as WCAG Version 3.0. Under this rule, a state parks department would probably be allowed to create a new mobile app for campground reservations that meets a future standard if the standard provides the same or more accessibility and usability than WCAG 2.1, Level AA.

Exceptions: In limited situations, some kinds of web content and content in mobile apps do not have to meet WCAG 2.1, Level AA.

It is important that state and local governments can prioritize so they can choose the most important content-like current or commonly used information-to make accessible to people with disabilities quickly.

There are limited exceptions for some kinds of content that are not as frequently used or that may be particularly hard for state and local governments to address right away.

If an exception applies to certain content, it means that content would not have to meet WCAG 2.1, Level AA.

In the next section, we describe the exceptions and provide examples of how they might apply. We also give examples of when the exceptions would not apply.

The ADA requires that state and local governments must provide individuals with disabilities with effective communication, reasonable modifications, and an equal opportunity to participate in or benefit from their services, programs, and activities. So even when web content or content in mobile apps does not have to meet WCAG 2.1, Level AA, a state or local government would likely still need to provide the content to a person with a disability who needs it in a format that is accessible to them.

Summary of the Exceptions

1. Archived web content

State and local governments' websites often include a lot of content that is not currently used. This information may be outdated, not needed, or repeated somewhere else. Sometimes, this information is archived on the website.

Web content that meets all four of the following points would not need to meet WCAG 2.1, Level AA:

1. The content was created before the date the state or local government must comply with this rule, or reproduces paper documents or the contents of other physical media (audiotapes, film negatives, and CD-ROMs for example) that were created before the government must comply with this rule, AND

2. The content is kept only for reference, research, or recordkeeping, AND

3. The content is kept in a special area for archived content, AND

4. The content has not been changed since it was archived.

Example: A water quality report from 1998 that a state has stored in an "archive" section of its website and has not updated would probably fall under the exception. The exception would also probably apply to handwritten research notes or photos that go with the 1998 water quality report that the state scans and posts to its website in the archive section.

The exception does not apply unless all four points are present. If any point is missing, the content generally must meet WCAG 2.1, Level AA unless another exception applies.

What the exception does not change

2. Preexisting conventional electronic documents

Some state and local governments have a lot of old documents, like PDFs, on their website. It can sometimes be hard to make these documents meet WCAG 2.1, Level AA.

Documents that meet both of the following points usually do not need to meet WCAG 2.1, Level AA, except in some situations:

1. The documents are word processing, presentation, PDF, or spreadsheet files; AND

2. They were available on the state or local government's website or mobile app before the date the state or local government must comply with this rule.

Example: This exception would probably apply to a PDF flyer for a Thanksgiving Day parade posted on a town's website in 2018, or a Microsoft Word version of a sample ballot for a school board election posted on a school district's website in 2014.

The exception does not apply unless both points are present. Where either point is missing, the document generally needs to meet WCAG 2.1, Level AA.

When the exception does not apply: Documents that are currently being used to apply for, access, or participate in a state or local government's services, programs, or activities do not fall under the exception even if the documents were posted before the date the government has to comply with the rule.

Example: A state posted a PDF version of a business license application on its website in 2020. Members of the public still use that PDF to apply for a business license after the date the state has to comply with the rule. The exception would not apply to the application and it would usually need to meet WCAG 2.1, Level AA.

3. Content posted by a third party where the third party is not posting due to contractual, licensing, or other arrangements with a public entity

Third parties sometimes post content on state and local governments' websites or mobile apps. Third parties are members of the public or others who are not controlled by or acting for state or local governments. The state or local government may not be able to change the content third parties post.

This exception only applies to content posted by a third party. Content that is not posted by a third party usually needs to meet WCAG 2.1, Level AA. This includes:

1. Third-party content posted by the state or local government.
Example: Many state or local governments post content on their websites that is developed by an outside technology company, like calendars, scheduling tools, maps, reservations systems, and payment systems. This content wouldnot fall under the exception, and it would usually need to meet WCAG 2.1, Level AA, because it is posted by the state or local government.

2. Content posted by a state or local government's contractor or vendor.
Example: If a state or local government uses a company to design, manage, or update its website, the content the company posts for the government wouldnot fall under the exception, and it would usually need to meet WCAG 2.1, Level AA.

3. Tools and platforms that allow third parties to post content.
Example: If the state or local government has a message board platform on its website, that platform wouldnot fall under the exception, and it would usually need to meet WCAG 2.1, Level AA, because the message board was added to the website by the state or local government. However, the exception would probably apply to posts by third parties on that platform.

What the exception does not change

4. Individualized documents that are password-protected

State and local governments sometimes use password-protected websites to share documents that are for specific individuals, like a water or tax bill. It might be hard to make all of these documents accessible right away for everyone, and there might not be a person with a disability who needs access to these documents.

Documents that meet all three of the following points do not need to meet WCAG 2.1, Level AA:

1. The documents are word processing, presentation, PDF, or spreadsheet files, AND

2. The documents are about a specific person, property, or account, AND

3. The documents are password-protected or otherwise secured.

Example: A PDF version of a water bill for a person's home that is available in that person's secure account on a city's website would probably fall under the exception. However, the exception does not apply to the city's website itself.

The exception does not apply unless all three points are present. If any point is missing, the content usually must meet WCAG 2.1, Level AA. Here are some examples related to a town water bill:

What the exception does not change

5. Preexisting social media posts

For many state and local governments, making all of their past social media posts accessible may be impossible. There also may be very little use to making these old posts accessible because they were usually intended to provide updates about things happening at the time they were posted in the past.

For these reasons, social media posts made by a state or local government before the date the state or local government must comply with this rule do not need to meet WCAG 2.1, Level AA.

Example: This exception would apply to a 2017 social media post by a city's sanitation department announcing that trash collection would be delayed due to a snowstorm.

What the exception does not change

If none of the exceptions apply, do state and local governments always have to make web content and content in mobile apps meet WCAG 2.1, Level AA?

Usually, yes. But there are some situations where meeting WCAG 2.1, Level AA is not required:

Under the ADA rules, state and local governments do not need to take actions that would result in a fundamental alteration or an undue burden. This is also true for this rule. Determining what is a fundamental alteration or undue burden is different from entity to entity and sometimes from one year to the next.

For more information about fundamental alteration and undue burden, see the final rule in the section of the appendix called "Section 35.204 Duties" and the Department's State and Local Governments page.

Other Information About Complying with the Rule

Use of Conforming Alternate Versions

Sometimes a state or local government tries to have two versions of the same web content or content in a mobile app: one version that is not accessible and another version that is accessible and provides all the same information and features. The second version is called a "conforming alternate version."

Usually state and local governments should not have a main web page that is inaccessible and a separate accessible version of the same content, because people with disabilities should get equal access to that content on the same page.

Under the rule, state and local governments may use conforming alternate versions as an alternative to inaccessible content only in very limited circumstances. State and local governments are allowed to do this only when there is a technical or legal limitation that prevents inaccessible web content or mobile apps from being made accessible.

For more information about conforming alternate versions and when they are allowed, see the final rule in the section of the appendix called "Section 35.202 Conforming Alternate Versions."

What if an individual with a disability still cannot access web content and mobile apps that meet WCAG 2.1, Level AA?

What Happens If a State or Local Government Has Failed to Meet WCAG 2.1, Level AA in a Minor Way?

In some limited situations, state and local governments may be able to show that their web content or mobile apps do not meet WCAG Version 2.1, Level AA in a way that is so minor that it would not change a person with a disability's access to the content or mobile app. If the state or local government can show that, then they are not violating the rule.

State and local governments cannot use this part of the rule to avoid trying to meet WCAG 2.1, Level AA. If a state or local government's web content does not fully meet WCAG 2.1, Level AA, there are many things the government would have to prove to show that they did not violate the rule.

Example that violates the rule: A state's online renewal form does not meet WCAG 2.1, Level AA. Because of that, a person with a manual dexterity disability may need to spend a lot more time to renew their professional license online than someone without a disability. This person might also need to get help from someone who does not have a disability, give personal information to someone else, or go through a much harder and frustrating process than someone without a disability. Even if this person with a disability could ultimately renew their license online, the state would violate the rule.

Example that meets the rule: A state's web page with information about a park has text with a color contrast ratio that is 4.45:1. WCAG 2.1, Level AA requires a color contrast ratio of 4.5:1 for this text. It can be hard for some people with vision disabilities to see text on a web page if there is not enough contrast between the color of the text and the background color. But that very small difference in color contrast ratio probably would not change whether most people with vision disabilities could read the text on the website and access the information about the park. If the state can prove the difference in color contrast is so small that it would not make it harder for people with disabilities to access the information about the park, the state would not violate the rule.

For more information, see the final rule in the section of the appendix called "Section 35.205 Effect of Noncompliance That Has a Minimal Impact on Access."

How Long State and Local Governments Have to Comply with the Rule

State and local governments must make sure that their web content and mobile apps meet WCAG 2.1, Level AA within two or three years of when the rule was published on April 24, 2024, depending on their population.

You can find more information about why the Department is requiring compliance with this timeline in the rule in the section of the appendix called "Requirements by Entity Size."

State and local government size

Compliance date

0 to 49,999 persons

April 26, 2027

Special district governments

April 26, 2027

50,000 or more persons

April 24, 2026

After this time, state and local governments must continue to make sure their web content and mobile apps meet WCAG 2.1, Level AA.

ADA Information Resources

If you have questions about this rule or the ADA, you can call the Department's ADA Information Line.

Another source of information is the ADA National Network. The National Network includes ten regional centers that provide ADA technical assistance to businesses, state and local governments, and individuals with disabilities. One toll-free number connects you to the center in your region: 800-949-4232 (Voice and TTY).

# data[].attributes.attachment_link.title
Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments

# data[].attributes.attachment_link.description
The Department of Justice published a Notice of Proposed Rulemaking (NPRM) on July 20, 2023 explaining how we propose updating the regulations for Title II of the Americans with Disabilities Act (ADA) to add more specific requirements about web and mobile application accessibility.

# data[].attributes.attachment_link.title
New Digital Accessibility Rule for Public Schools, Community Colleges, and Public Universities

# data[].attributes.body
89 FR 31320 - Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities

# data[].attributes.attachment_link.title
New ADA Title II Web Accessibility Requirements Hit April 24, 2026 - Accessibility.Works

# data[].attributes.attachment_link.description
From the statehouse to local libarary » Read More

# data[].attributes.attachment_link.title
DOJ to Revisit ADA Title II and III and What It Means for Digital Accessibility | Pivotal Accessibility

# data[].attributes.attachment_link.description
Explore how the DOJ's review of ADA Title II and III may impact digital accessibility rules, compliance timelines and checklist.

# data[].attributes.attachment_link.description
PAC is the free and globally used PDF Accessibility Checker and has proven itself since 2010 as the standard tool for checking PDF accessibility.

# data[].attributes.body
Microsoft Accessible Documents

# data[].attributes.attachment_link.readable_text
Learn how to create accessible Microsoft Word documents that conform to the Revised 508 Standards.

Microsoft Word

Guidance developed by the Accessible Electronic Documents Community of Practice (AED COP).

Training Videos

How to Make an Accessible Document in Microsoft Word

The Accessible Electronic Document Community of Practice (AED CoP) created this series of videos to explain and demonstrate the minimum steps needed to ensure your Microsoft Word document is Section 508 conformant.

Duration 59m 21s | 14-Part Video Series

Tips

Save documents as .docx format to preserve accessibility features. Other formats that can be produced by Microsoft Word (RTF, DOC, TXT, and ODF) may not be accessible.

Develop reusable accessible design templates to reduce the level of effort to create accessible electronic content.
Follow responsive design principles that support accessibility on different types of devices.

Advocate for the use of authoring tools and document converters that enable users to easily create accessible documents. Where possible, upgrade existing tools (e.g., Microsoft Office or Adobe Acrobat) to the latest version. Benefits include:

Authoring and evaluation features that make it easier to create accessible documents;

Conformance to requirements for software-authoring tools requirement in the Revised 508 standards.

Agency-Developed Guidance

The resources in this section were developed by federal agencies and shared here for your convenience. Note, much of this guidance predates the [Revised 508 Standards][1].

Reviewed/Updated: January 2025

# data[].attributes.attachment_link.description
Information about the Section508.gov website, GSA's Government-wide IT Accessibility Team, and guidance to Federal agencies on accessible information and communication technology (ICT).

# data[].attributes.body
Electronic Documents Overview

# data[].attributes.attachment_link.description
Discover Section 508 accessibility requirements for electronic documents like PDFs, Word, Excel, and PowerPoint, ensuring federal content is usable by all

# data[].attributes.body
Creating Accessible PDFs

# data[].attributes.attachment_link.description
Information about the Section508.gov website, GSA’s Government-wide IT Accessibility Team, and guidance to Federal agencies on accessible information and communication technology (ICT).

# data[].attributes.body
Create Accessible Digital Products

# data[].attributes.attachment_link.readable_text
​ Federal agencies are responsible for ensuring their information and services are accessible to persons with disabilities. The Revised 508 Standards include not just IT tools and systems, but electronic content such as documents, web pages, presentations, social media content, blogs, and certain emails.

​

# data[].attributes.attachment_link.description
​ Federal agencies are responsible for ensuring their information and services are accessible to persons with disabilities. The Revised 508 Standards include not just IT tools and systems, but electronic content such as documents, web pages, presentations, social media content, blogs, and certain emails. ​

# data[].attributes.body
Create Accessible Software and Websites

# data[].attributes.attachment_link.description
Section508.gov is the official U.S. government resource for ensuring digital accessibility compliance with Section 508 of the Rehabilitation Act (29 U.S.C. 794d). It offers comprehensive guidance, tools, and training to help federal agencies and vendors create accessible information and communication technology (ICT) for individuals with disabilities.

# data[].attributes.body
Test for Accessibility

# data[].attributes.attachment_link.description
Learn Section 508 accessibility testing lifecycle, methods, and tools for electronic documents, hardware, software, and websites.

# data[].attributes.attachment_link.readable_text
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:

is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and

has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

Exceptions:

Note 1: What is perceived as the user interface component or sub-component (to determine enclosure or size) depends on its visual presentation. The visual presentation includes the component's visible content, border, and component-specific background. It does not include shadow and glow effects outside the component's content, background, or border.

Note 2: Examples of sub-components that may receive a focus indicator are menu items in an opened drop-down menu, or focusable cells in a grid.

Note 3: Contrast calculations can be based on colors defined within the technology (such as HTML, CSS and SVG). Pixels modified by user agent resolution enhancements and anti-aliasing can be ignored.

# data[].attributes.attachment_link.description
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following: is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

# data[].attributes.attachment_link.description
WCAG 2.0 establishes a set of Success Criteria to define conformance to the WCAG 2.0 Guidelines. A Success Criterion is a testable statement that will be either true or false when applied to specific Web content.

# data[].attributes.body
ANDI, the accessibility and Section 508 compliance testing tool.

# data[].attributes.attachment_link.description
ANDI accessibility test tool. A free tool to test websites for accessibility.

# data[].attributes.attachment_link.readable_text
WAVE ® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content. Our philosophy is to focus on issues that we know impact end users, facilitate human evaluation, and to educate about web accessibility.

WAVE Browser Extensions

You can use the online WAVE tool by entering a web page address (URL) in the field above. WAVE Chrome, Firefox, and Edge browser extensions are available for testing accessibility directly within your web browser - handy for checking password protected, locally stored, or highly dynamic pages.

WAVE API and Testing Engine

The WAVE subscription API and Stand-alone WAVE API and Testing Engine are powerful tools for easily collecting accessibility test data on many pages. The stand-alone API and Testing Engine can be integrated into your infrastructure for testing intranet, non-public, and secure pages, including in continuous integration processes.

Accessibility IMpact (AIM) Report

Your Accessibility IMpact (AIM) assessment report provides detailed WAVE test data, your site's AIM score (a measure of end user impact compared to web pages generally and as determined by human testers), and expert manual test results to give you insights into the accessibility of your web site for users with disabilities.

Need more than one page at a time?

Our friends at provide an enterprise-level web accessibility evaluation system based on WAVE that gives site-wide monitoring and reporting over time.

Learn more at pope.tech.

# data[].attributes.attachment_link.description
WAVE ® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content.

# data[].attributes.attachment_link.title
WVU CED Social Media Accessibility Best Practices 2026_copy for sharing

# data[].attributes.attachment_link.readable_text
Mit PAVE machen Sie Ihre PDF-Dokumente barrierefrei, damit sie gängige Vorlese-Programme korrekt interpretieren können. Die visuelle Darstellung Ihres PDFs bleibt dabei unverändert. Das ICT-Accessibility Lab der ZHAW School of Engineering hat PAVE entwickelt und stellt es für den Eigengebrauch kostenlos zur Verfügung. Probieren Sie es aus! Falls Sie grosse Mengen an PDFs barrierefrei machen wollen, nehmen Sie bitte Kontakt mit uns auf.

1. Laden Sie Ihr PDF-Dokument auf PAVE hoch.
Achtung: Die maximal zulässige Dateigrösse beträgt 5 Megabytes.

2. PAVE nimmt die automatisch durchführbaren Korrekturen direkt vor.

3. Führen Sie die restlichen Korrektur-Vorschläge in PAVE einfach selber durch.

4. Laden Sie das nun barrierefreie PDF-Dokument herunter. Das PDF-Dokument bleibt auf dem PAVE-Server maximal 3 Wochen gespeichert, wenn Sie es zuvor nicht manuell löschen.

PAVE starten

Haftungsausschluss

Trotz aller Sorgfalt können inhaltliche oder visuelle Änderungen am Dokument durch die Bearbeitung mit PAVE nicht vollständig ausgeschlossen werden. Es ist Sache des Benutzers, die generierten PDF-Dokumente zu prüfen. Die ZHAW übernimmt keinerlei Haftung.

Sehbehinderte können sich elektronische Textdokumente mit entsprechender Software vorlesen lassen. Das funktioniert aber nur bei PDF-Dokumenten gut, die entsprechend getagged, d.h. mit den nötigen Metainformationen versehen sind, was aber häufig nicht der Fall ist. Dieses weit verbreitete Problem ist nun auf einfache Art und Weise gelöst: machen Sie Ihre PDF-Dokumente direkt in PAVE barrierefrei.

Das ICT-Accessibility Lab hat bereits früher Plugins für das Erstellen von barrierefreien PDF-Dokumenten aus MS-Word und MS-PowerPoint entwickelt, mit denen Sie jedoch bereits bestehende PDF-Dokumente nicht barrierefrei machen können. Diese Lücke wird nun mit PAVE geschlossen.

E-Mail:

Kontakt-Details

# data[].attributes.attachment_link.title
PAVE - PDF-Barrierefreiheit Überprüfen und Verbessern

# data[].attributes.attachment_link.description
Mit PAVE machen Sie Ihre PDF-Dokumente barrierefrei, damit sie gängige Vorlese-Programme korrekt interpretieren können. Die visuelle Darstellung Ihres PDFs bleibt dabei unverändert. Das ICT-Accessibility Lab der ZHAW School of Engineering hat PAVE entwickelt und stellt es für den Eigengebrauch kostenlos zur Verfügung. Probieren Sie es aus!

# data[].attributes.attachment_link.title
AUCD Event | CEDC Access for All: Building Digital and Document Accessibility Skills – Social Media Accessibility: Creating Inclusive Online Content

# data[].attributes.attachment_link.description
All are welcome to join the CEDC on Thursday, August 20, 2026 as we continue our Access for All: Building Digital and Document Accessibility Skills series with our 3rd three-part series on Social Media Accessibility: Creating Inclusive Online Content.

# data[].attributes.headline
Social Media Accessibility Tips and Tricks

# data[].attributes.subject
Social Media Accessibility Tips and Tricks

# data[].attributes.body
Kennedy Krieger, Credit to Mindy Johnson

# data[].attributes.attachment_link.description
An introduction to accessibility and how it impacts social media and digital content.