- From: Userite <richard@userite.com>
- Date: Fri, 27 Aug 2021 12:26:12 +0100
- To: "Janina Sajka" <janina@rednote.net>, "Wayne Dick" <wayneedick@gmail.com>
- Cc: "John Foliot" <john@foliot.ca>, "W3C WAI ig" <w3c-wai-ig@w3.org>
Hi Janine You are correct when you say that this feature helps people with learning disabilities. But I am not sure that this situation (sequential highlighting) could cause seizures or dizziness. The background highlight colour change does not happen at the same location thus it would cause the eye focus to change as it moves to the next word. My understanding is that this eye movement coupled with the fact that each "flash" highlights a different word (different length and pattern of letters) could/should break the hypnotic effect of repetitive flashing. Has anyone actually checked with an expert? Regards Richard -----Original Message----- From: Janina Sajka Sent: Wednesday, August 25, 2021 6:08 PM To: Wayne Dick Cc: John Foliot ; W3C WAI ig Subject: Re: Flash index problem. Wayne: It sounds like your technology setup is forcing the word being voiced to be highlighted on screen which creates a kind of progressive flashing one word after the next. Am I understanding you? I know this kind of feature is considered desirable for certain COGA situations, but I was never aware it to be a requirement for low vision. Do you not have the option to not highlight the word? Or to put it differently, what's the desired behavior? Perhaps the desired behavior is that you have chosen this feature setup and it should, therefore, not be classified as hazardous for the simple reason that it's a conscious choice? If so, I think we're going in this direction with WCAG 3. Best, Janina Wayne Dick writes: > Hi All, > I brought this up because it bothers me. > > Here is the problem. When you read and listen at the same time, you keep > your visual focus on the word being read. The visual information > reinforces what you cannot hear, and the audio reinforces what you cannot > see. So, unlike non-visual access to reading, other people with print > disabilities use the see/hear combination to boost comprehension. This > requires looking at the word being read. > > The word highlighted appears at the same region in the visual field. It > looks like a flash. I have tried not looking at the highlighted word, but > that disrupts comprehension. > > As far as slowing down reading speed to below 180 wpm, that works but > reading drags. The typical person reads 200-250 words per minute on > average. > > Good ebook or article readers give the user a choice to highlight: > > - None, > - Word, > - Phrase or > - Line. > > I brought this up because I observed the problem, and could calculate that > it does not meet Web guidelines. That means it may be an accessibility > issue. Log it. You may not be able to address it, but it is a potential > problem. > > I did not start with the numbers and go backwards. I started with > persistent nausea and worked backwards. > > At CSU Long Beach we had a lattice lath structure over a sidewalk that > caused flash issues for people who walked under it. We discovered it when > the vice president of publications got extremely dizzy whenever she walked > under it at lunch time. She was a member of our Accessible Technology > Initiative, and recognized the issue. The University changed the > orientation of the lath and the problem went away. That is not a Web > problem, but the Web guidelines enabled us to identify the problem. When a > person walked under the lath at a normal speed it created a flash effect > that was greater than 3/second. > > This highlight flash may not be a web content issue, but it may very well > be an IT accessibility issue. > > Best, Wayne > > > > > > > > > On Wed, Aug 25, 2021 at 8:51 AM Janina Sajka <janina@rednote.net> wrote: > > > Good points, John. > > > > In terms of mitigation -- APA is looking at a technological solution. > > We're expecting a presentation of tech developed at MIT at an upcoming > > RQTF call. The concept has been proven to work. Now we need to get the > > licensing and user agent adoption. > > > > John Foliot writes: > > > 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" > > > > -- > > > > 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 > > > > -- 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
Received on Friday, 27 August 2021 11:26:32 UTC