OASIS Open Document Format for Office Applications (OpenDocument) TC

Expand all | Collapse all

Fw: [office-accessibility] Re: [office] Table Refresh Delay

  • 1.  Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-19-2008 14:31

    "Dave Pawson" <dave.pawson@gmail.com> wrote on 07/19/2008 02:00:50 AM:

    > 2008/7/18 Peter Korn <Peter.Korn@sun.com>:
    > > Hi Dave,
    > >
    > > 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.
    >
    >
    > Table refresh isn't animation Peter.
    >
    > I'm more in favour of accessibility than Sun commercial interests.
    >

    Please, let's all refrain from questioning the motives of other colleagues on the TC.  

    The question we have is:

    1) What is the risk?
    2) What are the possible ways to mitigate the risk?
    3) What method or combination of methods reduces the risk to acceptable levels?

    It seems to me that an application-level setting to disable animation or other sources of flicker is one way to mitigate the risk, and should be considered.

    -Rob


  • 2.  Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-20-2008 13:17
      |   view attached



  • 3.  Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-20-2008 13:17



  • 4.  Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-20-2008 13:35
    2008/7/20 Richard Schwerdtfeger 


  • 5.  Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-20-2008 13:35
    2008/7/20 Richard Schwerdtfeger 


  • 6.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table RefreshDelay

    Posted 07-20-2008 21:19
    
    
      
      
    
    
    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.



    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.
    
    
    regards
    
      



  • 7.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-21-2008 07:30
    2008/7/20 Peter Korn 


  • 8.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table RefreshDelay

    Posted 07-21-2008 12:36
    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 


  • 9.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-21-2008 12:53
    Compromise.
    
     "Note: Blink rates of more than 3 times a second have been identified as
     dangerous for some human physical conditions especially on large or
     magnified text and other screen objects. Implementions may be required
     to avoid such behaviour by local law or regulation. A future version of
     this standard may deprecate such blinking, on scientific advise. This
     note applies to table refresh of fields as well as screen animations and
     text display."
    
    
    Could we add that to the spec.
    
    
    regards
    


  • 10.  Re: [office-accessibility] Re: [office] Re: Fw: [office-accessibility]Re: [office] Table Refresh Delay

    Posted 07-21-2008 13:35
    I agree on adding some text describing the situation / some advice.
    
    I don't agree on "future version of this standard may deprecate...".
    
    Malte.
    
    
    Dave Pawson wrote, On 21.07.08 14:52:
    > Compromise.
    > 
    >  "Note: Blink rates of more than 3 times a second have been identified as
    >  dangerous for some human physical conditions especially on large or
    >  magnified text and other screen objects. Implementions may be required
    >  to avoid such behaviour by local law or regulation. A future version of
    >  this standard may deprecate such blinking, on scientific advise. This
    >  note applies to table refresh of fields as well as screen animations and
    >  text display."
    > 
    > 
    > Could we add that to the spec.
    > 
    > 
    > regards
    > 
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
    > 
    


  • 11.  Re: [office-accessibility] Re: [office] Re: Fw: [office-accessibility] Re: [office] TableRefresh Delay

    Posted 07-21-2008 15:18



  • 12.  Re: [office-accessibility] Re: [office] Re: Fw: [office-accessibility] Re: [office] Table Refresh Delay

    Posted 07-21-2008 15:36
    2008/7/21 Richard Schwerdtfeger 


  • 13.  Re: [office-accessibility] Re: [office] Re: Fw: [office-accessibility]Re: [office] Table Refresh Delay

    Posted 07-21-2008 18:59
    
    
      
    
    
    Dave,

    FYI - I'm happy with significantly stronger language.  I also think we should cite that the specific danger is a seizure.  I think we have a little time to work this through (the deadline for inclusion in both ODF v1.2 and our next guidelines document is some time away).  Let's take some time to hammer out this language, and perhaps discuss at one of our next SC meetings.


    Regards,

    Peter Korn
    Accessibility Architect,
    Sun Microsystems, Inc.

    711a73df0807210835j43e08be4o9414966df3d493df@mail.gmail.com" type="cite">
    2008/7/21 Richard Schwerdtfeger <schwer@us.ibm.com>:
      
    This fine although I don't know that we can make the deprecation point. I
    don't believe the TC will agree on that based on their other requiremetns.
    We should synch our wording with the odf accessibility guidelines and we
    should be more prescriptive.
        
    
    I'd prefer it as a requirement in the standard Rich, but hows this,
    pandering to implementers.
    
    
      Blink rates of more than 3 times a second have been identified as
      dangerous for some human physical conditions especially on large or
      magnified text and other screen objects. Implementations may be required
      to avoid such behaviour by local law or regulation.
     This  note applies to table refresh of fields as well as screen animations and
      text display."
    
    Is that strong enough?
    
    Can you take it forward please?
    
    I think Peter/Malte are OK with this version.
    
    regards
    
    
    
    
      



  • 14.  Re: [office-accessibility] Re: [office] Re: Fw: [office-accessibility]Re: [office] Table Refresh Delay

    Posted 07-21-2008 15:28
    Dave,
    
    I have no problem using strong language to tell ODF implementers about 
    this problem, nor to suggest that the simplest way to ensure this isn't 
    a problem is to avoid blink rates faster than 3Hz.  Especially to avoid 
     >3Hz by default.  I'm fine with recommending this for both the ODF 
    spec. itself, and of course our own guidelines.
    
    I don't want to make it illegal to do so either as a spec. violation, or 
    to say that in all cases greater than 3Hz is a problem as our current 
    best knowledge is that there are well defined situations in which it 
    isn't a problem.
    
    
    Regards,
    
    Peter Korn
    Accessibility Architect,
    Sun Microsystems, Inc.
    > Compromise.
    >
    >  "Note: Blink rates of more than 3 times a second have been identified as
    >  dangerous for some human physical conditions especially on large or
    >  magnified text and other screen objects. Implementions may be required
    >  to avoid such behaviour by local law or regulation. A future version of
    >  this standard may deprecate such blinking, on scientific advise. This
    >  note applies to table refresh of fields as well as screen animations and
    >  text display."
    >
    >
    > Could we add that to the spec.
    >
    >
    > regards
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
    >
    >   
    
    


  • 15.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table RefreshDelay

    Posted 07-21-2008 12:36
    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 


  • 16.  Re: [office] Re: Fw: [office-accessibility] Re: [office] Table RefreshDelay

    Posted 07-20-2008 21:19
    
    
      
      
    
    
    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.



    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.
    
    
    regards