Re: ARIA BPG Issue: we should not be decreeing complex keyboard interactions

Hi James,

A comment inline below:

James Craig wrote:
>
> It's hard enough to learn a screen reader anyway, but this approach
> will ask people to learn three different ways to interact with the
> same type of control.
>
>     1. How their screen reader interacts with the desktop version of
> the control.
>     2. How the screen reader interacts with a web control that doesn't
> have proper semantics defined.
>     3. How the screen reader interacts with a web control that has
> ARIA semantics defined.
>
> You said:
>
>> Every fieldset/form/control-based UI (and most of SAP UI's are
>> fieldset/form based) should be fully functional and accessible by
>> keyboard WITHOUT the need for additional AT keyboard navigation aids.
>
>
> Agreed. What I intended to say is that this should be left to AT
> vendors *and* browser vendors to decide how to implement, and again,
> they should behave as the native desktop versions of the controls
> behave. The job of ARIA is to define the semantics so that browsers
> and AT can know what type of control a DOM node is emulating and how
> the DOM attributes map to that control's properties. The job of ARIA
> is *not* to define, decree, and limit how the user interacts with that
> control.

I share the view/hope that ARIA (at least ARIA 1.0) is about defining
the semantics, and not the interaction. I would like to mention however,
that keyboard interaction in DHTML tends to be defined by the JavaScript
author, and not the Browser, or the AT. At the very least, we have to
deal with this scenario.

I recall testing a DHTML widget in dojo using Jaws, and Jaws, trying to
be helpful, told me (the user) what keystrokes I could use to interact
with the control. The problem here was Jaws was assuming this was a
native windows control and it 'help' wasn't quite correct.  I think the
hope here is the DHTML style guide work:
http://dev.aol.com/dhtml_style_guide

If Apple is going to base SproutCore interactions on native OSX
interactions, I'd like to see Apple represented on the style guide team.
We need to sort all this stuff out.

cheers,
David
>
> James
>
>
> Schnabel, Stefan wrote:
>
>> this would mean that we're in danger to leave sometimes important
>> functionality to AT and rely on their presence IN AT for optimal
>> operation of UI's and controls.
>>
>> Every fieldset/form/control-based UI (and most of SAP UI's are
>> fieldset/form based) should be fully functional and accessible by
>> keyboard WITHOUT the need for additional AT keyboard navigation aids.
>>
>> This includes also concepts for navigating grids and data tables without
>> AT.
>>
>> The full keyboard navigation concept is to be programmed later in JS
>> libraries being part of common frameworks. This CAN be done. There may
>> be some "defile" situations but if we leave the solution here always to
>> AT we'll get to nowhere.
>>
>> For me, this "screen reader uses a particular key command to controls a
>> widget" statement is extremely dangerous for this control MUST (and
>> will) always be controlled by JS framework code first. I will send you
>> the comments of our framework coders when AT starts to override their
>> key definitions .. know what I mean?
>>
>> I do not talk of plain classy web pages. Here (e.g. documentation) the
>> clever additional navigation aids of current AT will do the job
>> gracefully.
>>
>> So, bottom line:
>>
>> If (role=application) then (AT_do_separate_keyboard_navigation=false)
>>
>> - Stefan
>>
>> -----Original Message-----
>> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
>> Behalf Of James Craig
>> Sent: Mittwoch, 3. September 2008 21:13
>> To: wai-xtech@w3.org WAI-XTECH
>> Subject: ARIA BPG Issue: we should not be decreeing complex keyboard
>> interactions
>>
>>
>> Other than the most basic navigation controls, I don't agree with a
>> lot of the mouse and keyboard interaction specified in the ARIA BPG.
>> Many of the complex interactions specified (type ahead, Ctrl+Shift
>> +F10, Ctrl+Spacebar, Shift+PageDown, etc.) seem to me to be best left
>> for the AT vendors to decide how to implement and use to differentiate
>> themselves.
>>
>> This is exactly the reason properties like expanded and
>> activedescendant should be expected to be writable by the AT. If a
>> screen reader uses a particular key command to controls a widget in a
>> desktop application, it should be able to use that same key command to
>> control that type of widget in a web application. The interaction
>> models in every screen reader are different, and I believe that
>> decreeing browser and AT interaction design will stifle innovation.
>>
>> James
>>
>>
>
>

Received on Friday, 5 September 2008 17:20:03 UTC