Re: Flash index problem.

Hi Janina,

Not sure if you are aware of the PEAT testing tool from the Trace Center (
https://trace.umd.edu/peat/), however they state:

"In general, web or computer content will not provoke seizures if either of
the following is true:

   - There are no more than three general flashes and no more than three red
   flashes within any one-second period, or
   - 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.
   "

So my reading between the lines suggests that it's less the location, and
more the size. I wonder aloud how this is applicable to Wayne's
concern/observation?

As a TTS tool that also provides text highlighting processes the individual
words it is reading, are those 'highlighted words' less than or greater
than "...a total of one quarter of any 341 X 256 pixel rectangle"? Or is it
more looking at a combination of "flashing highlighting" that is also
introducing horizontal movement (L to R in English, but R to L in, say
Hebrew) that it then becomes a concern? (In other words, while each word is
highlighted individually, and thus likely below the individual measurement
thresh-hold, is the *proper* way to evaluate this to instead think of this
as the block of text that is flashing or strobing in the aggregate?)
Perhaps an issue that requires clarification and review in WCAG 3?

Nonetheless, while I recognize the issue and concern, I'm also not sure
there is anything an individual content author can do to mitigate or
remediate this edge-case scenario.

JF

On Wed, Aug 25, 2021 at 8:51 AM Janina Sajka <janina@rednote.net> wrote:

> There's an additional nuance I've not previously considered ...
>
> Is the flash sensitivity specific to location on screen? i.e. more than
> 3 per second at the same x,y location?
>
> Or does successive highlighting of words on screen also trigger the
> hazzard?
>
> To me this seems like it would be worth clarifying.
>
> Best,
>
> Janina
>
> John Foliot writes:
> > Hi Wayne,
> >
> > Ah, math <smile>. This presumes that the end-user has configured their
> TTS
> > engine to read at this speed - but since all screen readers I've seen
> also
> > allow the end-user the ability to adjust the reading rate, this by
> > extension means they can also adjust "flashing" in the use-case context
> you
> > provided. (And if the user-agent stack doesn't, this is a failure of
> UAAG,
> > which is non-normative, sadly.)
> >
> > Additionally, this will manifest on *any* content rendered in the
> > user-agent - this cannot be mitigated by the individual content
> > author/owner - it is a concern rooted at the user-agent level.
> >
> > One has to presume that a user who both requires
> > text-to-speech+highlighting AND is also sensitive to flashing content
> will
> > have previously adjusted their user-agent stack to address this issue.
> >
> > JF
> >
> > On Tue, Aug 24, 2021 at 6:57 PM Wayne Dick <wayneedick@gmail.com> wrote:
> >
> > > If you are reading with a text-to-speech reader and it highlights
> words at
> > > more than 180 words per minute, then you have more than 3 flashes per
> > > second.
> > >
> > >
> >
> > --
> > *John Foliot* |
> > Senior Industry Specialist, Digital Accessibility |
> > W3C Accessibility Standards Contributor |
> >
> > "I made this so long because I did not have time to make it shorter." -
> > Pascal "links go places, buttons do things"
>
> --
>
> Janina Sajka
> https://linkedin.com/in/jsajka
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures     http://www.w3.org/wai/apa
>
>

-- 
*John Foliot* |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"