W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > December 2002

Re: Automatically testing Web content for flicker

From: Wendy A Chisholm <wendy@w3.org>
Date: Sat, 07 Dec 2002 20:23:30 -0500
Message-Id: <5.1.0.14.2.20021207180117.04adbd70@localhost>
To: "Phill Jenkins" <pjenkins@us.ibm.com>, w3c-wai-er-ig@w3.org

At 11:27 AM 12/2/02, Phill Jenkins wrote:
>I was cleaning up some old mail and noticed that this thread may not have
>completely ended [1].
>
>Is the question about flicker being a content requirement now in WCAG the
>WG?  Flicker is addressed in UAAG Guideline 3 [2], so we now have redundant
>requirements in WCAG 1.0 and UAAG 1.0.  I couldn't find a related issue in
>the WCAG 2.0 issue list [3].

As you pointed out, the relevant UAAG requirements are in Guideline 3.  The 
only specfic mention I found of "flicker" is in the Techniques for UAAG 
related to Checkpoint 3.4 Toggle scripts. (P1) (does not apply to 
plug-ins,but does apply to applets) [4]. Although, several of the other 
elements (e.g., images) could contain flicker and that being able to toggle 
them on/off is important.

Regardless, as with many other requirements there is both a WCAG piece and 
a UAAG piece.  The WCAG piece is typically "design and/or markup the 
content so that it can transform"  the UAAG piece is typically "allow the 
user to take advantage of the flexibility that the author has provided."

In the flicker case (as it relates to scripts), UAAG says, "[UA] Developers 
should not consider that the user's ability to turn off scripts is an 
effective way to improve content accessibility; turning off scripts means 
losing the benefits they offer. Instead, developers should provide users 
with finer control over user agent or content behavior known to raise 
accessibility barriers. The user should only have to turn off scripts as a 
last resort."

Thus, there is still a part within WCAG that needs to say "avoid flicker or 
make it possible for the user to turn it off."

WCAG 2.0 addresses the issue with "Checkpoint 2.3 Avoid causing the screen 
to flicker."  [5] I don't think we feel we are done and I think that 
requirement b is likely to disappear, but we the minimum criterion 
currently reads:
You will have successfully met Checkpoint 2.3 at the Minimum Level if:
At least one of the following is true:
a. content was not designed to flicker (or flash) in the range of 3 to 49 Hz.
b. Reviewer's Note: We would like to include a criteria here which would 
state that a test that was conducted and the pages passed. No test or tool 
exists yet though. We're looking into how such a test and/or tool might be 
designed.
c. if flicker is unavoidable, the user is warned of the flicker before they 
go to the page, and as close a version of the content as is possible 
without flicker is provided.

>Wendy mentioned:
> >In the meantime, I heard back from Professor Harding and there is a system
> >that checks for flicker.  It's based on his research and produced by
> >Cambridge Research Systems. http://www.hardingfpa.co.uk/
> >
> >Not sure how much it costs, how easy it is to use, or how well it works on
> >web content...but I'll contact CRS to find out.
>
>I couldn't find an update on this.

Looks like I forgot to follow-up on this.  As you said, it appears this 
tool analyzes television broadcasts and doesn't appear that it will work on 
web content.  I've sent an email to Cambridge Research Systems asking if 
HardingFPA analyzes Web content and if not are there plans to develop this 
in the future.

>Perhaps it is in the mail archives, but
>since they are archived every month, it is difficult to search multiple
>months.  Is there any way to archive ER-IG every quarter (3 months) instead
>of once a month?
Have you ever tried using the list archives search facility or used an 
external engine, like Google?  This is often how I find things on the archive.

I have requested that the archive interval for this list change from 1 
month to 3 months.

>and Terje wrote:
> >Whether it makes sense to attempt to _test_ for this is a different
>matter.
>
>How to determine if the content meets some testable criteria _is_ the issue
>here.  It is easy to say from a single authors point of view that I should
>_avoid_ things that _might_ cause flicker.  But WCAG 2.0 owes it to the
>author to clearly set the criteria that the author has to meet.  Now that
>these Web Content Accessibility Guidelines are parts of policy,
>regulations, and laws, it needs to be testable - did I meet the standard or
>not?

What do you think of the Photo-Sensitive Epilepsy (PSE) Guidelines at:
http://www.films.demon.co.uk/online/pse.html

These are written for television, but seem fairly objective.  Note that 
these include more than flicker. It also looks at different types of shot 
angles and changes between scenes.

>As the evaluation and repair interest group, we need to determine how to
>evaluate and repair what's in WCAG 1.0 and influence 2.0 success criteria.

I would prefer to see this work happen in the WCAG WG.  This Thursday (12 
December) we are having a techniques "kick-off" of sorts to discuss the 
plans for the technology-specific aspect of WCAG.  If you look at the 
thread discussing the requirements for the wcag 2.0 techniques [6], you'll 
see that what was previously AERT [7] will become part of the 
technology-specifics for WCAG 2.0.

>If we look at it from the view point of someone representing 100's or
>1,000's of web authors and pages, for example from a government agency or
>large company view - how do I evaluate if any of my 1,000's of pages have
>bad flicker or not?  Did all my 100's of author avoid it or not?  Asking
>them to all say yea or nea is not sufficient because content is changed
>constantly and the author trail of who actually changed/authored a piece of
>content at a particular point in time is rarely known.  So, we come back to
>the question of evaluation - how do we evaluate it - which begs the
>question - do we really need to evaluate the requirement of bad flicker at
>all?

We've been discussing this series of questions and hoping that EARL could 
help provide some of the answers (i.e., as the content passes through 
different hands, if each tool understood EARL then the answers to these 
questions could move around with the content).

Specific to the flicker issue, as you suggested in your email, we need 
someone to develop a tool that applies the ideas of the Harding tool to Web 
content.

>To close this thread, I propose that [...]

Since I think that the 3 action items you proposed are all within the scope 
of the WCAG WG, I will answer that part of the email on that mailing list.

Best,
--wendy

>[1] ER-IG thread
>http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Jun/0010.html
>[2] UAAG Guideline 3
>http://www.w3.org/TR/UAAG10/guidelines.html#gl-feature-on-off
>[3] WCAG 2.0 issues tracking list http://www.w3.org/2002/09/wcag20-issues

[4] http://www.w3.org/TR/UAAG10/guidelines.html#tech-on-off-scripts
[5] http://www.w3.org/WAI/GL/WCAG20/#avoid-flicker
[6] http://lists.w3.org/Archives/Public/w3c-wai-gl/2002OctDec/0206.html
[7] http://www.w3.org/TR/AERT

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Saturday, 7 December 2002 20:20:03 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:41 GMT