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 Thursday, 4 September 2008 18:03:11 UTC