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 totally agree with Peter...

Malte.

Peter Korn wrote:
> Dave,
>
> 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.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>> 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.
>>
>>
>> regards
>>
>>   
>


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