# data[].attributes.body
This person has some great examples of WAI and what makes them fit into the category of web accessibility.

# data[].attributes.attachment_link.readable_text
Last week Steven Faulkner blogged about real world ARIA landmark use. He analyzed the HTML home pages of the top 10,000 websites, looking for ARIA landmark roles. Among his findings, he discovered that 130 of these pages are using role="main".

I'm often asked for good real-world examples of accessible websites, and this seemed like a perfect starting point for identifying some promising practices. So I spent a couple of hours over the last few days opening up each of those 130 pages and giving them my 10-second web accessibility assessment, which goes something like this:

1. Use the Outline button on the WAVE toolbar to see if the web page has a halfway decent, logical heading structure. I was pleased to see that each of the 130 sites used HTML headings, but several sites had heading creep. Screen reader users benefit tremendously from good heading structure, but if a web page has too many headings, this offsets the benefits, and some of these sites have several dozen headings. If everything is a heading, nothing is a heading.

2. Again using the WAVE toolbar, check for Errors, Features, and Alerts. If there are many errors, I assume this page will not serve as a good example, and stop checking. If there are only a few errors (e.g., fewer than five) I'll check those errors and might be forgiving if they're relatively minor and are offset by good accessibility in other areas.

3. Try tabbing through the page. If there's no visible indication of focus and it's impossible to tell where I am on the page, this page will not serve as a good example.

4. If the page includes video content, try playing a video to see if it's captioned. If it isn't, this page will not serve as a good example.

If a page passes the above tests, it's worth a closer look.

It's great that at least 130 of the top pages are using ARIA landmark roles. However, of all these pages, only eleven passed my 10-second accessibility assessment, and of those only seven survived the cut to be featured in this blog post. With that, here are seven pretty good examples of accessible websites...

I didn't create an account to explore this site beyond the home page, but I like what I see on the home page. There are a few areas where the page could be improved, but here are the features I'm impressed with:

Excellent heading structure

Clean, simple interface

Video on the home page is captioned/subtitled in 14 languages..

Labels on most form fields. The lone exception is birthdate, which is divided into three fields, only the first of which has a label. I consider this a minor problem, since the birth day and birth year fields are select boxes with pre-defined options, so screen reader users aren't likely to have difficulty understanding this series of fields.

A language picker at the top of the page. When users select a new language, the page is reloaded with all text translated. The lang attribute on the <html> element also changes to reflect the new language, so screen readers will pronounce the text correctly. This is a very cool feature, and makes the site accessible to millions of people who would otherwise be excluded due to language. However, it's a little buggy. Selecting some of the languages (e.g., " Slovenčina") does not result in translated text on the home page, but does result in a changed lang attribute, so screen readers that support the selected language will pronounce the English text using the new language's speech engine, which is not likely to be intelligible.

U.S. Government Sites

It's not surprising to see U.S. government sites on this list, since they're required to be accessible via Section 508 of the Rehabilitation Act. The best of the U.S. government sites in the sample are the Center for Disease Control and Social Security Administration sites.

The accessibility of these sites is very similar. Both sites include:

A full set of ARIA landmark roles, including (in various places) banner, main, navigation, search, complementary, and contentinfo.

Good heading structure. On each site, the home page skips H2, but it's used on other pages in the site and it's arguably more important to preserve consistency throughout the site than to sacrifice that consistency in order to have a perfect logical heading structure on any one page.

Both sites include hidden same-page links at the top of the page for skipping to particular content. The CDC site includes five of these links, roughly corresponding with each of the landmark regions. These links become visible when keyboard users tab into the page. These links may ultimately be unnecessary if browsers support navigation by headings or landmarks. Screen readers already provide this support, but until browsers do so natively, non-mousers with eyesight can benefit from skip links like the ones on these government sites.

Both sites support multiple languages (English and Spanish), and both include lang="es" on the <html> element of the Spanish pages. However, on the CDC site, in addition to lang="es" the <html> element has xml:lang="en". This potentially sends mixed messages to screen readers (is this web page in Spanish or English?) JAWS 13 seems to honor lang rather than xml:lang but I don't know about other screen readers.

This site, the U.S. Government's official web portal, deserves its own entry for its effort in creating an accessible slideshow. Many of the sites in the sample had slideshow widgets, but this is one has some accessibility characteristics that most others don't have:

It is fully controllable by keyboard. Users can tab into it, visibly see which control has focus, and execute that control by pressing enter.

The slideshow auto-advances, which can be distracting for some users, but there's a pause button so users can prevent the slides from advancing, and other buttons so users can control the slides manually.

The slides are hidden with display:none and made visible with display:block, and each is marked up with aria-live="polite" so when it becomes visible, screen readers will read the new slide only when it's convenient for the user (i.e., they won't interrupt if users are actively reading something else).

Coincidentally, the day I evaluated this site they were promoting Autism Awareness Month. That's cool, and I confess it may have biased my assessment, although I really do think USA.gov has done a great job with their accessibility.

Not to be outdone by their Southern neighbors, the Canadian government site is highly accessible. The home page is a simple page, beautiful in its perfect symmetry between English and French. The default language as specified on the <html> element is English (lang="en", hey they had to pick one) but all French content is marked up with lang="fr". It's actually quite pleasing, and very Canadian, to listen to this page with JAWS as it alternates between the two languages.

Once a user selects their preferred language, the content inside the site features several exemplary features:

Extensive use of ARIA, not just for landmarks but for communicating roles and properties of other content as well. This is particularly important for making dynamic content accessible to screen reader users.

A slideshow that has comparable accessibility to that on the USA.gov site.

A keyboard-accessible dropdown menu that can be navigated not just with the tab key, but with a full keyboard model including tab, arrow keys, and escape. For more information about why this a good thing, see my recent blog post on Accessible Dropdown Menus.

Not to be outdone by either the USA or Canada, the French government site has perfect heading structure, a full set of "Aller au" ("Skip to") links, and a 100% pass rate using the WAVE accessibility checker, which means (among other things) all images have alternate text and all form fields have labels.

Another feature that I like on this site is the Écouter button:

If the user selects this button, the page is read aloud while text is highlighted. This is powered by ReadSpeaker, which I think is a really cool product. It provides improved accessibility to a vast audience of people who might not otherwise have their own assistive technology, such as people who are not native to the language of the page, or people with dyslexia or other reading challenges.

Mozilla Japan is the only Mozilla site to appear in the sample, but I could easily feature almost any Mozilla site in this review. The Firefox page in English has similar characteristics:

A clean, simple interface

Good heading structure

A keyboard-accessible dropdown menu that includes support for arrow keys in addition to tab.

My only beef with the Mozilla site is that wherever video is shown (e.g., Firefox Flix) they provide subtitles in non-English languages, but don't provide English captions. So Mozilla's videos are accessible to people who read Ligure and Shquip, but not to Deaf or Hard of Hearing folks who need English captions.

Where are all the university sites?

Since I work in higher education, I was excited to see four university sites within the 130-site sample. These sites ( Penn, Harvard, USC, and NCSU) all have reasonably accessible sites, but each had problems that regretfully kept them off my final list.

Penn in particular nearly made the cut because I really like their keyboard accessibility. It amazes me how few sites provide visible indication of keyboard focus, when it's incredibly simple to achieve (just add a style for a:focus in your style sheet). Penn did this, and consequently it's very easy for sighted keyboard users to keep track of their position as they tab through the page. They also included a keyboard-accessible dropdown menu. However, there are some dynamic features on the Penn home page that really need ARIA markup for full accessibility. They also have a few contrast problems, most notably their slideshow navigation, which is red-on-red:

Other Good Examples?

These examples may or may not be the most accessible websites on the planet, but I think they're very good. Since the first criterion for inclusion on this page is use of ARIA role="main", there are certainly plenty of other accessible sites that have not yet added this feature, as well as other accessible sites that aren't among the top 10,000.

If you know of other sites that you feel are outstanding examples of accessibility, please share those in the Comments. I'm particularly interested in sites that have made challenging content accessible, e.g., using ARIA.

# data[].attributes.attachment_link.description
Last week Steven Faulkner blogged about real world ARIA landmark use. He analyzed the HTML home pages of the top 10,000 websites, looking for ARIA landmark roles. Among his findings, he discovered that 130 of these pages are using role="main".

# 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.title
What is Web Accessibility Initiative (WAI)? | DO-IT

# data[].attributes.attachment_link.description
Web Accessibility Initiative (WAI™) is one of four domains of the World Wide Web Consortium (W3C®). W3C was created in 1994 to develop common protocols that promote the evolution of the World Wide Web and ensure its interoperability. The HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) specifications are two of the most familiar outcomes of W3C's work.

# data[].attributes.attachment_link.title
Web Accessibility | What is Web Accessibility? | Udacity

# data[].attributes.attachment_link.description
Learn online and advance your career with courses in programming, data science, artificial intelligence, digital marketing, and more. Gain in-demand technical skills. Join today!

# data[].attributes.body
Here is a quick video on what exactly web accessibility and what it does.

# data[].attributes.attachment_link.authors[].name
Department of Social Services, Australian Government

# data[].attributes.attachment_link.description
Download an audio version of this video at: http://resources.fahcsia.gov.au/videos/web_accessibility_video.mp3 Web accessibility - What does it all mean? Misconception: Web accessibility is about disability. No, Web accessibility is about universality. It's about making something that can be used by as many people as possible: different environments, different devices, elderly, different cultural backgrounds, non-English speakers, impaired abilities.

# data[].attributes.attachment_link.title
Creating Accessible Websites - American Foundation for the Blind

# data[].attributes.attachment_link.description
The Internet is tremendously important in our daily lives, including the lives of people who are blind or visually impaired. We check the news, sports, weather, and stocks engage in social networking, and make banking transactions and travel plans alongside fully sighted friends.

# data[].attributes.attachment_link.readable_text
In order to assure that websites and web applications are accessible to and usable by everyone, designers and developers must follow web accessibility guidelines. Each of the following topics address issues that are especially common on UW websites. See also our annotated list of web accessibility Tools and Resources.

Features of Accessible Websites

Additional information is available on the AccessComputing website 30 Web Accessibility Tips.

Checking a Website for Accessibility

You can go a long way toward assuring your website is accessible by following these simple steps:

1. Validate your HTML. If HTML is used incorrectly, assistive technology can have problems interpreting the page content, which can result in access problems for users. Use an HTML validator to check your code.

2. Test with a keyboard. Set your mouse aside and use the tab key to navigate through your web pages. You should be able to access all interactive features (e.g., menus, links, form fields, buttons, controls) and operate them by pressing Enter, space, arrow keys or other intuitive keystrokes. If you are unable to access some of your site's features, your site is likely to have accessibility problems.

3. Use an accessibility checker. There are several free online tools that will check your web pages for accessibility. See our Tools and Resources page for an annotated list. Also, the UW has an enterprise license for Siteimprove, a powerful tool that scans your site at regular intervals for broken links, spelling errors, and accessibility problems. More information on Siteimprove will be added to this site soon.

4. Test with users. You can test your site by simply recruiting and observing users as they interact with your site. To test for accessibility, recruit users who have a variety of skill levels and characteristics, such as those listed below under the heading What Is Accessibility?

5. Ask for help. The UW community is actively working toward the goal of full accessibility for all visitors to its websites. Since we're all working together toward this goal, there are many in the community who are happy to help. See Getting Help with Accessibility for more information.

Developing Accessible Sites Using WordPress

UW Marketing has created a UW WordPress Theme with input from UW-IT Accessible Technology Services. The theme includes a variety of accessible features, and accessibility is an ongoing consideration as features are added or updated. Therefore, web owners are encouraged to use this theme. Free WordPress hosting is also available for UW organizations.

WordPress is an easy-to-use, highly flexible content management system for creating and managing websites. Its functionality can be extended with any of several hundred widgets and plugins that are freely available. However, widgets and plug-ins can also introduce accessibility problems to a site, so you should select these very carefully. See How to Select Accessible WordPress Widgets and Plug-Ins for additional help.

What is Web Accessibility?

People who use the web have a growing variety of characteristics. As web developers, we can not assume that all our users are accessing our content using the same web browser or operating system as we are, nor can we assume they're using a traditional monitor for output, or keyboard and mouse for input. Consider these user characteristics:

Unable to see. Individuals who are blind use either audible output (products called screen readers that read web content using synthesized speech) or tactile output (a refreshable Braille device).

Has dyslexia. Individuals with learning disabilities such as dyslexia may also use audible output, along with software that highlights words or phrases as they're read aloud using synthesized speech.

Has low vision. Individuals with low vision may use screen magnification software that allows them to zoom into all or a portion of the visual screen. Many others with less-than-perfect eyesight may enlarge the font on websites using standard browser functions, such as Ctrl + in Windows browsers or Command + in Mac browsers.

Has a physical disability. Individuals with physical disabilities that effect their use of hands may be unable to use a mouse, and instead may rely exclusively on keyboard or use assistive technologies such as speech recognition, head pointers, mouth sticks, or eye-gaze tracking systems.

Unable to hear. Individuals who are deaf or hard of hearing are unable to access audio content, so video needs to be captioned and audio needs be transcribed.

Using a mobile device. Individuals who are accessing the web using a compact mobile device such as a phone face accessibility barriers, just like individuals with disabilities do. They're using a small screen and may need to zoom in or increase the font size, and they are likely to be using a touch interface rather than a mouse. Also, Apple's iPhone and iPad do not support Adobe Flash.

Limited bandwidth. Individuals may be on slow Internet connections if they're located in a rural area or lack the financial resources to access high-speed Internet. These users benefit from pages that load quickly (use graphics sparingly) and transcripts for video.

Limited time. Very busy individuals may have too little time to watch an entire video or audio recording, but can quickly access its content if a transcript is available.

An accessible website works for all of these users, and countless others not mentioned.

The W3C summarizes web accessibility nicely in their Web Content Accessibility Guidelines 2.0. WCAG 2.0 is organized into the following four key concepts:

Web content must be perceivable

Web content must be operable

Web content must be understandable

Web content must be robust

There are many possible approaches to attaining accessibility as defined by these four concepts. The pages of this website were designed to help.

The following video, produced by UW-IT Accessible Technology Services, features university web designers and developers, including several from the UW, discussing the importance of creating websites that are accessible to all users.

# data[].attributes.attachment_link.description
In order to assure that websites and web applications are accessible to and usable by everyone, designers and developers must follow web accessibility guidelines. Each of the following topics address issues that are especially common on UW websites. See also our annotated list of web accessibility Tools and Resources.

# data[].attributes.attachment_link.readable_text
Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.

Web accessibility encompasses all disabilities that affect access to the Web, including visual, auditory, physical, speech, cognitive, and neurological disabilities. The document "How People with Disabilities Use the Web" describes how different disabilities affect Web use and includes scenarios of people with disabilities using the Web.

Millions of people have disabilities that affect their use of the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. As more accessible Web sites and software become available, people with disabilities are able to use and contribute to the Web more effectively.

Web accessibility also benefits people without disabilities. For example, a key principle of Web accessibility is designing Web sites and software that are flexible to meet different user needs, preferences, and situations. This flexibility also benefits people without disabilities in certain situations, such as people using a slow Internet connection, people with "temporary disabilities" such as a broken arm, and people with changing abilities due to aging. The document " Developing a Web Accessibility Business Case for Your Organization" describes many different benefits of Web accessibility, including benefits for organizations.

The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and more. It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with disabilities. An accessible Web can also help people with disabilities more actively participate in society.

The Web offers the possibility of unprecedented access to information and interaction for many people with disabilities. That is, the accessibility barriers to print, audio, and visual media can be much more easily overcome through Web technologies.

The document " Social Factors in Developing a Web Accessibility Business Case for Your Organization" discusses how the Web impacts the lives of people with disabilities, the overlap with digital divide issues, and Web accessibility as an aspect of corporate social responsibility.

Another important consideration for organizations is that Web accessibility is required by laws and policies in some cases. WAI Web Accessibility Policy Resources links to resources for addressing legal and policy factors within organizations, including a list of relevant laws and policies around the world.

Much of the focus on Web accessibility has been on the responsibilities of Web developers. However, Web software also has a vital role in Web accessibility. Software needs to help developers produce and evaluate accessible Web sites, and be usable by people with disabilities.

One of the roles of the Web Accessibility Initiative ( WAI) is to develop guidelines and techniques that describe accessibility solutions for Web software and Web developers. These WAI guidelines are considered the international standard for Web accessibility.

The document "Essential Components of Web Accessibility" describes the different Web accessibility roles, and how specific improvements could substantially advance Web accessibility.

Making a Web site accessible can be simple or complex, depending on many factors such as the type of content, the size and complexity of the site, and the development tools and environment.

Many accessibility features are easily implemented if they are planned from the beginning of Web site development or redesign. Fixing inaccessible Web sites can require significant effort, especially sites that were not originally "coded" properly with standard XHTML markup, and sites with certain types of content such as multimedia.

The document " Implementation Plan for Web Accessibility" lists basic steps for addressing accessibility in Web projects. The Web Content Accessibility Guidelines and techniques documents provide detailed information for developers.

When developing or redesigning a site, evaluating accessibility early and throughout the development process can identify accessibility problems early when it is easier to address them. Simple techniques such as changing settings in a browser can determine if a Web page meets some accessibility guidelines. A comprehensive evaluation to determine if a site meets all accessibility guidelines is much more complex.

There are evaluation tools that help with evaluation. However, no tool alone can determine if a site meets accessibility guidelines. Knowledgeable human evaluation is required to determine if a site is accessible.

The document " Evaluating Web Sites for Accessibility" provides guidance on preliminary reviews using techniques to quickly assess some of the accessibility problems on a site. It also provides general procedures and tips for evaluating conformance to accessibility guidelines.

The WAI Web site provides guidelines and resources to help make the Web accessible. These range from very short summaries, such as " Quick Tips to Make Accessible Web Sites," to resources on managing accessibility, to detailed technical references.

Related resources for making the Web accessible are also available from other organizations, and many can be found on the Web.

Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and such. More specific definitions are available in the WCAG documents, which are linked from the Web Content Accessibility Guidelines (WCAG) Overview.

Web software includes:

People with disabilities sometimes use other software, called assistive technologies, to interact with the Web.

# data[].attributes.attachment_link.title
Introduction to Web Accessibility ◦ Web Accessibility Initiative ◦ W3C

# data[].attributes.attachment_link.description
Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.