Thread Subject: Flashing provisions
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
Return to this mailing list's archives
From: Jared Smith
Date: Fri, Jul 20 2007 3:50 PM
Subject: Flashing provisions
The General Requirements and the Web requirements state a Flashing
timing requirement (more than 3 per second) and then reference the
General Flash and Red Flash Thresholds which again specified the same
timing requirement. This is a bit confusing. I think these could
simply state, "Flashing must be under the General Flash and Red Flash
Thresholds" as these thresholds include the timing requirements.
The application of general and red thresholds within the definition is
also a bit awkward (to me). Here's a stab at clarifying and
simplifying the definition.
A sequence of flashes or rapidly changing sequences where all three of
the following occur:
1. There are more than three and less than 50 flashes within any
one-second period; and
2. The combined area of flashes occurring concurrently and
contiguously occupies more than a total of .006 steradians (25% of any
10 degree visual field on the screen); and
3. The relative luminance of the opposing changes is 10% or more and
the relative luminance of the darker image is below 0.80, or the
opposing changes are to or from a saturated red.
Note 1: A 10 degree visual field for standard screen sizes and viewing
distances is approximately a 341 x 256 pixel rectangle anywhere on a
1024 x 768 display.
Comments/questions:
- Removed the word "image" from the definition, recombined both timing
requirements, and recombined general and red requirements. This means
we could simply call this "Flash Threshold" for simplicity.
- Made some wording more consistent ("opposing changes",
"transitions", "flashes", etc.)
- What exactly is "a saturated red"? I'm assuming it is #ff0000 in
RGB, but if so, this certainly would have no different impact than
#ff0001. I also assume this is referring to my programmed colors, not
the colors as displayed on screen, correct?
- Shortened Note 1 and removed "For general Web content" as this
applies beyond the web.
Jared Smith
From: Gregg Vanderheiden
Date: Fri, Jul 20 2007 5:35 PM
Subject: Re: Flashing provisions
It is mentioned in the provision because that is an easy way to avoid it all
together.
But I see your point.
How about
If content contains components that flash more then 3 times within 1 second
then it must be below the general flash and red flash thresholds.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jared Smith
> Sent: Friday, July 20, 2007 4:45 PM
> To: TEITAC Web/Software Subcommittee
> Subject: [teitac-websoftware] Flashing provisions
>
> The General Requirements and the Web requirements state a
> Flashing timing requirement (more than 3 per second) and then
> reference the General Flash and Red Flash Thresholds which
> again specified the same timing requirement. This is a bit
> confusing. I think these could simply state, "Flashing must
> be under the General Flash and Red Flash Thresholds" as these
> thresholds include the timing requirements.
>
> The application of general and red thresholds within the
> definition is also a bit awkward (to me). Here's a stab at
> clarifying and simplifying the definition.
>
> A sequence of flashes or rapidly changing sequences where all
> three of the following occur:
> 1. There are more than three and less than 50 flashes within
> any one-second period; and 2. The combined area of flashes
> occurring concurrently and contiguously occupies more than a
> total of .006 steradians (25% of any 10 degree visual field
> on the screen); and 3. The relative luminance of the opposing
> changes is 10% or more and the relative luminance of the
> darker image is below 0.80, or the opposing changes are to or
> from a saturated red.
> Note 1: A 10 degree visual field for standard screen sizes
> and viewing distances is approximately a 341 x 256 pixel
> rectangle anywhere on a
> 1024 x 768 display.
>
> Comments/questions:
> - Removed the word "image" from the definition, recombined
> both timing requirements, and recombined general and red
> requirements. This means we could simply call this "Flash
> Threshold" for simplicity.
> - Made some wording more consistent ("opposing changes",
> "transitions", "flashes", etc.)
> - What exactly is "a saturated red"? I'm assuming it is
> #ff0000 in RGB, but if so, this certainly would have no
> different impact than #ff0001. I also assume this is
> referring to my programmed colors, not the colors as
> displayed on screen, correct?
> - Shortened Note 1 and removed "For general Web content" as
> this applies beyond the web.
>
> Jared Smith
>
From: Jared Smith
Date: Fri, Jul 20 2007 5:40 PM
Subject: Re: Flashing provisions
Another issue...
Unless I'm mistaken or misunderstanding something (I'm not an
engineer), both steradians and "25% of any 10 degree visual field" are
not testable. This is because they both change based on the viewing
distance, something that we don't define or allow for. For instance,
if I'm one inch from the screen, both .006 steradians and "25% of any
10 degree visual field" are VERY small.
In order for either to be testable, we must either do something much
different or we must define a typical or minimum viewing distance
from which the 10 degree visual field must be measured. I'm not sure
how we do that. If we can assume that viewing distance will always be
relative to the display size (the bigger the display, the further I am
likely to be from it), then we could do something like:
"... 25% of any 10 degree visual field at a distance of 1.5 times the
greater of the display width or height."
"1.5 times" assumes a typical minimum viewing distance that I just
guessed at. This accounts for display size (anything from handheld
devices to LCD projectors), visual field, AND the point from which
that field is measured. This, of course, is very easy to test - for a
two dimensional display that is roughly perpendicular to your line of
sight it works out to always be a squared area that is 26% of the
greater of width or height.
Without some measure of viewing distance or some formula based upon
display size, the flashing threshold will remain untestable as is.
Of course, the other big problem is that even if we fix this,
programmers and web designers still have little control over display
size, so none of this is very useful to them anyways.
OK, it's Friday and my brain is now officially fried - I'm out.
Jared Smith
From: Gregg Vanderheiden
Date: Fri, Jul 20 2007 10:10 PM
Subject: Re: Flashing provisions
I think what you are looking for might be in the notes. A specific screen
area is provided for standard content. The steradians is used because the
provision would apply to more than typical screens at typical viewing
angles. So people can use the measures provided or they can use their own
and justify it.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jared Smith
> Sent: Friday, July 20, 2007 6:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Flashing provisions
>
> Another issue...
>
> Unless I'm mistaken or misunderstanding something (I'm not an
> engineer), both steradians and "25% of any 10 degree visual
> field" are not testable. This is because they both change
> based on the viewing distance, something that we don't define
> or allow for. For instance, if I'm one inch from the screen,
> both .006 steradians and "25% of any 10 degree visual field"
> are VERY small.
>
> In order for either to be testable, we must either do
> something much different or we must define a typical or
> minimum viewing distance from which the 10 degree visual
> field must be measured. I'm not sure how we do that. If we
> can assume that viewing distance will always be relative to
> the display size (the bigger the display, the further I am
> likely to be from it), then we could do something like:
>
> "... 25% of any 10 degree visual field at a distance of 1.5
> times the greater of the display width or height."
>
> "1.5 times" assumes a typical minimum viewing distance that I
> just guessed at. This accounts for display size (anything
> from handheld devices to LCD projectors), visual field, AND
> the point from which that field is measured. This, of course,
> is very easy to test - for a two dimensional display that is
> roughly perpendicular to your line of sight it works out to
> always be a squared area that is 26% of the greater of width
> or height.
>
> Without some measure of viewing distance or some formula
> based upon display size, the flashing threshold will remain
> untestable as is.
>
> Of course, the other big problem is that even if we fix this,
> programmers and web designers still have little control over
> display size, so none of this is very useful to them anyways.
>
> OK, it's Friday and my brain is now officially fried - I'm out.
>
> Jared Smith
>