Web Content Accessibility Guidelines (WCAG) addresses web content, and is used by developers, authoring tools, and accessibility evaluation tools. Something that is neat about WCAG standards is that it is backwards compatible, meaning something that is compliant with the latest version (2.1) would also pass (2.0).
WCAG is one of the most common standards for UX and Product designers as it applies to all the content. There is a simple rating system for all the guidelines under WCAG:
Level A (minimum)
The most basic web accessibility features. The website MUST satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use web documents.
Level AA (mid-range)
Deals with the biggest and most common barriers for disabled users. Website SHOULD satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
Level AAA (highest)
The highest level of web accessibility. A website MAY address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to web documents.
Certain products (such as ones for many federal agencies) may have to meet a specific level of compliance. There tends to be a grey area for private businesses, but generally the more compliant the score, the more accessible a product is to the general public.
A summary of the general WCAG 2.0 Guidelines are as follows:
(*indicates Cognitive Accessibility Success Criteria)
Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
Time-based Media: Provide alternatives for time-based media (commonly videos) such as captions, described audio or a media alternative.
Adaptable*: Create content that can be presented in different ways (for example simpler layout) without losing information or structure. This includes considerations for, proper labeling, consideration for different screen sizes etc.
Distinguishable: Make it easier for users to see and hear content including separating foreground from background. This includes common UI decisions such as contrast and text size in addition to audio considerations like background noise.
Keyboard Accessible: Make all functionality available from a keyboard. This mostly refers to the ability to move focus to and from all components of the page using a keyboard interface.
Enough Time*: Provide users enough time to read and use content. This includes moving, blinking, scrolling, or auto-updating information as well as interruptions and time-outs.
Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions. This generally means limiting flashes and motion animation to below the approved threshold.
Navigable*: Provide ways to help users navigate, find content, and determine where they are. This includes important UI decisions like information architecture, focus order, and proper titles, headers and labelling.
Input Modalities: Make it easier for users to operate functionality through various inputs beyond keyboard. An example of this is consideration for the minimum size of touch targets.
Readable*: Make text content readable and understandable. This could be as simple as identifying the human language of a page but can also include advanced standards such as identifying and explaining idioms or abbreviations.
Predictable*: Make Web pages appear and operate in predictable ways. This includes predictable interactions from components and consistent form of navigation.
Input Assistance*: Help users avoid and correct mistakes. This includes identifying input errors and providing helpful, timely and relevant instructions or suggestions.
Compatible: Maximize compatibility with current and future user agents. This is mostly work for the developers to make sure the product is built in a way that supports assistive technologies.