OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only

Re: [office] Re: [office-accessibility] Re: [office] Fw:[office-accessibility] Inclusion of tables in the .odp profile forpresentations

  • 1.  Re: [office] Re: [office-accessibility] Re: [office] Fw:[office-accessibility] Inclusion of tables in the .odp profile forpresentations

    Posted 02-24-2006 09:50
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    office message

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


    Subject: Re: [office] Re: [office-accessibility] Re: [office] Fw:[office-accessibility] Inclusion of tables in the .odp profile forpresentations


    Bad thing with embedded object is
    
    - If you read the slide with AT, you can't read the content of OLE objects
    
    - Activation normally doesn't help here, you would have to read the
    content from OLE separately
    (Special OOo implementation of internal OLE objects could change that,
    but...)
    
    - You can't activate OLE in read-only documents
    
    - OLE objects can't grow while editing, which would be really bad for
    table editing
    
    
    Malte.
    
    
    
    Lars Oppermann wrote:
    > Hi Guys,
    >
    > Just a quick question here: is it, from an A11Y perspective absolutely 
    > unacceptable to have embedded tables? If the application is able to 
    > activate the embedded object in-place and the activated context is 
    > sufficiently accessible...
    >
    > Also from a file-format perspective, the structural information would be 
    > available, if the embedded table object is ODF.
    >
    > I understand, that this is not very lightweight. I would like to know 
    > whether it has to be ruled out completely from an A11Y point of view.
    >
    > All the best,
    > /lars
    >
    > Richard Schwerdtfeger wrote:
    >   
    >> Since not everyone is an accessibility expert - The reason we need a 
    >> real table construct in presentations is that we need to be able to do 
    >> structural navigation. We need to have row, column constructs, headers, 
    >> etc. otherwise we have an inaccessible solution. We will also have to 
    >> address keyboard navigation of tables once we have a "tables for 
    >> presentations" specification.
    >>     
    >
    >   
    


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