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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility message

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


Subject: Re: [office-accessibility] [Fwd: Re: Accessibility concerns (ODF pt 1,public review 1)]


Hi Peter,

I agree that there might be issues with touch-based UIs, but it's not
clear to me if that really has much influence on the wording in the
specification.

At least for the concrete examples below.

But if you think there is room for improvement, please add a comment to
http://tools.oasis-open.org/issues/browse/OFFICE-2486 :)

Best,
Malte.

Peter Korn wrote, On 04/14/10 17:25:
> Malte,
> 
> We are seeing the rapid emergence of touch-based UIs, and touch isn't
> quite the same as a mouse (separate from the notion of multi-touch,
> which has no common mouse analog).  In that context, I think his
> comments have validity. 
> 
> At the same time, there are lots of interesting accessibility challenges
> around touch-based UIs.  Having spent a little bit of time playing with
> the iPad & iPhone through the built-in VoiceOver screen reader (and also
> having spoken with some blind users/fans of that combination), I am
> impressed with the job they did creating a good blind user interface. 
> But what I haven't seen is an interface that addresses non-blind users
> who lack hand-eye coordination of a different sort: they can't use their
> hands.  I understand that connecting a bluetooth keyboard to the iPad
> doesn't yield a keyboard-operable UI, and that is something very much
> needed by many with physical disabilities.
> 
> 
> So, to sum up: I think Alex's comments are valid: we shouldn't imply
> that the only way to interact with ODF forms is via mouse or keyboard. 
> But we should nonetheless continue to require that those interaction
> means continue to be supported, even while others (e.g. touch) are added
> to the mix.
> 
> 
> Regards,
> 
> Peter Korn
> Accessibility Principal
> Oracle
> 
> 
>> Hi Accessibility SC colleagues,
>>
>> the last mail on our mailing list was in April - last year - so I
>> thought it might be a good time for writing something here ;)
>>
>> Alex Brown has some concerns wrt wording in ODF specification and
>> accessibility.
>>
>> I don't share his concerns, but maybe somebody here has a different
>> opinion about this (see below)?
>>
>> Best,
>> Malte.
>>
>> -------- Original Message --------
>> Subject: Re: Accessibility concerns (ODF pt 1, public review 1)
>> Date: Wed, 14 Apr 2010 16:38:24 +0200
>> From: Malte Timmermann <Malte.Timmermann@sun.com>
>> To: Alex Brown <alexb@griffinbrown.co.uk>,
>> office-comment@lists.oasis-open.org
>>
>> Hi Alex,
>>
>> I don't see an issue here:
>>
>> Except via API access, there are two ways for the user to perform
>> actions: via Mouse, or via Keyboard.
>>
>> If the user uses some special tools like AT, it results in something
>> like keyboard/mouse for the application:
>>
>> When operating an onscreen keyboard via mouse, buttons or what ever, for
>> the application it's key input (only GOK might result in actions via API).
>>
>> When using some eye tracking or other mouse replacements, for the
>> application it's mouse input.
>>
>> But that's just my point of view.
>> I will bring this to the accessibility SC, and check if other people
>> think differently about this.
>>
>> Best,
>> Malte.
>>
>> Alex Brown wrote:
>>   
>>> Dear all,
>>>
>>> A lot of language in this specification mandates/assumes the use of a screen/keyboard/mouse based computing environment.
>>>
>>> For example:
>>>
>>> ----
>>> 19.267 form:default-button
>>>
>>> The form:default-button attribute specifies whether a button is the default button on a form. If a user clicks the default button or presses Return while an input control is focused, the implementation takes the same action.
>>> ----
>>>
>>> or
>>>
>>> ----
>>> 19.276 form:focus-on-click
>>>
>>> The form:focus-on-click attribute specifies if a <form:button> element is given the focus in a form when the form button control for that element is clicked with a mouse.
>>> ----
>>>
>>> A thorough pass should be made of the text, generalising such language to ensure ODF does not privilege certain non-accessible computer environments.
>>>
>>> - Alex.
>>>     
>>
>>
>>
>>   
> 


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