RE: Checkpoint 2.3 Avoid causing the screen to flicker.

My comments and notes are inserted prior to each comment.  I hope this 
is not too confusing, as I did not want to remove the other items out 
of confusion when referred to later.

Lee

I concur with proposal #1.

Comment #1
WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002 [1]
Benefits: 'Distractibility problems' could be reworded to say
'individuals 
who are easily distracted'.

Proposal #1
Accept the proposed rewording so that the 2nd benefit reads,
"Individuals 
who are easily distracted may not be able to focus on page content with 
flicker occurring in the same visual field."

============
Comment: Section 508 applies only to US Government web sites.  It is my 
recommendation to not use that source as a metric as it was supposedly 
based upon WCAG1.  However, some public officials felt they should mold 
it to their liking and not conform to the knowledge and expertise of 
the WCAG1 WG.

Photosensitivity actually has a range of 2Hz to 63Hz.  However, the 
majority of standards states the recommendation is 2Hz to 60Hz.


Comment #2
Terry Thompson, 21 Oct 2002 [2]
IBM (via Andi Snow-Weaver), 29 Oct 2002 [4]
Why is the high end of the dangerous flicker rate 49Hz?  508 recommends 
55Hz. We should be consistent with that.

Proposal #2
- In the success criteria, use the interval: "between 2 Hz to 55 Hz."
- Reword Benefit #1 to read: "Individuals with photosensitive epilepsy
can 
have seizures triggered by flickering or flashing of 3 flashes per
second 
(Hertz) or faster with a peak sensitivity at 20 flashes per second.  An 
upper limit of 55 Hz is used to be consistent with other guidelines."

Rationale:  Harding said (in a private email), "Current guidelines ban 
flicker above 3/sec with no upper limit, 15% are  still sensitive at 60 
Hz."  British broadcasters have not set an upper limit (with a couple 
exceptions) as outlined in the "Photo-Sensitive Epilepsy (PSE)
Guidelines." 
http://www.films.demon.co.uk/online/pse.html

WCAG 1.0 uses the interval:  4 to 59 flashes per second.  While the low
end 
is not low enough, the high end (59Hz) is closer to Harding's
recommendation.

However, 508 originally contained no upper limit but this was opposed
and 
changed to 55 Hz in the final rule.  Thus, to be consistent with 508,
the 
proposal is to use 55 Hz as the upper limit. 
http://www.access-board.gov/sec508/508standards.htm

==============
Comment #3
Sun (via Earl Johnson), 27 Oct 2002 [3]
On #3 in Level 2: if it is kept as a criteria consider changing it to a 
Level 3 criteria. (note that in the 28 august draft, this became #4)
commenting on the statement, "(tougher test - that would make pages pass

with even slower equip. Equip might be old or just slow for other
reasons)"

Proposal #3
Either delete this or change it to read, "Reviewer's note: we might
propose 
a tougher test that would make pages pass with even slower 
equipment.  Equipment might be old or just slow for other reasons."

Rationale:  It appears to be an unfinished thought or a note.  If
someone 
can clean this up better than I can, please do.

============
Comment #4
IBM (via Andi Snow-Weaver), 29 Oct 2002 [4]
Minimum success criteria: Since all success criteria must be testable,
and 
item 1b implies that 1a cannot be tested, item 1a should not be included
as 
a success criteria.

Proposal #4
rewrite the minimum to read:
1. At least one of the following is true:
    a. content does not flicker or flash.
    b. flickering or flashing of content is not between 3 Hz and 55 Hz.
    c. if flicker is unavoidable, the user is warned of the flicker
before 
they go to the content, and as close a version of the content as is 
possible without flicker is provided.
Reviewer's Note: A tool currently exists to test television broadcasts
but 
does not yet test Web content.  We're looking into how such a test
and/or 
tool might be designed.

Rationale:  1b was a reviewer's note about a tool.  Since it seems the
only 
way to test for flicker is with a tool, it made sense to apply it to all

three criteria.  1a was added for completeness.

============
Comment #5
IBM (via Andi Snow-Weaver), 29 Oct 2002 [4]
Level 2 success criteria: Items # 1 and # 2 should be moved to Level 3.
(in 
the 28 august draft these are now #3 and #2)
Level Items #2 and #3 currently read:
2. content that might create a problem has been tested [using XYZ tool];

only pages with unavoidable flicker remain and appropriate warnings
along 
with a close alternative presentation have been provided for these
pages. 3. a conformance claim associated with the content asserts
conformance to 
this checkpoint at level 2

Proposal #5
delete #2

Rationale: #2 is the same as the minimum level:  if pages contain
flicker 
then you have to the warn the user.
#3 will be reworded in the new draft per the resolution to reword or
remove 
these types of claims ala the resolution outlined at: 
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0044.html

============
I think there is a typo in this as a person would not be affected at 
flashing or flickering rates of 3 to 49MHz.  That should be Hz.

Comment #6
Phill Jenkins [5]
move success criteria for 2.3 from the minimum and level 2, to level 3 
only, such that it includes the existing criteria of not "visibly or 
purposely flicker between 3 and 49
Mhz", etc.

Proposal #6
This issue requires follow-up with Phill since he is saying that
Checkpoint 
2.3 should not have any minimum level or level 2 success criteria - only

level 3.  Check back with him after we discuss the rest of the proposals
in 
this message.

===========
Comment #7
Phill Jenkins [5]
Web examples of "bad flicker" be identified and evaluated such that
common 
testable characteristics be identified.  In other words, further the 
science here for the benefit of the browsers and authors and especially 
evaluation tools testing for compliance.  The work referenced by Wendy
of 
Professor G. Harding and the HardingFPA system from Cambridge Research 
Systems is mostly, if not all about traditional TV broadcast images and 
needs to be applied to the Web browsers and content.

Proposal #7
Yes. This should be done.  Gregg and I have been in contact with
Cambridge 
Research Systems and hopefully someone a tool will emerge that analyzes
Web 
content for flicker.

===========
Comment #8
After comments 6 and 7 are closed, re-open a work item for the ER 
interest/working
group.

Proposal #8
It is a requirement of WCAG 2.0 that success criteria be testable, thus 
this is a work item for the WCAG WG not the ERT WG.  Thus, whatever the 
results of 6 and 7, the work be done by WCAG WG and incorporated into a 
draft of WCAG 2.0.


===========
Comment #9
SAP (via Audrey Weinland), 31 Oct 2002 [6]
"content was not designed to flicker (or flash) in the range of 3 to 49 
Hz." Could you include a visual example?

Proposal #9
We will have to provide strong disclaimers. I would prefer to provide 
examples of content that meets the requirements (e.g., good 
examples).  However, people want to know what it looks like and want to 
test their tools. Here is an example from a webaim tutorial.  Please be 
careful looking at this image!!! 
http://www.webaim.org/contentobjects/tutorials/seizuregraphic

Thanks,
--wendy

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0135.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0080.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0111.html
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0117.html
[5] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Dec/0000.html
[6] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0130.html

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Friday, 20 December 2002 13:37:35 UTC