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

James,

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 08:19:02 UTC