OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-accessibility] Re: [office] Table Refresh Delay

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.


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.


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]