Checkpoint 2.3 Avoid causing the screen to flicker.

Hello,

With the upcoming holidays, these proposals will remain open until 9 
January.  After that time if no comments have been received about a 
proposal or the comments are editorial tweaks that don't cause controversy 
the proposal will be incorporated into the next possible internal working 
draft.  Proposals that can not be resolved via discussion on the mailing 
list will be discussed at a future WCAG WG teleconference.


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 #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

============
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 Thursday, 19 December 2002 19:07:55 UTC