That value gets set in WebKit's WebFrame.mm:
if ([[NSApp
accessibilityAttributeValue:NSAccessibilityEnhancedUserInterfaceAttribute]
boolValue])
AXObjectCache::*enableEnhancedUserInterfaceAccessibility*();
What is that mysterious NSAccessibilityEnhancedUserInterfaceAttribute? It's
a secret AppKit value, equaling @"AXEnhancedUserInterface". What's *that*?
Oh, it's a magical value set by VoiceOver as a hint to certain internal
AppKit controls to alter their behavior slightly to make life better for it.
(See
http://lists.apple.com/archives/accessibility-dev/2006/Feb/msg00009.html ).
That message is the only documentation past seeing it in WebKit archives.
I'm fine with this, but I just want to know how I can do both...
Avi
On Thu, Mar 5, 2009 at 4:34 PM, Thomas Van Lenten <[email protected]>wrote:
> Does the universal access setting w/in safari's prefs change this in any
> way?
>
> TVL
>
>
>
> On Thu, Mar 5, 2009 at 4:30 PM, Avi Drissman <[email protected]> wrote:
>
>> I'm trying to figure out the exact meaning of
>> accessibilityEnhancedUserInterfaceEnabled because I'm getting that effect on
>> my Mac without any accessibility. In addition, what I forgot to mention is
>> that *both* ctrl *and* ctrl+alt work in Safari for me, while we can only
>> pick one to return from accessKeyModifiers() and whichever one we don't
>> return doesn't work.
>>
>> Avi
>>
>>
>> On Thu, Mar 5, 2009 at 4:24 PM, Ben Goodger (Google)
>> <[email protected]>wrote:
>>
>>> It sounds like they only use the single modifier when the
>>> accessibility system setting is turned on, otherwise they use the dual
>>> one. Why don't we just do the same thing? I'm pretty sure we should
>>> match the platform default browser instead of emacs.
>>>
>>> -Ben
>>>
>>> On Thu, Mar 5, 2009 at 1:22 PM, Avi Drissman <[email protected]> wrote:
>>> > The definition of what the accesskey modifier is the result of
>>> > EventHandler::accessKeyModifiers(). On Windows it's alt, and on
>>> Chromium
>>> > it's also alt.
>>> >
>>> > The question is: What to make it on the Mac? And how to do it right?
>>> >
>>> > Mozilla apparently switched recently to use the command key. They used
>>> to
>>> > use the control key. What does Safari use? Much more difficult
>>> question. The
>>> > code says:
>>> >
>>> >> unsigned EventHandler::accessKeyModifiers()
>>> >> {
>>> >> // Control+Option key combinations are usually unused on Mac OS X,
>>> but
>>> >> not when VoiceOver is enabled.
>>> >> // So, we use Control in this case, even though it conflicts with
>>> >> Emacs-style key bindings.
>>> >> // See <https://bugs.webkit.org/show_bug.cgi?id=21107> for more
>>> >> detail.
>>> >> if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled())
>>> >> return PlatformKeyboardEvent::CtrlKey;
>>> >>
>>> >> return PlatformKeyboardEvent::CtrlKey |
>>> PlatformKeyboardEvent::AltKey;
>>> >> }
>>> >
>>> > And if you go to the layout test, you'll see that on the Mac it uses
>>> the
>>> > modifiers ctrl+alt. This solution is problematic for two reasons.
>>> >
>>> > The first is that using a dual modifier sucks. It makes it extremely
>>> > difficult to use accesskeys.
>>> >
>>> > The second is that triggering them with a single modifier (just the
>>> ctrl
>>> > key) on my machine works fine in Safari. Which puts me in a quandary,
>>> > because I'm not sure how Safari's doing that (I'm digging now). If we
>>> alter
>>> > our accessKeyModifiers() to return the dual modifier, layout tests
>>> start
>>> > passing, but it's hard to use. If we use just ctrl, then it's easy to
>>> use
>>> > but we fail tests. And somehow Safari does both...
>>> >
>>> > Avi
>>> >
>>> > >
>>> >
>>>
>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---