Gregg volunteered Trace to look into the development of a tool to measure flicker. Still isn't clear whether this is doable.
In the absence of a tool, we should try to come up with the best that we are comfortable with.
GV: Proposed success criteria:
LR: Fire alarm strobes must be over 120
GSW: It doesn't matter why the screen flashes, it is still a big issue. We shouldn't divide by checkpoint. All should be level 1
GV: What if it flickers if you run on a very slow computer, but not fast one? The alternative is that you can never use any technology that refreshes at all unless you do it very slowly so you know it will never flicker
GSW: Isn't this a backwards-compatability issue? Shouldn't we assume everyone is running a computer fast enough not to cause this?
GV: There are browsers on cell phones that are very slow
CS: You may have a particular monitor that causes the effect. There is no way for a content-provider to test all the configurations user might have.
GW: The tool wouldn't test for flicker; author would test for passing the tool
CS: It may be difficult to have a tool that captures everything
GV: But it can cover lots of egregious stuff
GV: I worry that if level 1 requires no flicker, no company could ever make such a claim. Then they would never make minimum conformance.
GV: If any level 1 requirements can be legally construed as dangerous, companies will not try to meet minimum
GV: We are asking people to say for each point what they have done. Previously (WCAG1) claims were broader/softer.
CS: This fails testability. But claiming that it wasn't designed to flicker is testable.
MM: We can't ever ask people to prove a negative. When we create claims for compliance, authors must be able to assert that "it worked for us in this environment"
GV: The compatability issue is interesting. Users would have to use hardware that stayed within the parameters tested.
CS: Design and tested on certain equipment seems a reasonable claim
GSW: How to you specify what equipment to test on?
CS: We don't say what to test on, but author must describe what platform it was tested on
GV: This seems really complicated; can we use EARL to record this? in a way that is useful to people searching for safe web sites
CS: Wendy and I have done some thinking about this (recording hardware configs in EARL)
GV:
GV: Note: Trace should do a dual ended tool! authors run against site, and users run against machine!
CS: We could provide it to hardware manufacturers
MM: It would then be easy to write a back end, based on the specs
GW: Because of potential interactions, I don't think you want to make claims unless you actually ran the test; but if you can give it to users to test their own equipment, this is very good. Butthe person may need to leave the room so that running the test doesn't trigger a seizure
GSW: Is this someting we can really do? there are lots of reasons people might sue one another; can we think of all of them?
CS: We probably can't, but our testability requirement covers this issue
GV: If vendors can claim that they tested according to guidelines, they are ok
GSW: Can we be sued?
GV: No, we didnt' do anything, unless there was actual negligence in putting together the guidelines
GV: Level 2 could be "tested with at least 3 hardware configurations (standard manufacturer configs) and no flicker detectable with ..."
LR: What about small designers trying to comply?
CS: I propose "designed not the flicker", rather than "not designed to flicker"
GW: Some sites were designed intentionally to flash; but how can someone design to "not behave"
CS: I see.
GV: Let's leave the test as a note at level 1
GV: Does anyone want to do legwork on developing this tool? contact Gregg.
GV: Highlights: Level 1 guideline content: if this causes seizures, don't want to demote to level 2 things that causes seizures for some people. Level 2 should be less restrictions on users and the equipment they can use, rather than fewer people getting seizures. We shouldn't ask companies to guarantee that something won't happen, only to state that they did something or that something didn't happen. (testable)
GV: LR provided criteria, [[Gregg reading from Lee's message]]
GSW: What if someone decides on dark blue background with white text - is that unacceptable? what about color-blind folks who have trouble with derivatives of colors?
GV: Light on dark vs dark on light is a different discussion from whether there is contrast.
GSW: There is an issue with defining dark and light
GV: We need to quantify "sufficient"
CS: There must be research on this for RGB
LR: I couldn't find any numbers
CS: Don't use percentages for ratios, but use RGB values themselves
GV: e.g. if on a scale of 256 there needs to be a 200 point spread?
GV: Saturation and darkness are important. If they are similar for the 2 colors, this will cause potential problems
CS: Can we find someone with expertise in this area?
GV: Everytime I've talked to experts, they don't want to do anthing practical
WC: There is a tool called VisTech that may be useful
GV: Spread needs to be in darkness rather than hue
CS: We are picking RGB because that is how colors are expressed in HTML
GV: RGB is also used for monitors; it's our best Rosetta stone
MM: The number of bits of RGB is related to monitor color depth; CSS level 3 has finer control over color than HTML, which is RGB-only
Highlight - using notion of spread (or percentage of full scale) of darkness
Highlight - is RGB the best basis for this checkpoint?
Wendy will investigate this spread idea
CS: Does anyone have an on-line URL for basic color theory
GV: We need to stay with display color theory, not print color theory
GV: I did not including Lee's success criteria in highlights because of the problems already identified; will include link to his message
WC: The list of references should go someplace stable, so people can find them and add to them. maybe in techniques?
GV: What do we do with mixed good info/ misinformation? How do we keep good info available
CS: Bibliography?
GV: Putting in techniques implies we are recommending them. But this info just gets lost in the archives. Who can deal with this? Wendy is too busy. Can someone work with Ben?
WC: I'm already keeping track of people who need to review different topics; in some ways I'm already keeping track of this: resource and references associated with a topic. I can do that. Lots will get incorporated into the core techniques.
BC: Additional color blindness resources available off Trace web site
WC: Send me a link
GV: Anything else on color? one other highlight: it is probably good for us to use theory for display technology rather than print technology. Think about using numbers or scales used by authors.
GV: Wendy proposed something for the GL homepage to the chairs.
WC: It's already done. I redesigned our home page to make it easier to find things. 2 major changes: all the things related to WCAG2 are moved to a separate page. I tried to highlight major things we are working on. I added more navigation at the top and added images. It makes it look better and feel less overwhelming.
WC: The images are icons for each major section; there are probably still some broken links. People should look at it and give feedback on whether this is more or less confusing.
GV: I suggested moving WCAG1 to a separate page, too. It seems to have been done already . We need to indicate that WCAG2 is the future work, but WCAG1 is what is in effect right now
GV: Here are techniques for 1.0; why isn't that in the 1.0 area?
WC: I heard continually that people can't find the techniques documents
$Date: 2002/05/24 21:45:12 $ Loretta Guarino Reid