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

You wrote:

> The job of ARIA  
> is *not* to define, decree, and limit how the user interacts with that

> control.

> they should behave as the native desktop versions of the controls  
> behave.

Both Agreed. But what will you do if there is no keyboard standard even
for the same control type on desktops?
Imagine 20 3d party WPF-based MS grid controls that work differently
here .. what to take as "standard"?

For me, to address both of your comments, this is the job of
http://dev.aol.com/dhtml_style_guide. 
This is an *important* work in progress. 

When we talk about industry and their web control sets these
- always have proper semantics defined
- need a documented and working keyboard accessibility implementation
without AT aids
- need reliable test procedures for QA based on above two
- need AT that follows this concept, not guides

I think the implementation work has to go in the direction

1. web controls navigation work the way the style guide defines
2. AT knows that and *does not interfere* with that basic navigation
when aria role of control is known
3. AT may offer additional (NOT different) navigation aids for these
controls

I do not think that a proprietary AT navigation for aria roles is a
blessing for the web. 
The problem is that in the past this definition part has been left
totally to the AT vendors and you know the outcome.

- Stefan


-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Donnerstag, 4. September 2008 20:03
To: wai-xtech@w3.org WAI-XTECH
Cc: Schnabel, Stefan
Subject: Re: ARIA BPG Issue: we should not be decreeing complex keyboard
interactions

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.

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 06:36:04 UTC