OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Re: Fw: [office-accessibility] Re: [office] Table RefreshDelay


I believe there are two, separate issues here.  They are:

 1. What are the appropriate units to use for table refresh in ODF?
     -> what I've heard suggested from TC members is the ISO standard for this, which allows time to be expressed in milliseconds as well as larger increments

 2. Where is/are the appropriate place/s to ensure that user interactions with an ODF document won't cause a seizure?
     -> what I suggest is the appropriate place is in the ODF application, not the document format specification

The reasons I suggest the appropriate place is in the ODF applications are:

 1. The app is where the rendering & user interaction occur
 2. Not in all cases does a table refresh have the potential to trigger a seizure (only if enough of the field of view is making a sufficient luminosity change in the triggering frequency range).
 3. My belief that the purview of the ODF accessibility subcommittee is accessibility issues (and not anything beyond that).  I personally feel free to offer my opinions on all manner of things ODF-related, but I do so as a member of OASIS interested in ODF; not with my "accessibility hat" on.
 4. My own sense that user interface considerations should not dictate encoding schemes, they should simply place requirements on what is needed (and thus I wouldn't say that the only valid table refresh number must explicitly be outside of the range of 3-50Hz).

Thus whether or not I believe a vendor or any application author does or does not have good reason to update some portion of the screen at greater than >3Hz, my sole accessibility concern is whether that update has the other attributes needed to trigger a seizure.  If not, then my aesthetic or other considerations are only those, and not an accessibility statement. 

And I further believe that only the rendering application is in a position to make the determination as to whether the other seizure-triggering characteristics are at play or not (e.g. a two cell table in 9 point font where only black pixel text on a white background is updating at potentially 5Hz when displayed on a 1280x1024 screen at 72dpi should be well below the seizure threshold, while a table update that includes changing the background color of the cell from black to white in a 50 cell table at 24 point font at 5Hz is certainly over the threshold). 

Whether or not something is a good idea from a design or aesthetics point of view, if it doesn't cause a true accessibility problem then it isn't my job to make sure it is fixed.


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

711a73df0807200634k1c2321a8n27ec1b45076929a1@mail.gmail.com" type="cite">
2008/7/20 Richard Schwerdtfeger <schwer@us.ibm.com>:

My suggestion would be to be to take an excerpt from our ODF accessibility
Guidelines for 1.2 and place it in the ODF guidelines in the section on
Table Refresh Delay. Something on the order that Office applications SHOULD
provide a facility to enable the user to limit table refresh delays to no
more than three times per second. Failure to do so may cause seizures in
some ODF users.

We could make this a MUST but I don't know of all uses for ODF documents.
Additionally, we should provide guidance to ODF content authors which would
be in line with this W3C WCAG requirement.

Tell me a vendor who justifiably refreshes at >3Hz in a human facing app?

Yet again we bow to the vendors Rich?
Pretty please instead of do it because its right?

I'll ride with it, but it's wrong IMO.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]