Web accessibility for seizures and physical reactions - Accessibility

Web accessibility for seizures and physical reactions
=====================================================

This article introduces concepts behind making web content accessible for those with vestibular disorders, and how to measure and prevent content leading to seizures and/or other physical reactions.

Overview
--------

### Seizures

Seizures caused by light are known as photosensitive epilepsy. Content that flickers, flashes, or blinks can trigger photosensitive epilepsy. Web technologies that use video, animated gifs, animated pngs, animated SVGs, Canvas, and CSS or JavaScript animations are all capable of content that can induce seizures or other incapacitating physical reactions. Certain visual patterns, especially stripes, can also cause physical reactions even though they are not animated. Photosensitive epilepsy is actually a kind of "reflex epilepsy"—seizures occurring in response to a trigger. In the case of photosensitive epilepsy, seizures are triggered specifically by flashing lights, but other types of reflex epilepsies may be triggered by the act of reading, or by noises. Patterns and images can also trigger epilepsy.

The fact that static images may cause seizures and other disorders is documented in articles such as "Gamma Oscillations and photosensitive epilepsy", where it is noted "*Certain visual images, even in the absence of motion or flicker, can trigger seizures in patients with photosensitive epilepsy*". The Epilepsy Foundation, in its article, "Shedding Light on Photosensitivity, One of Epilepsy's Most Complex Conditions" talks about static images and patterns: "*Static or moving patterns of discernible light and dark stripes have the same effect as flashing lights because of the alternation of dark and bright areas."* The Epilepsy Foundation of America Working Group is able to "quantify" the problem a little: *"A pattern with the potential for provoking seizures contains clearly discernible stripes, numbering more than five light-dark pairs of stripes in any orientation*". In addition to stripes, checkered patterns have also been known to cause photosensitive seizures, according to Cedars-Sinai.

Although static images are possible as triggers, they are less consistent. The trigger that is well established and strong is flashing/strobe lights. Dr. Selim Benbadis of USF's Comprehensive Epilepsy Program notes, *"The only thing that is really documented is flashing lights, which can trigger seizures in patients with photosensitive epilepsy. Only a few types of epilepsies are photosensitive though, and the vast majority of epilepsies are not."* In addition to seizures brought about by photosensitivity, listening to certain pieces of music can also trigger what are called musicogenic seizures, although these types of seizures seem to be much more rare. For a great introduction on the topic of musicogenic seizures, visit Epilepsy Ontario's web page on Musicogenic Seizures.

Seizures and epilepsy are not the same. In its article "A Revised Definition of Epilepsy", the Epilepsy Foundation notes that "*a seizure is an event and epilepsy is the disease involving recurrent unprovoked seizures*." According to the Epilepsy Foundation's page "How Serious Are Seizures?", *"Sudden unexpected death in epilepsy (SUDEP) is likely the most common disease-related cause of death in with epilepsy. It is not frequent but it is a very real problem and people need to be aware of its risk"*.

The point is, seizures most definitely can be and are fatal, and developers and designers are incredibly important for making the web a safer place for those with sensitivities to photosensitive or musicogenic triggers.

Seizures can be fatal, but even the ones that are "only" debilitating can be of such severity that they render the user incapacitated. Other disorders, such as disorientation, nausea, vomiting, and more can also be so severe that the user is unable to function. The Epilepsy Foundation's article, "Photosensitivity and Seizures", provides a list of triggers that may cause seizures in photosensitive people; here's an excerpt from that list:

* Television screens or computer monitors due to the flicker or rolling images.
* Certain video games or TV broadcasts containing rapid flashes or alternating patterns of different colors.
* Intense strobe lights like visual fire alarms.
* Natural light, such as sunlight, especially when shimmering off water, flickering through trees or through the slats of Venetian blinds.
* Certain visual patterns, especially stripes of contrasting colors.

That same article continues that many factors must combine to trigger the photosensitive reaction. Of note is that it includes the wavelength of light as a possible factor; wavelengths in the red part of the spectrum seem to be especially problematic. In the article, "Understanding WCAG 2.0 Three Flashes or Below Threshold" notes generally that: *"Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes"* and goes on to note, very specifically that: "*People are even more sensitive to red flashing than to other colors, so a special test is provided for saturated red flashing*".

You don't even need an image or video to cause harm. A `<div>` element set to change color and luminosity at high frequency, easily done via JavaScript, can cause real harm. And, flickering can occur everywhere. For example, "spinners" commonly used to display while pages load can easily "flicker" while spinning.

Additional concerns exist for individuals with motor-skill problems. For example, the page for Trace Research & Development Center's Photosensitive Epilepsy Analysis Tool notes that *"Photosensitive seizures can be provoked by certain types of flashing in web or computer content, including mouse-overs that cause large areas of the screen to rapidly flash on and off repeatedly"*.

### Other physical reactions

Nausea, vertigo (or dizziness), and disorientation are very nonspecific symptoms associated with all kinds of diseases and not particularly suggestive of seizures (except maybe disorientation, which is seen in seizures). However, seizures are not the only adverse physical response possible from flashing, flickering, blinking, and other such stimuli. In 1997, a Japanese cartoon featured an animated "virus bomb". Some of the children watching the cartoon reacted by having seizures, others by suffering nausea, shaking, and vomiting blood. The reactions from the children were so severe, they had to be rushed to the emergency room. The physical disorders listed below are all possible consequences: each of these physical reactions may be so severe as to be incapacitating.

* Seizures
* Vestibular Disorders
* Migraines
* Nausea
* Vomiting
Flashing, blinking, & flickering
--------------------------------

Although "flashing" and "blinking" are sometimes used interchangeably, they are not the same. According to the W3C, blinking is a distraction problem, whereas flashing refers to content that occurs more than 3 times per second, and which is sufficiently large and bright. Section 508 prohibits flickering effects with a frequency greater than 3 Hz (flickers per second) and lower than 55 Hz. The Epilepsy Foundation's article "Shedding Light on Photosensitivity, One of Epilepsy's Most Complex Conditions" notes that *"Generally, flashing lights between the frequencies of five to 30 flashes per second (Hertz) are most likely to trigger seizures. In order to be safe, the consensus recommends that photosensitive individuals should not be exposed to flashes greater than three per second."* For some people, however, flashing/blinking can cause symptoms at less than 3 Hz.

It's important to note that not all flashing and blinking is bad. NASA, in its document titled, "Blinking, Flashing, and Temporal Response" notes that blinking and flashing can be powerful tools for drawing attention—as is necessary for warning buttons (this assumes that users can still see the screen while elements are flashing, which is not always true). For some users, blinking buttons also caution that they must be used sparingly, and with care. As it applies to web design, systems that alert company employees to danger by "hijacking" the screen to provide a flashing warning of emergency need to take into consideration the rate, size, and luminosity changes on the screen as these warnings are flashed.

### Flashing and flickering—how is danger quantified?

According to the article "Photic- and pattern-induced seizures: expert consensus of the Epilepsy Foundation of America Working Group", *"A flash is a potential hazard if it has luminance ≥20 cd/m2, occurs at a frequency of ≥3 Hz, and occupies a solid visual angle of ≥0.006 steradians (approximately 10% of the central visual field or 25% of screen area at typical viewing distances)."*

How far is a typical viewing distance? The recommendation considered for a typical viewing distance at the time of writing was "*the area can be taken as applying to an area >25% of the area of a television screen, assuming standard viewing distances of ≥2 m (∼9 feet)"*. Much has changed since that time, and we are now much closer to our screen.

Certain colors, and/or combinations of colors, also matter. "Certain Colors More Likely To Cause Epileptic Fits, Researchers Find" notes that *"…complexities underlying brain dynamics could be modulated by certain color combinations more than the others, for example, red-blue flickering stimulus causes larger cortical excitation than red-green or blue-green stimulus."*

### Flashing & flashing red

WCAG 2.3.1 general flash and red flash thresholds are defined as follows:

* A **general flash** is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance 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;
* A **red flash** is defined as any pair of opposing transitions involving a saturated red.

These standards are based on earlier research. In 2004, The Epilepsy Foundation of America convened a workshop developed a consensus on photosensitive seizures, stating *"A flash is a potential hazard if it has luminance at least 20 cd/m2, occurs at a frequency of least 3 Hz, and occupies a solid visual angle of at least 0.006 steradians (about 10% of the central visual field or 25% of screen area at typical viewing distances)."* The transition to or from a saturated red is important and constitutes a risk on its own: "*Irrespective of luminance, a transition to or from a saturated red is also considered a risk.*"

### Size and distance

#### How big? It depends

"Relative" size and distance both matter. According to PEAT, *"The combined area of flashes occurring concurrently occupies no more than a total of one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels."*

The point that the field of vision is an important consideration arises in the article addressing WCAG 2.3.1 continues: "*The 1024 x 768 screen is used as the reference screen resolution for the evaluation. The 341 x 256 pixel block represents a 10 degree viewport at a typical viewing distance. (The 10 degree field is taken from the original specifications and represents the central vision portion of the eye, where people are most susceptible to photo stimuli.)*"

This pixel area ratio calculates for relative size, but distance also matters.

Distance matters because it affects the total field of vision. When viewers wear ocular masks for gaming, the field of vision is likely enveloped in its entirety by the screen. WebVR is an open specification that makes it possible to experience VR in your browser, which can be experienced on phone, computer or headset. The concern about flashing images in an ocular mask is a growing one, since the mask is so close to the eyes.

The Epilepsy Society (UK), in their article, "3d Films and Virtual Reality", noted: *"With VR the images flash very quickly and generally this is too quickly to trigger a seizure in people with photosensitive epilepsy. However, the field of view is large and so more of the eye is stimulated. This means that more of the brain may be affected and this may trigger a photosensitive seizure."*

(Note that some users will not be able to see with blinking cursors, and may get migraines, motion sickness, and disorientation, although blinking cursors occupy a much smaller area of the screen.)

### Patterns, and parallax

Contrasting dark and light geometric patterns are a known culprit; stripes and checks are the best known examples. The Epilepsy Foundation of America Working Group lists how many light-dark pairs of stripes are likely to provoke seizures, and, in what conditions. If a pattern is unchanging and straight, eight lines is the maximum allowable, but if it undulates, no more than five lines.

Parallax effects can cause disorientation. Use parallax effects with caution; if you must use them, ensure the user has a control to turn them off.

"A pattern with the potential for provoking seizures contains clearly discernible stripes, numbering more than five light-dark pairs of stripes in any orientation. When the light-dark stripes of any pattern collectively subtend at the eye from the minimal-expected viewing distance a solid angle of >0.006 steradians, the luminance of the lightest stripe is >50 cd/m2, and the pattern is presented for ≥0.5 s, then the pattern should display no more than five light-dark pairs of stripes, if the stripes change direction, oscillate, flash, or reverse in contrast; if the pattern is unchanging or smoothly drifting in one direction, no more than eight stripes."

Not all is known, and even with the metrics listed above, additional factors come into play. For example, going from a smaller area to a larger one increases the likelihood that the brain responds, as well as increasing contrast, and increasing spatial frequency from a low to middle. It's also known, although the reasoning is not understood behind it, that going from simple orientations (for example, stripes) to a multiple one (for example, the checkered pattern that emerges when laying one set of stripes on top of, but perpendicular to, the original set) affects the brain.

### Colors

Understanding color is important for accessibility. See understanding colors and luminance as it relates to web accessibility and accessibility in general.

How the color relates to its background—usually framed in terms of contrast—and how drastically the color changes frame to frame in animation is important. For more on this, see Three Flashes or Below Threshold Understanding SC 2.3.1.

#### The Special Case of Red

It has been demonstrated that some colors are more likely to cause epileptic fits than others. Human physiology and psychology are affected by the color red in general. Its power to influence behavior has even been noted in animals.

* **Red Desaturation tests:** The human eye is so sensitively tuned to red that ophthalmologists set up a test using it. The Red desaturation test assesses the integrity of the optic nerve. For more information as to how an ophthalmologist uses this test, see Red Desaturation.
* **Red Environment:** Studies have shown that for those who suffer Traumatic Brain Injury, cognitive function is reduced in a red environment.

Saturated Red is a special, dangerous case, and there are special tests for it. In addition to a red environment affecting the cognitive function of those with Traumatic Brain Injury, color in the red spectrum wavelength seems to require special concern and special tests. Dr. Gregg Vanderheiden, when testing the Photosensitive Epilepsy Analysis Tool, noted that the seizure rates were much higher than expected. They found that we are much more sensitive to saturated red flashing. (See the video, The Photosensitive Epilepsy Analysis Tool.)

#### Websafe does not mean seizure-safe

Note that the color **#990000** is considered "**websafe**". That does *not* mean it is "safe for not causing seizures", it only means that the color may be "safely" reproduced accurately by the technology used to generate color on screens.

Measuring to prevent harm
-------------------------

Measuring the potential for harm is a good starting point. Factors considered within tests include color, luminosity, size, contrast, and in cases of animation, frequency. WCAG 2.1 provides guidance for evaluating content.

In August, 2004, the Epilepsy Foundation of America convened a workshop to begin to develop an expert consensus on photosensitive seizures. The following, expert, and authoritative information is from: Photic- and pattern-induced seizures: expert consensus of the Epilepsy Foundation of America Working Group.

>
> A flash is a potential hazard if it has luminance ≥20 cd/m2, occurs at a frequency of ≥3 Hz, and occupies a solid visual angle of ≥0.006 steradians (approximately 10% of the central visual field or 25% of screen area at typical viewing distances). A transition to or from saturated red also is considered a risk. A pattern with the potential for provoking seizures contains clearly discernible stripes, numbering more than five light-dark pairs of stripes in any orientation. When the light-dark stripes of any pattern collectively subtend at the eye from the minimal-expected viewing distance a solid angle of >0.006 steradians, the luminance of the lightest stripe is >50 cd/m2, and the pattern is presented for ≥0.5 s, then the pattern should display no more than five light-dark pairs of stripes, if the stripes change direction, oscillate, flash, or reverse in contrast; if the pattern is unchanging or smoothly drifting in one direction, no more than eight stripes. These principles are easier to apply in the case of fixed media, for example, a prerecorded TV show, which can be analyzed frame-by-frame, as compared with interactive media.
>
>
>

The "cd/m2" refers to candela per square meter. So for the web developer, how does this relate to measurements for color, luminance, and saturation?

The candela is a SI unit (International System of units) of luminous intensity. It's a photometric term, and photometry deals with the measurement of visible light as perceived by human eyes. Wikipedia's article on "Candela per square metre" puts it in terms of what we are familiar with as developers: on a display device, and in the RGB space. This is helpful, because there's a specific standard assumed to be used on monitors, printers, and the Internet, and it is the **sRGB** (standard Red Green Blue).

>
> As a measure of light emitted per unit area, this unit is frequently used to specify the brightness of a display device. The sRGB spec for monitors targets 80 cd/m2.[3] Typically, calibrated monitors should have a brightness of 120 cd/m2. Most consumer desktop liquid crystal displays have luminances of 200 to 300 cd/m2.[4] High-definition televisions range from 450 to about 1500 cd/m2.
>
>
>

The takeaway is that the **sRGB** color space is a common touch point between research, assessment tools, and developers, since it is easily converted from the commonly used Hex code.

### Human physiology and psychology as a consideration

Many experts work to quantify and measure to the greatest extent possible the kinds of web content that can serve as triggers for seizures. That said, it can't be forgotten that color is as much about human perception in the brain as it is the measurement of light coming from a computer screen.

In addition to the psychological variances, there are also physiological differences among us. There will be variances and nuances as to how a real human being perceives, and responds to, color and light. For example, Tom Jewett, Lecturer Emeritus of Computer Sciences at Cal State University Long Beach, notes the following concerning lightness in the HSL color scale *"…The distinction between levels of lightness is not actually linear as the HSL scale would imply; we are much more sensitive to changes in lighter values than to darker ones."*

It's important to understand that light and its measurements are linear, but human vision and human perception are not. Investigation and discussion is ongoing as to how to relate the machine measurement of light as it passes from a computer screen, through the distance to the human eye, filtered by human vision, and then manipulated through the human brain.

Even age and sex can play a role. According to the Epilepsy Foundation's article, "Shedding Light on Photosensitivity, One of Epilepsy's Most Complex Conditions", *"Children and adolescents are more prone than adults to have an abnormal response to light stimulation, and the first light-induced seizure almost always occurs before age 20".* The article follows with this statistic: *"Girls (60 percent) are more often affected than boys (40 percent), although seizures are more frequent in boys because they are more likely to be playing video games. Video games often contain potentially provocative light stimulation"*.

**User testing is very problematic**. Naturally, no one wants to subject a seizure-prone individual to user testing. It's dangerous. To that point, one of the most ethical thing that developers and designers can do is use tools that have been developed by experts in the field who have worked hand-in-hand with physicians to develop the tool. As of this writing, there are two commonly available tools that have been ethically and professionally developed by researchers and physicians for film/videos: **PEAT**, and the **Harding Test**.

### Photosensitive Epilepsy Analysis Tool (PEAT)

The Trace Research and Development Center has set a gold standard for a Photosensitive Epilepsy Analysis Tool, and they've made a point to make it ***free*** to download. PEAT can help authors determine whether animations or video in their content are likely to cause seizures. Please note the restriction on its use: ***Use of PEAT to assess material commercially produced for television broadcast, film, home entertainment, or gaming industries is prohibited. Use the Harding Test or other tools for commercial purposes.***

To get a free copy of the University of Maryland's Photosensitive Epilepsy Analysis Tool, visit the Trace Research & Development Center.

![University of Maryland College of Information Studies Photosensitive Epilepsy Analysis Tool.](/en-US/docs/Web/Accessibility/Seizure_disorders/peatversion1pt6.png)

### The Harding Test

As use of the PEAT tool is prohibited for commercial use, television programmers can use the Harding Test at HardingTest.com. The Harding Test is another gold standard. Television programmers in various countries must pass this test before being able to broadcast, so the group at HardingTest.com provides both analysis and certification of video content.

![Harding Flash and Pattern Analyzer.](/en-US/docs/Web/Accessibility/Seizure_disorders/screen_shot_2019-06-20_at_11.16.17_am.png)

Accessibility Solutions for Developers
--------------------------------------

All animations are potentially dangerous. As designers and developers our responsibility is to ensure we do no harm either intentionally or unintentionally. If we must include something that has the potential to cause harm, it is vital to prevent users from accidentally encountering the harmful content, and to provide ways for users to prevent and control animations mitigating potential harm.

### What the web developer can do

#### Do no harm

WCAG Guideline 2.3 Seizures and Physical Reactions provides an overview: *"Do not design content in a way that is known to cause seizures or physical reactions"*. Don't include animation that a user cannot control. Don't design with patterns known to cause problems. If you must include a gif or png with flashing in it, record it in a video format instead so that controls are available to the user. Give the user the ability to avoid it, turn it off, or render it less harmful.

#### Understand malice

As a developer or designer, ask yourself if strobing content really needs to be on your webpage. Even if handled properly, there are those who may download offending content from your site and weaponize it. It is believed the first documented attempt at using computers to effect physical harm via animation began Saturday, March 22, 2008: The Epilepsy Foundation's website was hacked via posts with flashing images and links falsely claiming to be helpful. Users with vestibular disorders who were seeking help from the site were affected.

A series of legal considerations are underway after journalist Kurt Eichenwald, a known epileptic, suffered a seizure after being sent an animated gif in December 2016: the flashing gif carried the message, *"You deserve a seizure for your posts"*.

#### Control exposure, control access

Controlling exposure to the page is key to ensuring that someone susceptible to seizures is not exposed to it accidentally. WCAG notes that a single object can make the entire page unusable.

If you believe you may have an image or animation that may cause seizures, control access to it by first displaying a warning about the content, and then putting it in a location where the user must opt in to it, such as clicking a button, or ensuring that the link to the page has a distinct and obvious warning.

Consider using metadata such as `<meta name="robots" content="noindex, nofollow">` so that the page is not indexed by search engines.

#### Do Not Index, Do Not Follow

By not indexing the page, the likelihood that users will stumble upon it via search will be reduced.

```html
<html lang="en">
  <head>
    <title>…</title>
    <meta name="robots" content="noindex, nofollow" />
  </head>
</html>
```

### Animated GIFs

All image types are potentially dangerous, however, animated gifs deserve special mention because of their ubiquity, and the fact that the animation speed is actually controlled within the GIF file itself.

#### Detect if a GIF is animated

* npm's animated-gif-detector allows for the ability to determine animate *as early as possible* in a given HTTP request.
* Zakirt provides a gist for animated-gif-detect.js

With animated GIFs, ensure animation is inactive until the user chooses to activate it. For example, the user must push a button or check a box in order to start the animation.

**Resources for detecting and controlling animated GIFs include:**

* RunKit Animated GIF Detector
* github.com/rubentd/gifplayer, a jQuery plugin that will help you play and stop animated gifs on your website
### Videos

As in the case of animated GIFs, the user must push a button or check a box in order to start the animation. There are many ways to do this, such as NOT adding the `autoplay` attribute to `<video controls>`, or setting `animation-play-state` to `paused` as an initial state. To see a powerful example of how this can actually work see the article by Kirupa, "Toggling Animations On and Off". Kirupa uses the `animation-play-state` in concert with `transition`, `transform`, and `prefers-reduced-motion` to create a very accessible experience under the user's control.

`animation-play-state` is a CSS property that sets whether an animation is running or paused.

```css
div {
  animation-play-state: paused;
}
```

`CSS Transitions` can be used to set the duration to zero for the initial stage of animation.

```css
div {
  transition-duration: 0s;
}
```

### Ensure the user can also stop animations as well as start them

A `<video>` element with no attributes will not play automatically, and will also have no controls. Ensure that you add the `controls` attribute to the video element so that the user can stop the video as well as start it.

```html
<video controls>
  <source src="video.mp4" type="video/mp4" />
  <source src="video.ogg" type="video/ogg" />
  Your browser does not support the video tag.
</video>
```

#### Programmatically ensure controls are available

The `HTMLMediaElement.controls` property reflects the `controls` HTML attribute, which controls whether user interface controls for playing the media item will be displayed.

##### Video

To ensure that a video has controls that a user can access, ensure that you add the word "controls" to HTML video and audio elements.

`<video controls>`

```html
<video controls>
  <source src="myVideo.mp4" type="video/mp4" />
  <source src="myVideo.webm" type="video/webm" />
  <p>
    Your browser doesn't support HTML video. Here is a
    <a href="myVideo.mp4">link to the video</a> instead.
  </p>
</video>
```

##### Audio

Taking that same example and applying it to audio:

`<audio controls>`

```html
<audio controls>
  <source src="myAudio.ogg" type="audio/ogg" />
  <source src="myAudio.mp3" type="audio/mpeg" />
  <p>
    Your browser does not support the audio element. Here is a
    <a href="myAudio.mp3">link to the audio</a> instead.
  </p>
</audio>
```

##### Audio as part of Video

Note that the audio in videos can be controlled by the `muted` content attribute, even though the content is within the `<video>` element rather than the `<audio>` element. This example is from the section on muted media attribute description from the HTML Living Standard. It explains that the video will autoplay quietly in the background until the user takes action to unmute the audio.

```html
<video src="adverts.cgi?kind=video" controls autoplay loop muted></video>
```

### Control speed

This seems obvious, but because there are so many MIME types, the mechanisms for handling them varies greatly, and for that reason there's not a one-size-fits-all solution to the problem. This is further complicated by the fact that even how files are classified complicates how they should be handled. For example, the .gif file format is usually understood to be an image, but is also considered a video file format in some circles because of its ability to be animated. For a comprehensive listing of media types, please visit IANA.org's page for Media Types.

The methods for sniffing them out is not a casual exercise. You may be interested in following the MIME Sniffing standard at whatwg.org. Just about every kind of image can be animated; how they are animated varies, and therefore, the control of the animation varies.

#### Commonly animated file types

* **Bitmap**: Animation
* **Canvas**: MDN's tutorial on Canvas has a great section on basic animations. `setInterval()` is a mainstay in Canvas animation, but it is also interesting to see how it interacts with screen refresh. See the article, "Controlling fps with requestAnimationFrame?" in which they discuss the nuts and bolts of implementing `requestAnimationFrame` against the backdrop of screen refresh.
* **GIFs (Raster)**: Tough to crack because control for their animation resides within the gif files themselves. For information about controlling the speed of gifs see W3C's "G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds)". A great Stack Overflow article on the subject is, "Can you control GIF animation with JavaScript?"
* **GIFV (Raster)**: Considered a variant, video version of GIF. The format is not standardized, and must reference a "real" video file (e.g. a .webm file) which must exist elsewhere.
* **JPG (Raster)**
* **MNG (Raster)**: Multiple-image Network Graphics is a graphics file format for animated images. Also considered by some to be a video format.
* **PNG, APNG (Raster)**: Portable Network Graphics and Animated Portable Network Graphics may both be animated.
* **SVGs (Vector)**: The MDN document, "SVG: Scalable Vector Graphics", notes that *"SVG is a text-based open Web standard. It is explicitly designed to work with other web standards such as CSS, DOM, and SMIL."* SVGs can be used as an image like in this example: `<img src="example.svg" alt="This is an image using a svg as a source">`. This means that SVG appearance and animation can be controlled through CSS keyframes and animations. For interaction with JavaScript, see the MDN documents on SVG Interfaces and Applying SVG effects to HTML content.
* **Voxel (Raster)**: Three-dimensional voxel raster graphics are employed in video games, as well as in medical imaging.

#### Text can also be animated

Translations and transformations can animate text in a div, and do harm. Although it is experimental technology, `CSSKeyframe.keyText` is being developed. Moving text can induce seizures for the same reasons that moving images do, so avoid animating your text. It's a good idea to avoid using moving text anyhow, as many screen readers cannot read moving text and it's bad user experience even for those with no vision or vestibular issues.

### CSS for animation

In the style sheet or within the `<style>` element, many options can combine together to create a powerful experience for the user. We've already mentioned the `animation` property earlier in this document. It's actually shorthand for all animation properties, including:

* `animation-play-state`
* `animation-duration` has a value of `<time>`; this is the duration an animation takes to complete one cycle. This may be specified in either seconds `(s)` or milliseconds `(ms)`. A default value of `0s` indicates no animation should occur.
* `animation-timing-function`

The animation property is already powerful on its own, but combined with other properties and queries such as `prefers-reduced-motion`, a powerful set of options can be set up for the user. Setting `animation-duration` and `transition-duration` properties to a short duration rather than setting them to `animation: none` and `transition: none`, enables a safeguard to prevent issues in any case there is a dependency on the animation to run.

### JavaScript animation

JavaScript is often used to control `<canvas>` elements and SVGs. Most JavaScript code that applies to HTML video also applies to audio. `HTMLMediaElement.playbackRate` is used to implement user controls for the playback rate for both video and audio. A value of 1.0 is default and considered normal speed; a value of 0.5 is half the speed, a value of 2.0 is twice the speed. A negative number plays the video or audio backwards. Set the playback rate property: `HTMLMediaElement.playbackRate = playbackspeed`.

document.getAnimations() is an experimental technology, and includes CSS Animations, CSS Transitions, and Web Animations. The MDN page on Document.getAnimations() provides the following code sample of how to slow down all animations on a page to half speed:

```js
document.getAnimations().forEach((animation) => {
  animation.playbackRate \*= 0.5;
});
```

#### Image sources for animation

One of the easiest ways is to start with an image that is already in existence, using it as an image source, and then animating it. Remember, you can use GIFs, JPGs, PNGs, SVGs and other file types here as an image source, as long as they are allowed file types—and sizes—in your environment. SVGs are often not allowed, due to security concerns. The MDN document, Basic animations, provides outstanding examples of this, using multiple image sources for the sun, earth, and moon, and using several canvas methods to control the speed and animation of the earth as it orbits around the sun, and the moon as it orbits around the earth. Use the codepen available with this tutorial to adjust `ctx.rotate` in the code to see how the animation is affected when changes are made.

#### If you absolutely, positively must use a flashing animation…

Make sure it has a control on it. Make sure it is turned off when the viewer first encounters it, and that a user must opt-in to see the animation.

An example of a format that has no controls available to the user is a gif file. Animation speed is controlled within the gif image itself. Converting an animated gif to video enables controls to be put on the animation, and gives the user agency. There are many free online converters available for use, such as EZGif and GIF to MP4.

#### Set user expectations

Give users a heads-up as to what will happen before they click on that link. Describe the animation that is to follow. See WCAG 2.1 Success Criterion 3.2.5 Change on Request.

#### Keep it small

If you absolutely positively must have flashing, keep it small. Generally speaking, limit the size of the flash to an area approximately 341 by 256 pixels or less. This pixel size assumes that a viewer is at a typical distance from the screen. As mentioned earlier, this size may be too big if the image is to be viewed at close range, such as in a VR headset. WebVR is an open specification that makes it possible to experience VR in your browser. WebVR can be experienced on phone, computer or headset.

If you are designing for a game or VR that uses an ocular mask, **or CAN be used by an ocular mask**, such as in Firefox Reality (a browser for virtual reality), ensure that the size of the rectangle is much smaller than 341 by 256 pixels, because the image is much closer to a user's eyes.

#### Reduce contrast

Normally, higher contrast is a good thing when it comes to accessibility. The greater the contrast of a text color to its background (technically called *luminosity contrast ratio,* according to W3.org's page on Colors with Good Contrast, the easier such content is to read. Users with low vision are especially appreciative of efforts to ensure high contrast of text against its background. When the content is animated, however, ***reducing*** contrast is actually a way to reduce the likelihood that the animated content will cause seizures. Drop the contrast ratio if three flashes within one second are detected.

The contrast ratio is defined in WCAG 2.1 as follows:

*contrast ratio*

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

* L1 is the relative luminance of the lighter of the colors, and
* L2 is the relative luminance of the darker of the colors.

It's best if you can adjust the contrast before it is uploaded or published to the web. For videos and animated GIFS, the Adobe Suite of products is a phenomenal resource for traditional images. Also for images, an online tool available is pinetools.com's Brightness and contrast online. If you intend to make animated gifs, for example, start with one that has a lower contrast ratio.

JavaScript is also an option for reducing contrast dynamically. Here's a code example from the section titled, "Example: Setting the background color of a paragraph" from the MDN document, Traversing an HTML table with JavaScript and DOM Interfaces. Notice that the color in the example is described in the **RGB** color space.

**HTML Content (link to source page)**

```html
<body>
  <input
 type="button"
 value="Set paragraph background color"
 onclick="set\_background()" />
  <p>hi</p>
  <p>hello</p>
</body>
```

**JavaScript Content (link to source page)**

```js
function set\_background() {
  // get a list of all the body elements (there will only be one),
  // and then select the zeroth (or first) such element
  myBody = document.getElementsByTagName("body")[0];

  // now, get all the p elements that are descendants of the body
  myBodyElements = myBody.getElementsByTagName("p");

  // get the second item of the list of p elements
  myP = myBodyElements[1];
  myP.style.background = "rgb(255 0 0)";
}
```

#### Avoid fully saturated reds for flashing content

As mentioned earlier in this document, the Epilepsy Foundation of America convened a workshop in August 2004 to begin to develop an expert consensus on photosensitive seizures. Among their results was the understanding that *"A flash is a potential hazard if it has luminance at least 20 cd/m2, occurs at a frequency of least 3 Hz, and occupies a solid visual angle of at least 0.006 steradians (about 10% of the central visual field or 25% of screen area at typical viewing distances). A transition to or from saturated red also is considered a risk."* They also note in that same consensus: *"Irrespective of luminance, a transition to or from a saturated red is also considered a risk."*

### Provide alternative CSS styles

With the understanding that much of animation and flashing can be controlled via CSS methods, it's important to explore ways to make alternative options available to users, and to make the control of these options convenient and visible.

#### Alternative Style Sheets

Modern browsers will display the alternate CSS available in alternate style sheets if the users know where to look for them. In some cases, the alternate styles are revealed when the users go through the View menu, in other cases they are manifested in the settings, sometimes both. Not all users know to look for these options via the browser or settings, so it's worth considering doing things the old-fashioned way, with obvious buttons or links to change the style so that users can see them. Doing so won't conflict with, or override, the browser's ability to read the alternate style sheets, or the ability of the user to set preferences in the settings.

It's important to know that certain users, such as those who rely on speech-recognition systems, often depend on legacy buttons and links because their disability prevents them from using a mouse, or to be able to take advantage of touch events on mobile tablets.

Common ways to include the alternative stylesheets into your HTML documents are to use the `<link>` element, and `@import`.

#### The `<link>` element

Use the `<link>` element, alongside with and together with the attributes of `rel="alternate stylesheet"` and for title, `title="…"` in the `<head>` section of the webpage.

```html
<head>
  <title>Home Page</title>
  <link href="main.css" rel="stylesheet" title="Default Style" />
  <link
 href="alternate1.css"
 rel="alternate stylesheet"
 title="Alternate One" />
  <link
 href="alternate2.css"
 rel="alternate stylesheet"
 title="Alternate Two" />
</head>
```

**`@import`** is also a way to incorporate style sheets, but it is not quite as well supported as the `<link>` element.

```html
<style>
 @import url(alternate1.css);
 @import url(alternate2.css);
</style>
```

By using alternate style sheets (remember to add the titles) you are setting it up for users to be able to use their browsers to choose alternate styles.

### Dynamic Style Switching

One problem with relying on the browser to reveal alternative styles is that not all users are technically savvy enough to discover the alternate styles. Or, because of their disability, are not able to. Buttons or links make it obvious that options are available to many grateful users. There's a multitude of ways to add toggle buttons to allow the user to switch to the different style sheets. That said, the use of alternative style sheets are not the only option. Another option is to manipulate the style of the page itself. According to the MDN document, Using dynamic styling information, *"where possible, it really is best practice to dynamically manipulate classes via the `className` property since the ultimate appearance of all of the styling hooks can be controlled in a single stylesheet".* One of the best examples around as to how to do this is from the W3C's page, "C29: Using a style switcher to provide a conforming alternate version".

### Extreme Cases: Text-Only Alternatives

A separate, alternative stylesheet that prevents images from being displayed is easy to make. It's a draconian solution; but it is one that is sometimes necessary for school teachers and other public servants who must serve those with extreme sensitivities. These public servants can ask their developers to develop a special alternative style sheet using `display: none`. Here's how to do it via CSS:

```css
img {
  display: none;
}
```

#### Take advantage of media queries with `<style>`

In setting up media queries, you are enabling controls by the user; these controls are made available in the browser or in the OS. See the MDN document, Accessibility: What users can do to browse more safely to see more details of how a user accesses the controls.

#### `prefers-reduced-motion`

Support for `prefers-reduced-motion` in modern browsers is growing.

```css
@media screen and (prefers-reduced-motion: reduce) {
}
@media screen and (prefers-reduced-motion) {
}
```

To see a great example of how to use the code `prefers-reduced-motion`, visit the MDN document, `prefers-reduced-motion`, or see the example below from the section on "New in Chrome 74".

```css
button {
  animation: vibrate 0.3s linear infinite both;
}

@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}
```

#### `prefers-color-scheme`

This can be useful if the ambient light API is not available. Support is emerging.

```css
@media (prefers-color-scheme: dark) {
  /\* adjust styles for dark mode \*/
}
```

#### Window.matchMedia()

There is a powerful tool available to developers via Window.matchMedia(). A great resource is MDN's document on `Window.matchMedia()`.

#### Media update feature

The more often the screen is refreshed, the more stable it appears to the human eye, and the less it "flickers". The vast majority of modern technology refreshes at a rate that does not cause problems with photosensitivity. However, not everybody is wealthy enough to be able to afford the most recent technology: older or underpowered computers can have low refresh rates. AbilityNet's Factsheet (November 2015) Computers and Epilepsy describes more of the details on refresh rates.

A very old article, Tech Republic's "Epilepsy and CRT/LCD screen flicker", had an interesting response concerning the refresh rates in Hz:

* *"This effect is noticeable, and documented, up to 70 Hz."*
* *"These studies would seem to indicate that you should stay away from refresh rates under 70 Hz, and use a rate not divisible by 10."*

Eric Bailey, of CSS-Tricks, found an innovative use the update feature which, used in combination with animation-duration or transition-duration, to conclude at a rate that is imperceptible to the human eye. In other words, Eric's techniques address the refresh-rate problem. The CSS below is from the CSS-Tricks article, " Revisiting prefers-reduced-motion, the reduced motion media query".

```css
@media screen and (prefers-reduced-motion: reduce), (update: slow) {
  \* {
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important; /\* Hat tip Nick/cssremedy (https://css-tricks.com/revisiting-prefers-reduced-motion/#comment-1700170) \*/
    transition-duration: 0.001ms !important;
  }
}
```

From W3.org's page on Media Queries 4:

The `update` media feature is used to query the ability of the output device to modify the appearance of content once it has been rendered. It has the values of "none", "slow", and "fast".

Developmental & Experimental Features
-------------------------------------

### MDN Navigator.doNotTrack

From the documentation: *"Returns the user's do-not-track setting. This is "1" if the user has requested not to be tracked by websites, content, or advertising"*.

### Media Queries Level 5

EnvironmentMQ (Planned in Media Queries Level 5)

`light-level`

`light-level` has three valid values: dim, normal, and washed. Interestingly, the specification refrains from actually defining the three levels in terms of a measurement of lux, because devices with a light sensor usually adjust the brightness of the screen automatically. The specifications also note the difference in technology, such as e-ink, which remains readable in bright daylight, versus liquid crystals, which do not.

`environment-blending`

From W3C's Draft document, Media Queries Level 5: *"The `environment-blending` media feature is used to query the characteristics of the user's display so the author can adjust the style of the document. An author might choose to adjust the visuals and/or layout of the page depending on the display technology to increase the appeal or improve legibility."*

#### User Preference Media Features (Planned in Media Queries Level 5)

User Preference Media Features in W3C Editor's Draft Media Queries Level 5 are especially promising in providing user control over media. Here are some highlights:

`inverted-colors`

According to the section, User Preference Media Features, "The `inverted-colors` media feature indicates whether the content is displayed normally, or whether colors have been inverted."

`forced-colors`

In `forced-colors-mode`, the user agent enforces the user's preferred color palette on the page, overriding the author's chosen colors. From W3C's Draft document, Media Queries Level 5 section on forced-colors: *"The forced-colors media feature is used to detect if the user agent has enabled a forced colors mode where it enforces a user-chosen limited color palette on the page".* The user will need to be made aware of this ability, and it will need to play nice with the appropriate value for the prefers-color-scheme media query.

`light-level`

From W3C's Draft document, Media Queries Level 5 section on light-level: *"The `light-level` media feature is used to query about the ambient light-level in which the device is used, to allow the author to adjust style of the document in response."* This will be a godsend to those who have motor-skills problems, or for some with cognitive difficulties, who cannot find the right "button" to change their screen settings.

prefers-contrast

From W3C's Draft document, Media Queries Level 5 section on `prefers-contrast`: *"The `prefers-contrast` media feature is used to detect if the user has requested the system increase or decrease the amount of contrast between adjacent colors. For example, many users have difficulty reading text that has a small difference in contrast to the text background and would prefer a larger contrast."* Sometimes there can be such a thing as too much contrast; a halo effect around text can occur in such situations and actually reduce legibility. Putting the amount of contrast in the user's control is a definite gift for accessibility.

#### `MediaQueryList` Interface

Section 4.2 from the CSSWG.org drafts integrates with the event loop defined in HTML. HTML for the `MediaQueryList` object. See the MDN document, MediaQueryList for more information.

#### Personalization Help and Support

The requirement for the `literal` property is taken from section 23 Non-literal Text and Images.

**Requirement:** Some users cannot understand non-literal text and icons such as metaphors, idioms etc. The `literal` property is intended to identify text or images as non-literal and allows the author to explain non-literal text and images to users.

#### Transitions (for CSS and SVG)

The following is from the Web Animations model CSSWG.org drafts

The Web Animations model is intended to provide the features necessary for expressing CSS Transitions, CSS Animations, and SVG.

See also
--------

### MDN

* Accessibility: What users can do to browse more safely
* Accessibility: Understanding color and luminance
* Applying SVG effects to HTML Content
* Basic Animations (Canvas Tutorial)
* Canvas API
* CanvasRenderingContext2D.drawImage()
* <color>
* Document Object Model
* MediaQueryList
* Using dynamic styling information
* WebGL: 2D and 3D graphics for the web
* WebVR API
### Color

* Color Tutorial: describing color Tom Jewett
* Formula to Determine Brightness of RGB color Stack Exchange Discussion Thread
* How the Color Red Influences Our Behavior Scientific American By Susana Martinez-Conde, Stephen L. Macknik on November 1, 2014
### Discussions

* Problems with WCAG 2.0 Flash Definition #553
* WCAG 2.1 Understanding 2.3.1 - missing/vague dimension definitions #585
### Epilepsy and Seizures

* Shedding Light on Photosensitivity, One of Epilepsy's Most Complex Conditions Epilepsy Foundation: *"Certain individuals are born with special sensitivity to flashing lights or contrasting visual patterns, such as stripes, grids and checkerboards. Because of this condition, their brain will produce seizure-like discharges when exposed to this type of visual stimulation."*
* Gamma oscillations and photosensitive epilepsy Current Biology Volume 27, Issue 9, 8 May 2017, Pages R336-R338: *"Certain visual images, even in the absence of motion or flicker, can trigger seizures in patients with photosensitive epilepsy."*
* Photosensitive Seizures. Cedars-Sinai "*Photosensitive seizures are triggered by flashing or flickering lights. These seizures can also be triggered by certain patterns such as stripes.*"
* Photic-and pattern-induced seizures: expert consensus of the Epilepsy Foundation of America Working Group Eplepsia 2005 Sept, 46(9):1423-5 PubMed.gov NCBI Harding G, Wilkins AJ, Erba G, Barkley GL, Fisher RS; Epilepsy Foundation of America Working Group.
### GPII

* Accessibility Master List Gregg Vanderheiden Ph.D. Editor
### Harding

Along with the PEAT tool, is generally recognized to be one of the two "gold standards" for analyzing flashes.

* Harding Flash and Pattern Analyzer
### ISO

* IEC 61966-2-2:2003(en) Multimedia systems and equipment — Colour measurement and management — Part 2-2: Colour management — Extended RGB color space — scRGB
### Photosensitive Epilepsy Analysis Tool

Along with the Harding tool, is generally recognized to be one of the two "gold standards" for analyzing flashes.

* Trace Research and Development Center
* Using PEAT To Create Seizureless Web Animations
### W3C

* CSS Color Module Level 3
* Personalization Semantics Explainer 1.0. Working Draft
* Personalization Tools 1.0 Working Draft
* Three Flashes or Below Threshold Understanding SC 2.3.1 Understanding WCAG 2.0 (Older, but contains some explanations of references made in the WCAG 2.1 criteria)
* Three Flashes or Below Threshold Understanding Success Criterion 2.3.1 Understanding WCAG 2.1
* Understanding Success Criteria 1.4.3: Contrast (Minimum)
* Web Accessibility Initiative (WAI)
* Web Animations Model W3C Working Draft
* Web Content Accessibility Guidelines (WCAG) 2.0 definition of relative luminance
* Web Content Accessibility Guidelines (WCAG) 2.1
Contributors
------------

Heartfelt thanks to Teal; Wayne Dick of the Low Vision Task Force of the W3C; Tom Jewett and Eric Eggert from Knowbility; Jim Allan of the Diagram Center; and Dr. Selim R. Benbadis, Director, Comprehensive Epilepsy Program and Clinical Neurophysiology Laboratory at USF and TGH in Tampa, Florida for their great, great assistance and discussions on this topic.

We are *all* in tremendous gratitude to the Trace Research & Development Center for making their amazing tool, the Photosensitive Epilepsy Analysis Tool (PEAT) for free.


An overview of accessible web applications and widgets - Accessibility

An overview of accessible web applications and widgets
======================================================

Most JavaScript libraries offer a library of client-side widgets that mimic the behavior of familiar desktop interfaces. Sliders, menu bars, file list views, and more can be built with a combination of JavaScript, CSS, and HTML. Since the HTML4 specification doesn't provide built-in tags that semantically describe these kinds of widgets, developers typically resort to using generic elements such as `<div>` and `<span>`. While this results in a widget that looks like its desktop counterpart, there usually isn't enough semantic information in the markup to be usable by an assistive technology.

The problem
-----------

Dynamic content on a web page can be particularly problematic for users who, for whatever reason, are unable to view the screen. Stock tickers, live twitter feed updates, progress indicators, and similar content modify the DOM in ways that an assistive technology (AT) may not be aware of. That's where ARIA comes in.

*Example 1: Markup for a tabs widget built without ARIA labeling. There's no information in the markup to describe the widget's form and function.*

```html
<!-- This is a tabs widget. How would you know, looking only at the markup? -->
<ol>
  <li id="ch1Tab">
    <a href="#ch1Panel">Chapter 1</a>
  </li>
  <li id="ch2Tab">
    <a href="#ch2Panel">Chapter 2</a>
  </li>
  <li id="quizTab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <div id="ch1Panel">Chapter 1 content goes here</div>
  <div id="ch2Panel">Chapter 2 content goes here</div>
  <div id="quizPanel">Quiz content goes here</div>
</div>
```

*Example 2: How the tabs widget might be styled visually. Users might recognize it visually, but there are no machine-readable semantics for an assistive technology.*
![Screenshot of the tabs widget](/en-US/docs/Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets/tabs_widget.png)

ARIA
----

**ARIA** enables developers to describe their widgets in more detail by adding special attributes to the markup. Designed to fill the gap between standard HTML tags and the desktop-style controls found in dynamic web applications, ARIA provides roles and states that describe the behavior of most familiar UI widgets.

**Warning:** Many of these were later added when browsers didn't fully support modern HTML features. **Developers should always prefer using the correct semantic HTML element over using ARIA**.

The ARIA specification is split up into three different types of attributes: roles, states, and properties. Roles describe widgets that aren't otherwise available in HTML 4, such as sliders, menu bars, tabs, and dialogs. Properties describe characteristics of these widgets, such as if they are draggable, have a required element, or have a popup associated with them. States describe the current interaction state of an element, informing the assistive technology if it is busy, disabled, selected, or hidden.

ARIA attributes are interpreted automatically by the browser and translated to the operating system's native accessibility APIs. So an element with role="slider" will be controlled in the same way as a native slider is controlled on the operating system.

This provides a much more consistent user experience than was possible in the previous generation of web applications, since assistive technology users can apply all of their knowledge of how desktop applications work when they are using web-based applications.

*Example 3: Markup for the tabs widget with ARIA attributes added.*

```html
<!-- Now \*these\* are Tabs! -->
<!-- We've added role attributes to describe the tab list and each tab. -->
<ol role="tablist">
  <li id="ch1Tab" role="tab">
    <a href="#ch1Panel">Chapter 1</a>
  </li>
  <li id="ch2Tab" role="tab">
    <a href="#ch2Panel">Chapter 2</a>
  </li>
  <li id="quizTab" role="tab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <!-- Notice the role and aria-labelledby attributes we've added to describe these panels. -->
  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">
    Chapter 1 content goes here
  </div>
  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">
    Chapter 2 content goes here
  </div>
  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">
    Quiz content goes here
  </div>
</div>
```

ARIA is well supported by all major browsers and many assistive technologies.

### Presentational changes

Dynamic presentational changes include using CSS to change the appearance of content (such as a red border around invalid data, or changing the background color of a checked checkbox), as well as showing or hiding content.

#### State changes

ARIA provides attributes for declaring the current state of a UI widget. Examples include (but are certainly not limited to):

`aria-checked`

Indicates the state of a checkbox or radio button.

`aria-disabled`

Indicates that an element is visible but not editable or otherwise operable.

`aria-grabbed`

Indicates the 'grabbed' state of an object in a drag-and-drop operation.

(For a full list of ARIA states, consult the ARIA list of states and properties.)

Developers should use ARIA states to indicate the state of UI widget elements and use CSS attribute selectors to alter the visual appearance based on the state changes (rather than using script to change a class name on the element).

#### Visibility changes

When content visibility is changed (i.e., an element is hidden or shown), developers should change the **`aria-hidden`** property value. The techniques described above should be used to declare CSS to visually hide an element using `display:none`.

Here is an example of a tooltip that uses **`aria-hidden`** to control the visibility of the tooltip. The example shows a simple web form with tooltips containing instructions associated with the entry fields.

In this example, the HTML for the tooltip has the form shown. Line 9 sets the **`aria-hidden`** state to `true`.

```html
<div class="text">
  <label id="tp1-label" for="first">First Name:</label>
  <input
 type="text"
 id="first"
 name="first"
 size="20"
 aria-labelledby="tp1-label"
 aria-describedby="tp1"
 aria-required="false" />
  <div id="tp1" class="tooltip" role="tooltip" aria-hidden="true">
    Your first name is optional
  </div>
</div>
```

The CSS for this markup is shown in the following code. Note that there is no custom classname used, only the status of the **`aria-hidden`** attribute on line 1.

```css
div.tooltip[aria-hidden="true"] {
  display: none;
}
```

The JavaScript to update the **`aria-hidden`** property has the form shown in the following code. Note that the script only updates the **`aria-hidden`** attribute (line 2); it does not need to also add or remove a custom classname.

```js
function showTip(el) {
  el.setAttribute("aria-hidden", "false");
}
```

### Role changes

ARIA allows developers to declare a semantic role for an element that otherwise offers incorrect or no semantics. The **`role`** of an element should not change. Instead, remove the original element and replace it with an element with the new **`role`**.

For example, consider an "inline edit" widget: a component that allows users to edit a piece of text in place, without switching contexts. This component has a "view" mode, in which the text is not editable, but is activatable, and an "edit" mode, in which the text can be edited. A developer might be tempted to implement the "view" mode using a read-only text `<input>` element and setting its ARIA **`role`** to `button`, then switching to "edit" mode by making the element writable and removing the **`role`** attribute in "edit" mode (since `<input>` elements have their own role semantics).

Do not do this. Instead, implement the "view" mode using a different element altogether, such as a `<div>` or `<span>` with a **`role`** of `button`, and the "edit" mode using a text `<input>` element.

### Asynchronous content changes

**Note:** Under construction. See also Live Regions

Keyboard navigation
-------------------

Often times developers overlook support for the keyboard when they create custom widgets. To be accessible to a variety of users, all features of a web application or widget should also be controllable with the keyboard, without requiring a mouse. In practice, this usually involves following the conventions supported by similar widgets on the desktop, taking full advantage of the Tab, Enter, Spacebar, and arrow keys.

Traditionally, keyboard navigation on the web has been limited to the Tab key. A user presses Tab to focus each link, button, or form on the page in a linear order, using Shift-Tab to navigate backwards. It's a one-dimensional form of navigation—forward and back, one element at a time. On fairly dense pages, a keyboard-only user often has to press the Tab key dozens of times before accessing the needed section. Implementing desktop-style keyboard conventions on the web has the potential to significantly speed up navigation for many users.

Here's a summary of how keyboard navigation should work in an ARIA-enabled web application:

* The Tab key should provide focus to the widget as a whole. For example, tabbing to a menu bar **should NOT** put focus on the menu's first element.
* The arrow keys should allow for selection or navigation within the widget. For example, using the left and right arrow keys should move focus to the previous and next menu items.
* When the widget is not inside a form, both the Enter and Spacebar keys should select or activate the control.
* Within a form, the Spacebar key should select or activate the control, while the Enter key should submit the form's default action.
* If in doubt, mimic the standard desktop behavior of the control you are creating.

So, for the Tabs widget example above, the user should be able to navigate into and out of the widget's container (the `<ol>` in our markup) using the Tab and Shift-Tab keys. Once keyboard focus is inside the container, the arrow keys should allow the user to navigate between each tab (the `<li>` elements). From here, conventions vary from platform to platform. On Windows, the next tab should automatically be activated when the user presses the arrow keys. On macOS, the user can press either Enter or the Spacebar to activate the next tab. An in-depth tutorial for creating Keyboard-navigable JavaScript widgets describes how to implement this behavior with JavaScript.

See also
--------

* ARIA
* Writing Keyboard-navigable JavaScript widgets
* WAI-ARIA Specification
* WAI-ARIA Authoring Practices


Keyboard-navigable JavaScript widgets - Accessibility

Keyboard-navigable JavaScript widgets
=====================================

Web applications often use JavaScript to mimic desktop widgets such as menus, tree views, rich text fields, and tab panels. These widgets are typically composed of `<div>` and `<span>` elements that do not, by nature, offer the same keyboard functionality that their desktop counterparts do. This document describes techniques to make JavaScript widgets accessible with the keyboard.

Using tabindex
--------------

By default, when people use the tab key to browse a webpage, only interactive elements (like links, form controls) get focused. With the `tabindex` global attribute, authors can make other elements focusable, too. When set to `0`, the element becomes focusable by keyboard and script. When set to `-1`, the element becomes focusable by script, but it does not become part of the keyboard focus order.

The order in which elements gain focus when using a keyboard, is the source order by default. In exceptional circumstances, authors may want to redefine the order. To do this, authors can set `tabindex` to any positive number.

**Warning:** avoid using positive values for `tabindex`. Elements with a positive `tabindex` are put before the default interactive elements on the page, which means page authors will have to set (and maintain) `tabindex` values for all focusable elements on the page whenever they use one or more positive values for `tabindex`.

The following table describes `tabindex` behavior in modern browsers:

| `tabindex` attribute | Focusable with mouse or JavaScript via `element.focus()` | Tab navigable |
| --- | --- | --- |
| not present | Follows the platform convention of the element (yes for form controls, links, etc.). | Follows the platform convention of the element. |
| Negative (i.e. `tabindex="-1"`) | Yes | No; author must focus the element with `focus()` in response to arrow or other key presses. |
| Zero (i.e. `tabindex="0"`) | Yes | In tab order relative to element's position in document (note that interactive elements like `<a>` have this behavior by default, they don't need the attribute). |
| Positive (e.g. `tabindex="33"`) | Yes | `tabindex` value determines where this element is positioned in the tab order: smaller values will position elements earlier in the tab order than larger values (for example, `tabindex="7"` will be positioned before `tabindex="11"`). |

### Non-native controls

Native HTML elements that are interactive, like `<a>`, `<input>` and `<select>`, are already accessible by keyboards, so to use one of them is the fastest path to make components work with keyboards.

Authors can also make a `<div>` or `<span>` keyboard accessible by adding a `tabindex` of `0`. This is particularly useful for components that use interactive elements that do not exist in HTML.

### Grouping controls

For grouping widgets such as menus, tablists, grids, or tree views, the parent element should be in the tab order (`tabindex="0"`), and each descendant choice/tab/cell/row should be removed from the tab order (`tabindex="-1"`). Users should be able to navigate the descendant elements using arrow keys. (For a full description of the keyboard support that is normally expected for typical widgets, see the WAI-ARIA Authoring Practices.)

The example below shows this technique used with a nested menu control. Once keyboard focus lands on the containing `<ul>` element, the JavaScript developer must programmatically manage focus and respond to arrow keys. For techniques for managing focus within widgets, see "Managing focus inside groups" below.

```html
<ul id="mb1" tabindex="0">
  <li id="mb1\_menu1" tabindex="-1">
    Font
    <ul id="fontMenu" title="Font" tabindex="-1">
      <li id="sans-serif" tabindex="-1">Sans-serif</li>
      <li id="serif" tabindex="-1">Serif</li>
      <li id="monospace" tabindex="-1">Monospace</li>
      <li id="fantasy" tabindex="-1">Fantasy</li>
    </ul>
  </li>
  <li id="mb1\_menu2" tabindex="-1">
    Style
    <ul id="styleMenu" title="Style" tabindex="-1">
      <li id="italic" tabindex="-1">Italics</li>
      <li id="bold" tabindex="-1">Bold</li>
      <li id="underline" tabindex="-1">Underlined</li>
    </ul>
  </li>
  <li id="mb1\_menu3" tabindex="-1">
    Justification
    <ul id="justificationMenu" title="Justification" tabindex="-1">
      <li id="left" tabindex="-1">Left</li>
      <li id="center" tabindex="-1">Centered</li>
      <li id="right" tabindex="-1">Right</li>
      <li id="justify" tabindex="-1">Justify</li>
    </ul>
  </li>
</ul>
```

#### Disabled controls

When a custom control becomes disabled, remove it from the tab order by setting `tabindex="-1"`. Note that disabled items within a grouped widget (such as menu items in a menu) should remain navigable using arrow keys.

Managing focus inside groups
----------------------------

When a user tabs away from a widget and returns, focus should return to the specific element that had focus, for example, the tree item or grid cell. There are two techniques for accomplishing this:

1. Roving `tabindex`: programmatically moving focus
2. `aria-activedescendant`: managing a 'virtual' focus
### Technique 1: Roving tabindex

Setting the `tabindex` of the focused element to "0" ensures that if the user tabs away from the widget and then returns, the selected item within the group retains focus. Note that updating the `tabindex` to "0" requires also updating the previously selected item to `tabindex="-1"`. This technique involves programmatically moving focus in response to key events and updating the `tabindex` to reflect the currently focused item. To do this:

Bind a key down handler to each element in the group, and when an arrow key is used to move to another element:

1. programmatically apply focus to the new element,
2. update the `tabindex` of the focused element to "0", and
3. update the `tabindex` of the previously focused element to "-1".

Here's an example of a WAI-ARIA tree view using this technique.

### Tips

#### Use element.focus() to set focus

Do not use `createEvent()`, `initEvent()` and `dispatchEvent()` to send focus to an element. DOM focus events are considered informational only: generated by the system after something is focused, but not actually used to set focus. Use `element.focus()` instead.

#### Use onfocus to track the current focus

Don't assume that all focus changes will come via key and mouse events: assistive technologies such as screen readers can set the focus to any focusable element. Track focus using `onfocus` and `onblur` instead.

`onfocus` and `onblur` can now be used with every element. There is no standard DOM interface to get the current document focus. If you want to track the focus status, you can use the document.activeElement to get the active element. You can also use document.hasFocus to make sure if the current document focus.

### Technique 2: `aria-activedescendant`

This technique involves binding a single event handler to the container widget and using the `aria-activedescendant` to track a "virtual" focus. (For more information about ARIA, see this overview of accessible web applications and widgets.)

The `aria-activedescendant` property identifies the ID of the descendant element that currently has the virtual focus. The event handler on the container must respond to key and mouse events by updating the value of `aria-activedescendant` and ensuring that the current item is styled appropriately (for example, with a border or background color).

General Guidelines
------------------

### Use onkeydown to trap key events, not onkeypress

IE will not fire `keypress` events for non-alphanumeric keys. Use `onkeydown` instead.

### Ensure that keyboard and mouse produce the same experience

To ensure that the user experience is consistent regardless of input device, keyboard and mouse event handlers should share code where appropriate. For example, the code that updates the `tabindex` or the styling when users navigate using the arrow keys should also be used by mouse click handlers to produce the same changes.

### Ensure that the keyboard can be used to activate element

To ensure that the keyboard can be used to activate elements, any handlers bound to mouse events should also be bound to keyboard events. For example, to ensure that the Enter key will activate an element, if you have an `onclick="doSomething()"`, you should bind `doSomething()` to the key down event as well: `onkeydown="return event.keyCode !== 13 || doSomething();"`.

### Always draw the focus for tabindex="-1" items and elements that receive focus programmatically

IE will not automatically draw the focus outline for items that programmatically receive focus. Choose between changing the background color via something like `this.style.backgroundColor = "gray";` or add a dotted border via `this.style.border = "1px dotted invert"`. In the dotted border case you will need to make sure those elements have an invisible 1px border to start with, so that the element doesn't grow when the border style is applied (borders take up space, and IE doesn't implement CSS outlines).

### Prevent used key events from performing browser functions

If your widget handles a key event, prevent the browser from also handling it (for example, scrolling in response to the arrow keys) by using your event handler's return code. If your event handler returns `false`, the event will not be propagated beyond your handler.

For example:

```html
<span tabindex="-1" onkeydown="return handleKeyDown();">…</span>
```

If `handleKeyDown()` returns `false`, the event will be consumed, preventing the browser from performing any action based on the keystroke.

### Don't rely on consistent behavior for key repeat, at this point

Unfortunately `onkeydown` may or may not repeat depending on what browser and OS you're running on.


Cognitive accessibility - Accessibility

Cognitive accessibility
=======================

Cognitive accessibility covers accessibility considerations for people with cognition and learning disabilities. This document introduces cognitive accessibility and improving accessibility of the web for people with cognitive and learning differences.

Cognitive impairment refers to a broad range of disabilities, from people with intellectual disabilities who may have the most-limited capabilities, to age-related issues with thinking and remembering. The range includes people with mental illnesses, such as depression and schizophrenia. It also includes people with learning disabilities, such as dyslexia and attention deficit hyperactivity disorder (ADHD).

Though there is a lot of diversity within clinical definitions of cognitive impairments, people with them experience a common set of functional problems. These problems include difficulty with understanding content, remembering how to complete tasks, and confusion caused by inconsistent or non-traditional web page layouts. In this document, we focus on steps developers should take to improve the cognitive accessibility of their websites and applications.

Overview
--------

Cognitive and intellectual disabilities cover a large spectrum, and may be momentary, temporary, or permanent conditions. For example, dementia and Alzheimer's are permanent cognitive impairments that get progressively worse. Other permanent cognitive impairments include aphasia, speech and language, autism, ADD/ADHD, dyslexia, and dyscalculia.

An example of a temporary cognitive impairment could be people affected by substances such as alcohol or drugs. Another form it can take is depression, such as when mourning the loss of a loved one, or being momentarily saddened by a tweet or video they just saw online. A third example could be sleep deprivation.

It may seem like an overwhelming challenge to address the wide range of cognitive differences, especially when solutions for two different people may be conflicting. One way to handle this is to focus on cognitive skills. Cognitive skills include:

* attention
* memory
* processing speed
* time management
* letters and language
* numbers symbols and math
* understanding and making choices

A solid approach to providing accessible solutions for people with cognitive impairments includes:

* delivering content in more than one way, such as by text-to-speech or by video;
* providing easily-understood content, such as text written using plain-language standards;
* focusing attention on important content;
* minimizing distractions, such as unnecessary content or advertisements;
* providing consistent web page layout and navigation;
* incorporating familiar elements, such as underlined links that are blue when not visited and purple when visited;
* dividing processes into logical, essential steps with progress indicators;
* making website authentication as easy as possible without compromising security; and
* making forms easy to complete, such as with clear error messages and simple error recovery.
WCAG Guidelines
---------------

WCAG, Web Content Accessibility Guidelines, includes several guidelines to improve cognitive accessibility. These guidelines are published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the Internet. This group is also responsible for the Accessible Rich Internet Application (ARIA) guidelines.

WCAG are guided by four principles: websites must be Perceivable, Operable, Understandable, and Robust. To this end, they define 17 specific guidelines, of which six are especially relevant for cognitive accessibility.

All of the following guidelines help more than just people with cognitive disabilities. For example, being able to extend the expiration time on an application requiring an authentication code sent to a mobile device via text message helps with the following scenarios:

* People with attention or anxiety disorders.
* People who have a poor short-term memory, or who are multitasking.
* People who are less technologically literate.
* People who have poor wireless reception.
* People who have motor control issues.
Adaptability
------------

Guideline 1.3 states "content should be **adaptable**". Create content that can be presented in different ways without losing information or structure. For example, provide responsive layouts, with a single column mobile design.

All information, including structure and relationships conveyed through the presentation, should be available in a form that can be perceived by all users to achieve this goal. For example, the information could be spoken aloud via a narration tool. Making your content capable of being understood by the software is a good way to help ensure it can be used by alternate presentational modes.

Time
----

It is important to allow users the time they require to complete tasks. Guideline 2.2 states "provide users enough **time** to read and use content".

A **time limit** is any process that happens without user initiation after a set time or on a periodic basis, such as being logged out after 30 minutes or having 15 minutes to make a purchase. People with cognitive disabilities may require more time to read content, or to perform functions such as filling out forms. Solutions include providing users enough additional time to complete tasks or eliminate time constraints altogether.

### Timers

Options for adjusting time requirements include:

* Allowing the user to turn off or adjust the time to at least 10 times the original limit before encountering it.
* Alerting the user and providing a buffer of at least 20 seconds to extend the timeout duration by a factor of 10 with a simple action, such as hitting the space bar.

Provide a toggle on content that allows users to enable a longer session time limit, or no session time limit at all. Examples of timed content include forms, timed reading exercises, and training materials. If the time limit is longer than 20 hours, accommodations are not required.

### Moving, blinking, scrolling

It is important not to distract users, especially ones with cognitive disabilities.

If moving, blinking, scrolling, or auto-updating information starts automatically, lasts more than five seconds, and is presented in parallel with other content, the user must able to pause, stop, hide or control it, unless it's an essential functionality. "Essential" means that removing the moving, blinking, scrolling, or auto-updating information would fundamentally change the meaning of the content and/or functionality, **and** information and functionality cannot be achieved in another way that would conform. This includes animated gifs, if the gif animates for more than 5 seconds.

Additional timing criteria to consider are:

* People who have cognitive or language limitations may need more time to read and to understand. For improved usability remove any time limit. Timed content should also be avoided, with exceptions for non-interactive synchronized media and real-time events.
* People with attention deficit disorders should be able to focus on content without distractions. The user should be able to postpone or suppress interruptions, except situations involving alerting a person to an emergency. This provides access to people with cognitive disabilities by enabling them to focus on the main purpose of the content. Enable the user to postpone content updates by providing a way to request content updates rather than updating automatically. Also, enable a way to make nonessential alerts optional.
* Ensure that people can continue an activity without loss of data after re-authenticating an expired session, for example, saving the state of a questionnaire. Make sure to save data in such a way that it can be modified after a user re-authenticates. Before re-authenticating, encode the data as hidden or encrypted.
* Providing warnings about inactivity that could result in data loss. When a timeout is used, tell people exactly how much time will cause the session to time out and result in lost data. The exception to this is preserving data for more than 20 hours when no actions are taken.
Navigation
----------

Guideline 2.4 states "provide ways to help users navigate, find content, and determine where they are," and provides 10 guidelines to ensure the site is navigable and content is findable:

### Include a `<title>`

Make sure to include a `<title>` for the document, as titles provide a quick and easy to reference description of the screen's main point. People with cognitive disabilities, limited short-term memory, and reading disabilities all benefit from being able to identify the purpose of content this way.

### Heading and labels

Include clear and descriptive headings so users can easily find information and understand relationships between different content sections. Descriptive labels help users identify specific components within the content. People who read slowly and people with limited short-term memory benefit when section titles make it possible to predict what each section contains.

### Section headings

Headings help define overall organization of page content. They help facilitate navigation through page content sections, and provide a mechanism to aid comprehension. Examples of headings include chapters, sections and subsections of content, and so on.

Headings are more obvious navigational aids compared to other methods to identify page content sections (borders, whitespace, horizontal rules, etc.).

### Multiple ways to find content

Different users prefer different methods of finding information, so it is important to provide multiple ways for users to locate content on your site.

Providing more than one way to navigate your site can help people find information faster. Some users may prefer a table of contents, site map, or search functionality rather than reading and traversing through several pages to find what they need. Others may prefer to explore the site in a sequential manner, moving from page to page in order to best understand the site's layout, content, and concepts.

### Ability to bypass blocks of content

Providing a mechanism, such as a skip link, to bypass blocks of content that are repeated on multiple web pages.

### Focus order makes sense

The order of focus for interactive elements should make sense. To achieve this, the DOM order should match the visual order, which in turn should match the tabbing order. If the tab order jumps around, especially in a way that does not match the visual order when navigating with a keyboard, users can become disoriented.

### Focused elements should be visibly focused

When a user navigates using a keyboard, the UI should make it obvious which element currently has focus. Don't alter or remove the browser's default `:focus` styling, unless you're making focus even more obvious.

### Link text conveys meaning

The link's text should clearly and concisely communicate what the user should expect to be navigated to next if they choose to activate it. Poorly phrased link text may confuse users as to its purpose or destination.

Some forms of assistive technology allow users to navigate by lists of all the links present on the page. Links will be removed from the context of their surrounding non-link content, making the need for understandable link text even more important. An example of a poor experience is a page full of links whose text reads, "Click here". Without indicating where "here" will take you, the link's purpose is unclear.

For screen readers, it is vital that linked text describes the purpose of each link. If you have added content to links for screen readers, and that content is verbose and potentially confusing to sighted readers, consider clipping the added text to visually hide it from those not using assistive technologies.

### Current location is available

Users should be able to orient themselves within a site or application. This is especially important and helpful for people with short attention spans who may become confused when following a long series of navigation steps.

All users benefit from information about where they are in a site's hierarchy, especially for sites or applications with large amounts of content or many subsections. Breadcrumbs, site maps, and identifying the current page in the navigation as "current" are all techniques that help communicate the current location.

Readability
-----------

Guideline 3.1 states "make text content readable and understandable". For some users, it is difficult to infer the meaning of a word or phrase from context, especially when the word or phrase is used in an unusual way, or has been given a specialized meaning.

For these users, the ability to read and understand may depend on the availability of specific definitions or the expanded forms of acronyms or abbreviations. Some users may experience great difficulty in recognizing written words yet they understand extremely complex and sophisticated documents when the text is read aloud, or when key processes and ideas are illustrated visually.

### Declare the language of the page and any content not in that main language

The language of every page must be declared by using the `lang` attribute on the `<html>` element. Include the `lang` attribute again on text that is in a language other than the main language of the document.

Proper use of `lang` allows some screen readers to announce the text properly when converting it into synthetic speech. It also helps people who use text-to-speech software.

### Define unusual words and word usage

Some disabilities make it difficult to understand nonliteral word usage, such as idioms, colloquialisms, and specialized jargon. Non-native language speakers may also struggle with these terms. If a word or phrase has a unique meaning, in the document provide a definition inline or linked, within a glossary, or to an online dictionary. If a word or phrase is used to mean more than one thing, define each use.

### Define abbreviations

Abbreviations can be confusing for people who:

* Have difficulty decoding words.
* Have limited memory.
* Have difficulty using context to aid understanding.
* Rely on screen magnifiers (which often reduce contextual cues).

Provide an expanded form of the abbreviation the first time it is used, followed by the abbreviation placed within an `<abbr>` element. If an abbreviation has no expanded form, or is an abbreviation for a word that is not in the document's main language (such as Latin), explain its meaning. Also, consider using ruby text for initialism (pronunciation of acronyms).

### Reading level

Content should be written as clearly and as possible. A good rule to go by is to make content simple enough that it can be understood the first time. Methods to achieve this include:

* Using short, simple words.
* Writing short sentences.
* Using active voice in the present tense.
* Using correct grammar and spelling.

It helps users with cognitive disabilities to provide a text summary (sometimes referred to as a TL;DR, or "too long; didn't read") at a low reading level. Another technique you can use is providing accompanying visuals to help explain ideas, events, and processes.

There are tools that can rate the level of your content. For example, this document has an average grade level of about 11. This means it should be easily understood by a native English speaker aged 16 to 17. Some tools can even provide suggestions to help simplify it.

### Pronunciation

There are multiple techniques that can help teach people how to pronounce words:

* Provide the pronunciation immediately following the word.
* Link to a list of pronunciations.
* Provide a glossary with pronunciation.
* Use the `<ruby>` element to illustrate how a word is pronounced.

Providing guidance on how to pronounce words helps many different kinds of people, including those who prefer to read aloud, non-native language speakers, and people who may unfamiliar with the meaning of a term in context.

Another solution is to use glyphs or diacritical marks to illustrate pronunciation. However, if this technique is used, there must be a mechanism to turn it off. Further, it is helpful to link to a guide to the marks being used, as their meaning may not be obvious.

Predictability
--------------

WCAG Guideline 3.2 states "make web pages appear and operate in predictable ways". This is a tenet of good user experience design. Consistency is especially important for people with cognitive difficulties. This includes consistency in page layout and predictable interactive components.

### Use activation, not focus to change context

Creating a change in context should be intentional. Because of this, when a UI feature receives focus, it should not trigger further user-facing actions. Rather, users should need to "activate" a feature to trigger the change.

### Change setting based on an active request

Form control operation and data entry should result in predictable behavior. Changes in context can confuse users with cognitive disabilities, and should therefore only occur when it is clear that such a change will happen in response to the user's action.

Changing state should require intentional user action. Examples of this are checking a checkbox, entering data or changing a select option. Also be sure to provide a submit button to initiate the change of context, and describe what will happen before the change is made.

### Keep navigation consistent throughout the site

Keep the navigation order consistent between pages. For example, if you have a navigation bar on multiple pages, make that navigation uniform across the site with the same links in the same location. This doesn't just apply to navigation: present all repeated components in the same relative order each time they appear.

### Provide consistent labeling

Identical functions should have similar labels every time they are utilized. Consistent button labels, alternative text for icons, and iconography for similar interactions and so on, even on different sections of your site, help all your users.

### Be consistent and predictable, and use norms

While unlabeled iconography is not the most effective method of conveying information, keeping the use of the icons (and if labeled, their label text) consistent helps people to understand what the icon represents. Similarly, don't change defaults like the browser's back button. If you need to redirect a user, let the user know about it beforehand.

Input Assistance
----------------

Guideline 3.3 helps to ensure accurate data entry, stating "help users avoid and correct mistakes". While we all make mistakes, some people are more likely to make mistakes, less likely to notice a mistake, or have a harder time correcting a mistake once they make one.

Input Assistance guidelines aim to reduce the likelihood that users, especially those with disabilities, make a mistake, and, if they do make a mistake, increase the likelihood that they see and comprehend the error message and can successfully fix any errors.

### Convey automated error detection

Users need to be alerted to the error and informed of what is wrong. If there is client side error detection, observe the following guidelines to make the error as effective as possible when conveyed to the user:

* The error must be described in the text.
* Ensure that the error message is as specific as possible.
* Provide text to identify incomplete required fields and text descriptions if a value entered is invalid.
* If the error prevented a form submission, focus on the error. If multiple errors are present, provide a summary, with each error linking to the related input.
* Include text along with use of icons, images, color and so on. Some people have difficulty understanding the meaning of icons and other visual cues.
* Other people may have difficulty understanding the text version of your error message. For these people, also provide things like icons and colors.
* Also, provide feedback on when there is a successful form submission.
### Provide instructions for user input

Start the form with text instructions on how to operate it. Include labels or instructions when users need to input information, using the `<label>`, `<fieldset>`, and `<legend>` elements to do so.

Labels should be descriptive and positioned close to the input they relate to. When requiring a specific format for input, provide an example formatted in the proper way. Additionally, consider performing server-side validation to help format input data, to aid in the ease of user input.

If a form control is required, indicate it both visually and via code. If a form control changes context, describe what will happen in a way that the user will understand it before they cause the context change to happen.

### Error Suggestion

Provide suggested input to the user if an input error is automatically detected and suggestions for correction are known (unless doing so would jeopardize the security or purpose of the content).

### Prevent catastrophes

For submissions that cause, or can lead to, legal, financial, or other significant consequences, ensure that the submissions can be reviewed, confirmed, and/or are reversible.

Data entered by the user should be checked for errors before submission, and the user should be given the opportunity to correct them. The user should be able to review, confirm, and correct information before final submission. Also, be sure to include a confirmation checkbox in addition to a submit button.

If a submission causes a legal or financial transaction to occur, provide a stated time within which the request can be amended or canceled by the user.

### Provide help

Context-sensitive help should be made available. If a form requires text input, provide form instructions describing the purpose and the necessary input. Include spell checking and suggestions for long-form text input, as well as links to help and support material. If a specific data format is expected for input, provide an example.

Notes
-----

The above are good design practices. They will benefit everyone.

* Many people with cognitive impairments also have physical disabilities. Websites must conform with the W3C's Web Content Accessibility Guidelines.
* The W3C's Cognitive and Learning Disabilities Accessibility Task Force produces web accessibility guidelines for people with cognitive impairments.
* WebAIM has a Cognitive page of relevant information and resources.
* The United States Centers for Disease Control estimate that, as of 2018, 1 in 4 U.S. citizens have a disability and, of them, cognitive impairment is the most common for young people.
* In the U.S., "intellectual disabilities" used to be called "mental retardation". In the U.K., "intellectual disabilities" is commonly called "learning disabilities" or "learning difficulties".
See also
--------

* Accessibility Guidelines
* What is accessibility
* Accessibility for seizure disorders
* Understanding WCAG Guidelines
* Accessibility overview
* Web Content Accessibility Guidelines, including cognitive accessibility guidelines
* CThe W3Cs cognitive and Learning Disabilities Accessibility Task Force
* WebAIM Cognitive information
* CDC information on disabilities