Re: Keyboard navigation in viewer pane - 3 scenarios.

Hence my original cautionary note. Not to throw cold water on things but 
in addition to the OS and browser we need to consider that screen 
readers also reduce the number of available key combinations. Luckily 
much of the alt key combination space is unclaimed so while 1:1 parity 
with desktop apps may not be possible, similar alt-key combinations 
should be.

CB

Earl.Johnson@Sun.COM wrote:
>
> Bummer but thanks Charles.
>
> This makes it sound like there is no way to guarantee browser and 
> desktop component key sequences can be harmonized when the browser or 
> desktop have already claimed them for another use. Is this correct or 
> is there some other way to tell the browser and desktop "send these 
> keystrokes to the web component for its use instead of claiming them"?
>
> Earl
>
> btw - it's probably clear now but the research mentioned below was all 
> "book" based, not prototype testing.
>
>
> Charles McCathieNevile wrote:
>>
>> On Sat, 14 Jul 2007 08:29:08 +0900, Earl Johnson 
>> <Earl.Johnson@sun.com> wrote:
>>
>>> Hi Chris;
>>>
>>> My understanding, from a researcch only stance, is all keysequences 
>>> can be repurposed in javascript so the browser never sees the keypress.
>> ...
>>> I assumed a re-purposing function/method similar to this would work 
>>> for all since jabvascript, being in the page content, always sees 
>>> the keystrokes before the browsxer even.
>>
>> Nope, the browser decides to pass the key (or not) which it gets from 
>> the OS (or not). The web app only gets it if nobody else has already 
>> claimed it - while that is the default it doesn't always happen. 
>> Otherwise things like one-handed keyboard drivers would be impossible 
>> to write...
>>
>> Cheers
>>
>> Chaals
>>
>> --  Charles McCathieNevile, Opera Software: Standards Group
>>   hablo español  -  je parle français  -  jeg lærer norsk
>> chaals@opera.com    Catch up: Speed Dial   http://opera.com
>>
>

Received on Tuesday, 17 July 2007 19:10:01 UTC