|Richard Schwerdtfeger||Jul 12, 2008 8:52 am|
|Duane Nickull||Jul 12, 2008 8:30 pm|
|Richard Schwerdtfeger||Jul 14, 2008 11:31 am||.gif, .gif, .gif, 7 more|
|robe...@us.ibm.com||Jul 14, 2008 1:48 pm|
|Duane Nickull||Jul 14, 2008 2:21 pm|
|Richard Schwerdtfeger||Jul 16, 2008 10:55 am||.gif, .gif, .gif, 7 more|
|robe...@us.ibm.com||Jul 16, 2008 11:36 am|
|Richard Schwerdtfeger||Jul 17, 2008 4:46 pm||.gif, .gif, .gif, 7 more|
|Malte Timmermann||Jul 18, 2008 2:07 am|
|Dave Pawson||Jul 18, 2008 3:49 am|
|Richard Schwerdtfeger||Jul 18, 2008 6:26 am||.gif, .gif, .gif, 7 more|
|Duane Nickull||Jul 18, 2008 9:23 am||.gif, .gif, .gif, 6 more|
|Peter Korn||Jul 18, 2008 10:36 am|
|Duane Nickull||Jul 18, 2008 11:12 am|
|robe...@us.ibm.com||Jul 18, 2008 11:50 am|
|Warren Turkal||Jul 18, 2008 1:28 pm|
|Duane Nickull||Jul 18, 2008 1:58 pm|
|Warren Turkal||Jul 18, 2008 2:03 pm|
|robe...@us.ibm.com||Jul 18, 2008 2:12 pm|
|robe...@us.ibm.com||Jul 18, 2008 3:30 pm|
|Peter Korn||Jul 18, 2008 3:44 pm|
|Duane Nickull||Jul 18, 2008 4:10 pm|
|Warren Turkal||Jul 18, 2008 4:41 pm|
|Dave Pawson||Jul 18, 2008 11:00 pm|
|robe...@us.ibm.com||Jul 19, 2008 7:30 am|
|Richard Schwerdtfeger||Jul 20, 2008 6:16 am||.gif, .gif, .gif, 7 more|
|Dave Pawson||Jul 20, 2008 6:34 am|
|Peter Korn||Jul 20, 2008 2:19 pm|
|Malte Timmermann||Jul 21, 2008 5:35 am|
|Subject:||Re: [office] Table Refresh Delay|
|From:||Warren Turkal (tur...@google.com)|
|Date:||Jul 18, 2008 2:03:42 pm|
-office-accessibility since I am not a member of that list and can't post.
I am in favor of using ms. I'm not sure that more granularity would actually buy us anything.
On Fri, Jul 18, 2008 at 1:57 PM, Duane Nickull <dnic...@adobe.com> wrote:
I think the key question was around refresh rate values and what they meant. This has digressed slightly. I had suggested milliseconds is a good measurement of time for the value. Whether or not it can cause epileptic fits is none of my concern. Looking at ugly ODF docs or other content has an equal wieght in this regard and the onus is on the author â we are not telling people what content to use.
I would like to ask for a decision â milliseconds as a measurement for refresh rates or ????
What is the alternative people are thinking of if not milliseconds?
The key point in my mind is that the nature of the problem ("a risk of causing an epileptic fit") may raise this from an accessibility issue to a safety issue.
ISO Directives, Part 2, section A.2.3 gives the following guidance:
"A.2.3 If health, safety aspects, the protection of the environment or the economical use of resources are relevant to the product, appropriate requirements shall be included. Otherwise, they may, in some countries, be made additional mandatory requirements which, if not harmonized, would constitute technical barriers to trade.
These requirements may need to have certain characteristics with limiting values (maximum and/or minimum) or closely defined sizes and, in some cases, even constructional stipulations (for example, to achieve non-interchangeability for safety reasons). The levels at which these limits are fixed shall be such that the element of risk is reduced as much as practicable."
So I think we should make some statement in the standard itself, not merely in a separate guidelines document, that defines how to use this feature safely.
Which leads me to the technical questions:
1) Surely, the table refresh itself is inoffensive, right? For example, an application could have a table refresh (fetch new data) but only display updates when some other condition was met. Or you might not have any GUI at all and the updates and recalc's trigger some action on the server.
2) Is any screen update faster than once every 3 seconds a problem? Or is it only certain styles of updates, the ones which noticeably "flash" because of poor redrawing, lack of double buffering or whatever? In other words is there any safe way of doing rapid screen updates?
3) Most display technologies are already redrawing at a fast rate. This is inherent in the graphics card/display technology. So very fast rates are OK? What is the range of rates where it is a problem?
4) How do we state this in the standard? Would something like this work: "Note: display devices which update information on the screen at rates between X Hz and Y Hz have been shown to prompt epileptic seizures in some people. ODF applications which refresh the display with each table refresh shall provide an option for the user to suspend the rendering of such refreshes." We could probably make a more general statement on refresh/animation/blink and place it in the conformance section of the standard.
Duane Nickull <dnic...@adobe.com> wrote on 07/18/2008 02:12:38 PM:
The main point is that implementors have control when implementing the specification vs. being constrained by the spec. Let's not put weightless restrictions into the specification.
On 18/07/08 10:35 AM, "Peter Korn" <Pete...@Sun.COM> wrote:
In OpenOffice.org we have the ability to turn animation off. I agree with Malte; we shouldn't prevent the expression of fast animation for those who want it, but we should enable users to not have it displayed to them.
Peter Korn Accessibility Architect, Sun Microsystems, Inc.
I don't agree on "require user agents to limit this to no more than 3 times a second".
I must admit that I don't believe a higher frequency would make any sense for anything, but People have different needs, and if someone for what every reason needs a higher frequency, the application should be allowed to support this.
Strongly disagree Malte.
If there is a riks of causing an epeleptic fit, then I'd like to see a 'shall' statement in the standard requiring nothing more than 3 times per second.
Peoples needs are my concern too.
-- ********************************************************************** Senior Technical Evangelist - Adobe Systems, Inc. Duane's World TV Show - http://www.duanesworldtv.org/ Blog - http://technoracle.blogspot.com Community Music - http://www.mix2r.com My Band - http://www.myspace.com/22ndcentury Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html **********************************************************************