Re: Checkpoint 2.3 Avoid causing the screen to flicker.

There has been discussion that if Checkpoint 2.3 [Core] "User can avoid
experiencing screen flicker" is not testable that it may be moved from
Core to Extended.
 
Some problems this would cause include: inconsistency with Section 508
1194.22(j), inaccessibility and possible injury to people with
photosensitive epilepsy, and loss of comprehension by people with
cognitive disabilities due to the distracting effect.
 
I see relationships with 2.2 [Core] "Users can control any time limits
on their reading, interaction, or responses unless control is not
possible due to nature of events or competition" because objects that
cause flicker may also cause screen refresh, or contain moving text or
other elements. Animations that contain flicker are distracting to
people with cognitive disabilities.
 
And 3.4 [Extended] "Layout and behavior of content is consistent or
predictable, but not identical." In that objects with flicker may also
cause a change of context to occur, e.g. rotating ads, ads that move
around the screen.
 
There appears to be movement away from 'banning' technology and instead
recommending 'warning and remedy' in WCAG 2.0 (e.g., pop-ups). From the
way 2.3 is currently written, it would appear that flicker, even within
the intolerable range, would be acceptable so long as the user can avoid
it. In addition, I feel the problem is not just with flicker but with
all non-static content.
 
Therefore I propose that rather than ban a frequency range of flicker
that we require for all instances of non-static content (flicker,
motion, refresh, and/or sudden change of context) the following:
a) warning before it occurs
b) opportunity to avoid it
c) static equivalent
 
The only remaining question, therefore, would be whether or not a tool
can detect the presence of any non-static content. I imagine one can.
Programmatically, one can think of: 'blink', 'marquee', changes in
position defined in CSS, 'object', 'embed', 'img dynsrc' etc. There may
be cost-effective physical measurements as well, or other methods I'm
unaware of. In any case, I believe that which needs to be detected is
significantly simplified.
 
If non-static content is detected, [Core] compliance could test for the
presence of a warning. [Extended] compliance may be for the presence of
control/avoidance (e.g., freeze button or link to alternative page) and
equivalent content.
 
Hope this helps,
 
Chris Brainerd

Instructional Designer

Real Choices ACCESS

Center on Disability Studies

University of Hawaii

Chris.brainerd@cds.hawaii.edu <mailto:Chris.brainerd@cds.hawaii.edu> 

808-956-9356