Hi Robert,
The current best thinking around limits in flashing/refresh to ensure
it won't trigger an seizure is expressed in the Final Report to the
U.S. Access Board from the Telecommunications and Electronic and
Information Technology Advisory Committee, delivered this past April.
Please see the Final Report at:
http://www.access-board.gov/sec508/refresh/report/ and see the relevant
section as part of the definition of "General Flash and Red Flash
Thresholds for Content and User Interfaces", somewhat down from the
subsection http://www.access-board.gov/sec508/refresh/report/#72
While this text did not reach consensus (it is part of the
non-consensed portion of the report), I believe it is the best starting
place for us to go from. The text is:
A flash or rapidly changing image sequence is below the
threshold
(i.e., software or CONTENT passes) if any of the following is true:
1. There are no more than three General Flashes and / or no more
than three Red Flashes within any one-second period; or
2. The combined area of FLASHES occurring concurrently occupies no more
than a total of .006 steradians within any 10 degree visual field on
the screen (25% of any 10 degree visual field on the screen) at typical
viewing distance where:
A General Flash is defined as a pair of opposing changes in
RELATIVE
LUMINANCE of 10% or more of the maximum RELATIVE LUMINANCE where the
RELATIVE LUMINANCE of the darker image is below 0.80; and where "a pair
of opposing changes" is an increase followed by a decrease, or a
decrease followed by an increase, and
A Red Flash is defined as any pair of opposing transitions
involving a saturated red.
Exception: FLASHING that is a fine, balanced, pattern such as white
noise or an alternating checkerboard pattern with "squares" smaller
than 0.1 degree (of visual field at typical viewing distance) on a side
does not violate the thresholds.
Note 1: For general software or Web CONTENT, using a 341 x 256
pixel
rectangle anywhere on the displayed screen area when the CONTENT is
viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree
visual field for standard screen sizes and viewing distances
(e.g.,15-17 inch screen at 22-26 inches). (Higher resolutions displays
showing the same rendering of the CONTENT yield smaller and safer
images so it is lower resolutions that are used to define the
thresholds.)
Note 2: A transition is the change in RELATIVE
LUMINANCE (or relative luminance/color for red flashing) between
adjacent peaks and valleys in a plot of relative luminance (or relative
luminance/color for Red Flashing) measurement against time. A FLASH
consists of two opposing transitions.
Note 3: The current working definition in the field for "pair of
opposing transitions involving a saturated red" is where, for either or
both states involved in each transition, R/(R+ G + B) >= 0.8, and
the change in the value of (R-G-B)x320 is > 20 (negative values of
(R-G-B)x320 are set to zero) for both transitions. R, G, B values range
from 0-1 as specified in “relative luminance” definition. (Harding and
Binnie 2002)
Note 4: Tools are available that will carry out analysis from video
screen capture. However, no tool is necessary if FLASHING is less than
or equal to 3 flashes in any one second period (content automatically
passes (see #1 and #2 above).
The aspects of refreshing that trigger seizures are:
- the change in relative luminance (large swings are a problem, the
color red seems particularly problematic)
- the frequency (slower than 3x/second is OK, and so is faster than
the eye can perceive (e.g. 50Hz)
- the portion of the user's field of view that the change occurs in
If we are talking about the change of text in a field (e.g. a
spreadsheet cell whose contents are displaying 10ths of a second as a
number), I believe this would pass the above test because: (a) the
relative luminance change from one number to another in terms of % of
pixels changing is below the threshold, and (b) unless it is a large
cell with a large font, the portion of the screen changing is small
enough as to be below the threshold.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
OF4E184310.13BFC0F8-ON8525748A.00650842-8525748A.00678B81@lotus.com"
type="cite">
The key point in my mind is that the
nature of the problem ("a risk of causing an epileptic fit")
may raise this from an accessibility issue to a safety issue.
ISO Directives, Part 2, section
A.2.3
gives the following guidance:
"A.2.3 If health, safety aspects,
the protection of the environment or the economical use of
resources are relevant to the
product,
appropriate requirements shall be included. Otherwise,
they may, in some countries, be made
additional mandatory requirements which, if not
harmonized, would constitute
technical
barriers to trade.
These requirements may need to have
certain characteristics with limiting values (maximum
and/or minimum) or closely defined
sizes
and, in some cases, even constructional stipulations
(for example, to achieve
non-interchangeability
for safety reasons). The levels at which these
limits are fixed shall be such that
the element of risk is reduced as much as practicable."
So I think we should make some
statement
in the standard itself, not merely in a separate guidelines document,
that defines how to use this feature safely.
Which leads me to the technical
questions:
1) Surely, the table refresh itself
is inoffensive, right? For example, an application could have a table
refresh (fetch new data) but only display updates when some other
condition
was met. Or you might not have any GUI at all and the updates and
recalc's trigger some action on the server.
2) Is any screen update faster than
once every 3 seconds a problem? Or is it only certain styles of
updates,
the ones which noticeably "flash" because of poor redrawing,
lack of double buffering or whatever? In other words is there any
safe way of doing rapid screen updates?
3) Most display technologies are
already
redrawing at a fast rate. This is inherent in the graphics card/display
technology. So very fast rates are OK? What is the range of
rates where it is a problem?
4) How do we state this in the
standard?
Would something like this work: "Note: display devices
which update information on the screen at rates between X Hz and Y Hz
have
been shown to prompt epileptic seizures in some people. ODF
applications
which refresh the display with each table refresh shall provide an
option
for the user to suspend the rendering of such refreshes." We
could probably make a more general statement on refresh/animation/blink
and place it in the conformance section of the standard.
-Rob
Duane Nickull <dnickull@adobe.com> wrote on
07/18/2008 02:12:38 PM:
>
> The main point is that implementors have control when implementing
> the specification vs. being constrained by the spec. Let’s
not put
> weightless restrictions into the specification.
>
> Duane
>
>
> On 18/07/08 10:35 AM, "Peter Korn" <Peter.Korn@Sun.COM>
wrote:
> Hi Dave,
>
> In OpenOffice.org we have the ability to turn animation off.
I
> agree with Malte; we shouldn't prevent the expression of fast
> animation for those who want it, but we should enable users to not
> have it displayed to them.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> 2008/7/18 Malte Timmermann <Malte.Timmermann@sun.com> <
> mailto:Malte.Timmermann@sun.com>
:
>
>
>
> I don't agree on "require user agents to limit this to no more
than 3
> times a second".
>
> I must admit that I don't believe a higher frequency would make any
> sense for anything, but People have different needs, and if
someone
for
> what every reason needs a higher frequency, the application should
be
> allowed to support this.
>
>
>
>
> Strongly disagree Malte.
>
> If there is a riks of causing an epeleptic fit, then I'd like
> to see a 'shall' statement in the standard requiring
> nothing more than 3 times per second.
>
> Peoples needs are my concern too.
>
> regards
>
>
>
>
>
|