Re: [Accessibility-ia2] IA2_STATE_PINNED

[Arnstein Skåra]

"Temporarily fixed" didn't give me an intuitive understanding. 
Temporarily would tell me something about duration. Perhaps it would 
make more sense, in my opinion, to just remove "temporarily".
Something pinned, doesn't have to be un-pinned, it may remain pinned 
indefinitely. Like pinning a program to Windows7's taskbar.


Arnstein / RaZiel

On 30.11.2010 18:33, Pete Brunet wrote:

How is this for the description of IA2_STATE_PINNED?

Indicates that an object is temporarily fixed at a certain location.  
One example is a browser tab that when pinned cannot be moved until 
unpinned.  Another example is a movable or floating object that when 
pinned remains in its pinned location until being unpinned.


David, Can a pinned FF tab be closed?  I am assuming pinned doesn't 
imply anything about an object's delete-ability.  BTW, TabMixPlus adds 
a "protected" context menu item for tabs.  You can't close a tab in 
this state.


Pete

Pete Brunet wrote:

Thanks to David and Brian.  I think "pinned" is the right word to use.
--
*Pete Brunet*

a11ysoft - Accessibility Architecture and Development
(512) 238-6967 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

Brian Cragun wrote:
Pinned is widely used with "floating" menus or objects.   Pinning 
the object keep it in one place and/or on the uppermost layer, where 
it is visible.  People use pinning so they can keep the item visible 
for quick access or reference.  We might take clues from the purpose 
and use of pinning.


In a serial audio stream, pinning is a little more than persistance, 
it infers keeping it handy, available, easily findable, quick 
reference.   Permanent is too strong, because you can "unpin" it. 
 But temporarily permanent is accurate.


Regards,

Brian

Brian Cragun
IBM AbilityLab Consultant
Human Ability & Accessibility Center
www.ibm.com/able& w3.ibm.com/able
W:(720)-663-2801H:(507)288-2437




From: Pete Brunet 
To: IA2 List 
Date: 11/30/2010 09:14 AM
Subject: Re: [Accessibility-ia2] IA2_STATE_PINNED
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org




Is "pinned" a widely used GUI concept?  It brings to mind something 
that is movable but currently fixed at a certain position, i.e. it 
conveys two concepts, neither of which seems to exactly fit the 
scenario given by David.  It seems "permanent" (or "persistent") 
would be a better word.


Pete

James Teh wrote:
On 19/11/2010 5:23 AM, David Bolter wrote:

In Firefox 4 betas you can pin browser tabs. This means that the tab
will become a permanent tab that is visually distinct and appears
together with other pinned tabs to the left of the regular tabs.

It's worth noting that this is not an application specific concept. It
appears elsewhere (e.g. Windows 7 taskbar and Start menu) and will
probably continue to appear in new applications as well.


So, create an IA2_STATE_PINNED or expose an object attribute?

My vote is for the state. This is a boolean state, so a state makes
sense. In addition, having it as an object attribute when it could be a
state suggests that it is an application specific hack, and is this
case, it probably shouldn't be implemented as a boolean value at all.

The practical problem with exposing it as a state is that we need a
revision to the IA2 IDL, which may take time that Firefox 4 doesn't 
have.


Jamie







___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
   



___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

[Accessibility-ia2] Recursively finding the object containing the caret is painfully slow.

[Arnstein Skåra]

Hi!

A brief description of the current situation:
1.Place caret within a paragraph.
2.Get the focused IAccessible object.
3.Traverse it's children to find the IAccessible2 object containing the caret.

This approach is how you are supposed to do it, according to the implementation 
guide.
It is a very time consuming operation. An example of how bad it can get is 
www.inetword.com.

Alexander Surkov proposed a method to deal with it:

[propget] HRESULT accessibleWithCaret ([out, retval] IUnknown **accessible);

Returns the accessible object containing the caret.  If the caret is in
an accessible in a tree of accessibles the returned accessible is the
one actually containing the caret, i.e. a leaf node in the
accessibility tree.

Parameters:

 [out] accessible   The returned accessible contains the caret.

Returned Values:

 S_OK
 S_FALSE   if there is no accessible in the entire accessible hierarchy 
containing a caret


- Arnstein

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Recursively finding the object containing the caret is painfully slow.

[Arnstein Skåra]

Here is an use case and additional information:

Joe = any user.
X = our product. A .Net GUI application, providing textual feedback.

Use case:
-
1. Joe is writing in Firefox, he is also using X. He expects to get 
feedback on what he writes through X.
2. X needs to know where and what Joe is writing. X already knows he is 
writing in Firefox.
3. X will use IAccessible2 to communicate with Firefox, to get what it 
needs.
4. X will conform to the IAccessible2 implementation guide for a client. 
It will find the focused object (see below),  and traverse the document 
hierarchy to find the caret object.
5. The caret object will give X what it needs to report back to Joe.

Motivation:
---
X needs non-event based IA2 client code to be isolated in a C dll. IA2 
already provides the means to satisfy X.

Problem:

But Joe is not satisfied, he is experiencing inconsistent timing of 
feedback from X.
The cause is located in use case step 4. The time it takes to find the 
caret object depends on the document currently
being viewed. The deeper the a11y tree the worse the performance. An 
example of a deep tree can be viewed at  www.inetword.com.
Joe shouldn't have to experience this inconsistency.

Solution:
-
IA2 spec should relieve any IA2 client of the need to traverse the 
document hierarchy to find the caret object.
In a document the caret can only be at one location at any given time. I 
assume an IA2 server knows at any given time
where the caret object is, therefore it should be easy to provide it to 
a client. Such as through the proposed  accessibleWithCaret() method.

The design choice of the DLL:
-
IA2 doesn't require a client to be listening to events.
If the DLL would subscribe to events with SetWinEventHook(), it will 
need a message queue.
A message queue requires a GUI thread, at the very least you need to 
create a message-only window in a new thread.
You will then have to deal with that operations are not mutually 
exclusive. For example X calls the DLL, and the DLL's message-only 
window is notified by an event at the same time.
It is simply put more complicated than it needs to be. Adding the 
accessibleWithCaret() method is beneficial regardless of choice of 
client approach.

How to find the focused object in a non-event based client:
---
1. GetGUIThreadInfo(). See 
http://msdn.microsoft.com/en-us/library/ms633506%28VS.85%29.aspx
2. AccessibleObjectFromWindow(hFocusedWindow, OBJID_CLIENT, 
__uuidof(IAccessible), (void**)&accObj).
3. Focused MSAA object = accObj->get_accFocus().

- Arnstein

On 08.12.2010 16:49, Alexander Surkov wrote:
> Hi, Pete.
>
> The issue is we want to avoid to check whether caret is inside of text
> accessible that this method is called for. Perhaps this method should
> be defined on top level accessible like application accessible. It
> should work until AT want to know whether the caret is contained by
> some text accessible, i.e. if AT need to get is a direct text
> accessible having a caret and caret offset within it.
>
> Also it makes sense to consider different version of the method that
> returns caret offset additionally like:
> [propget] HRESULT accessibleWithCaret ([out, retval] IUnknown
> **accessible, [out] long* caretOffset);
>
> Thank you.
> Alex.
>
>
> On Wed, Dec 8, 2010 at 11:30 PM, Pete Brunet  wrote:
>> We could create IAText2 and add this method.  Are there any issues with this
>> proposal?  (I'd have to look though my docs to see what else we might have
>> talked about over the last year or two that could also be added for
>> IAText2.)
>>
>> Pete
>> --
>> Pete Brunet
>>
>> a11ysoft - Accessibility Architecture and Development
>> (512) 238-6967 (work), (512) 689-4155 (cell)
>> Skype: pete.brunet
>> IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
>> http://www.a11ysoft.com/about/
>> Ionosphere: WS4G
>>
>> Arnstein Skåra wrote:
>>
>> Hi!
>>
>> A brief description of the current situation:
>> 1.Place caret within a paragraph.
>> 2.Get the focused IAccessible object.
>> 3.Traverse it's children to find the IAccessible2 object containing the
>> caret.
>>
>> This approach is how you are supposed to do it, according to the
>> implementation guide.
>> It is a very time consuming operation. An example of how bad it can get is
>> www.inetword.com.
>>
>> Alexander Surkov proposed a method to deal with it:
>>
>> [propget] HRESULT accessibleWithCaret ([out, retval] IUnknown **accessible);
>>
>> Returns the accessible object containing the caret.  If the caret is in
>> an accessible in a tree of accessibles the returned accessible is the
&g

Re: [Accessibility-ia2] Recursively finding the object containing the caret is painfully slow.

[Arnstein Skåra]

  
  
Hi, Peter :)

I don't think event driven approach vs polling approach should be
the deciding factor for adding accessibleWithCaret().
And the method wasn't my proposal, it was Surkov's. He came up with
it in minutes, with little input from me really.

I humbly feel the focus should be on the IA2 spec, which I feel is
incomplete without such a method. There is no quick way starting
from an IA2 document object or focused object, to get the caret
object directly. You will encounter performance problems with deep
a11y trees, unless you listen to IA2 events. It seems counter
intuitive to have to traverse the a11y tree to find it. Don't you
agree?

By counter intuitive I mean; instead of getting the caret object
directly, you may encounter a lot of objects that can confirm they
don't have it, and find one amongst siblings saying "yep, but you'll
have to ask my children" and so on.

On 11.12.2010 02:36, Peter Korn wrote:

  
  Hi Arnstein,
  
  Reading through your use case, it seems to me you have identified
  that the IA2 API provides a way to get what you are seeking: every
  time the user types a character or moves the caret, an event is
  fired.
I'm unsure what you mean by event here. I assume IA2 event, then no.
I didn't seek a way to react to IA2 events. I want to avoid them.
Our application reacts to events externally from IA2.  Currently,
you are forced to listen to IA2 events to get the caret object
without suffering an uncertain performance hit.

  You
  state that your code would be complicated by having an event loop
  in it, and so are therefore seeking additional work by every
  mainstream application
Yes, it wouldn't make sense to have an event loop inside the IA2
client code DLL.
Every mainstream application? I thought the IA2 spec wasn't
finalized. Excuse me if I'm wrong, but I thought only a handful
applications/frameworks have implemented it so far, and are still
working on it. 
Since Surkov proposed the new method himself, I'm sure he sees the
benefit and low cost of implementing it.

 to
  provide an additional API call that is otherwise redundant with
  information already provided - 

The information is redundant yes, but the process is not. It's all
about efficiency, and shifting the responsibility. And it's also
about not to favor neither IA2 event based client nor non-event
based client, which as I mentioned I feel shouldn't be a deciding
factor.

Down the road, I'm sure others will ask about the same functionality.


Most DOM APIs, in my experience, will give you the caret
object/offset/selection object without having to traversing the
document hierarchy. Why should it not be equally easy with IA2?

in
  order to save your single AT application some additional code work
  (because each such event includes the accessible which generated
  it, your proposed accessibleWithCaret() is simply getting
  information your event handler could have cached).
  


Isn't it more efficient if it can hand me that cached caret object
directly, than my client caching it as well?
The IA2 server is already keeping track of which object contains the
caret, and must/can easily already cache it. 
It would be nice with input from Surkov about that here.

We may have more products using the same C DLL, it would be overkill
for them all to have an extra thread with an IA2 event loop, and
they would support any number of IA2 server applications. Having
several system wide IA2 event loops would be redundant.

I'm sure I won't be the only one creating an non-event based client.
If it's discouraged, the implementation guide should reflect that.

 What
  your use case doesn't make clear to me is how your product will be
  making use of the information it retrieves from this proposed new
  API call.  Would your product be polling the app in order to get
  this information? 

Yes. It would simply not traverse the a11y tree anymore. And step 4
would take constant time, hopefully (depends on the IA2 server how
they keep track of the current caret object internally). 
 What
  is the user scenario (step by step) for which X would be seeking
  the accessible with caret (and then presumably doing something
  with that caret - e.g. re-rendering the text in the neighborhood
  of the caret in some alternate fashion)?

I'm unsure what you ask. I thought I wrote what you ask about in the
previous email.
 
  
  Regards,
  
  Peter
  
  On 12/10/2010 5:25 PM, Arnstein 

Re: [Accessibility-ia2] next changes to IAccessible2

[Arnstein Skåra]

Hi, Pete.

It looks great, especially "accessibleWithCaret" :)

About "Registry API":
As it stands now, I assume a feature will be disabled if you don't 
include it in the "features" argument. Am I right?


Thanks,
Arnstein


On 07.06.2011 06:09, Pete Brunet wrote:

Hi all, Please take a look at this and provide your feedback:

https://wiki.mozilla.org/Accessibility/IA2_1.3

Thanks, Pete
--
*Pete Brunet*

a11ysoft - Accessibility Architecture and Development
(512) 238-6967 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

On 3/11/2011 11:10 PM, Alexander Surkov wrote:
Hi, Jamie. I missed Mick suggestion on the list. It's sounds 
reasonable and I agree we should try it before getting new API for 
this since the issue is mostly about events.


Thank you.
Alex.


On Sat, Mar 12, 2011 at 11:43 AM, James Teh > wrote:


Hi.

Nice work; good to get the discussion going. :)

I still don't see a need for this registry API. Why not just use
IsWinEventHookInstalled(), as Mick suggested on the IA2 list?

Thanks.

Jamie


On 12/03/2011 3:48 AM, Alexander Surkov wrote:

Hi.

I gathered ideas into one doc -
https://wiki.mozilla.org/Accessibility/IA2_1.3. Please give
feedback
here and feel free to edit the wiki.

Thank you.
Alex.


-- 
James Teh

Vice President, Developer
NV Access Inc, ABN 61773362390
Email: ja...@nvaccess.org 
Web site: http://www.nvaccess.org/





___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] next changes to IAccessible2

[Arnstein Skåra]

I use IAccessibleEditableText. But not in relation to the clipboard. 
insertText, deleteText, and replaceText are the only member functions I 
use.

Arnstein

On 28.06.2011 20:54, Pete Brunet wrote:
> AT devs, do you use IAccessibleEditableText?
>
> Is there a kind of AT that can't use the GUI for clipboard operations?
> The same question often comes up regarding IAccessibleAction, i.e. why
> have actions if the same thing can be done via the GUI.  My
> understanding is that this is for those who can't use the mouse and
> keyboard.  Do ATs for those users not have the ability to use GUI menus?
>
> Pete
>
> On 6/28/2011 2:29 AM, Malte Timmermann wrote:
>> Actually, it's also not clear to me why the clipboard stuff exists at all.
>>
>> Maybe it was introduced with JAA/ATK, because there is no "standard
>> platform mechanism" on all supported platforms?
>>
>> I don't know - how would an AT tell any application on GNOME or Mac to
>> copy/paste, w/o faking some key events?
>>
>> The clipboard API is incomplete anyway. For example, I don't have an
>> equivalent API for copy/paste on a drawing document or a bitmap editor.
>> Only for objects supporting accessible text.
>>
>> Malte.
>>
>> Carolyn MacLeod wrote, On 27.06.2011 21:06:
>>> An excellent point, Peter.
>>>
>>> In fact, I just read Malte's discussion on the same API, and something
>>> he said - "If [the user] really is interested in selecting a certain
>>> format, he can use the dialog in the application." - reminded me of our
>>> initial reaction when we were asked to implement
>>> IAccessibleEditableText::copyText, cutText, and pasteText in our
>>> StyledText control namely, "Why??".
>>>
>>> Why do AT need a separate way of doing something that every editable
>>> text control already provides by a multitude of standard platform
>>> mechanisms?
>>>
>>> I still don't have the answer. However, since we implemented
>>> IAccessibleEditableText in order to provide insert/replace/delete and
>>> allow setting of attributes, we then implemented cut/copy/paste anyway,
>>> but only because they were in the same interface.
>>>
>>> Our second question was "What are the offsets for? Why not just use the
>>> selection?". The answer to that was that since IAccessibleText::copy
>>> needed offsets because there might not be a selection, someone decided
>>> that IAccessibleEditableText cut/copy/paste needed offsets, too, for
>>> consistency. This was an unfortunate decision, because it gives these
>>> methods a very strange side effect: the server is forced to change the
>>> selection to match the offsets before doing the clipboard operation. We
>>> grudgingly implemented these methods, and hoped that no AT would ever
>>> send us any offsets other than those for the already existing selection.
>>>   :)
>>>
>>> (Epilogue: I cannot find a definition of IAccessibleText::copy anywhere,
>>> so the original reason that there are offsets for the clipboard methods
>>> has been completely lost in the mists of time).
>>>
>>> Now, since multi-selection makes the strange semantics even stranger, I
>>> am happy to revert back to our initial impression that
>>> IAccessibleEditibleText[2] doesn't need clipboard operations at all.   :)
>>>
>>> Carolyn
>>>
>>>
>>> From:   Peter Korn
>>> To: Carolyn MacLeod/Ottawa/IBM@IBMCA
>>> Cc: Alexander Surkov,
>>> accessibility-ia2-boun...@lists.linuxfoundation.org, IA2 List
>>> 
>>> Date:   27/06/2011 02:22 PM
>>> Subject:Re: [Accessibility-ia2] next changes to IAccessible2
>>>
>>>
>>> 
>>>
>>>
>>>
>>> Carolyn, gang,
>>>
>>> Before we get too deep into (re-) designing this API... Do we have a
>>> clear set of use cases?  What AT do we expect to call this/these API
>>> call(s), supporting which use cases?
>>>
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> On 6/27/2011 11:13 AM, Carolyn MacLeod wrote:
>>>
>>> Hi, all.
>>>
>>> Regarding *IAccessibleEditableText2::pasteText(startOffset, endOffset,
>>> mimeType)*:
>>>
>>> 1) If we are going to use "mime type" to specify the clipboard format,
>>> then I think we need an explicit mapping from mime type to
>>> platform-specific clipboard format so that AT and server are both
>>> speaking the same language. For example, something like:
>>> MIME type   Windows GTK/ATK
>>> text/plain  CF_TEXT (predefined)gdk_atom_intern("COMPOUND_TEXT")
>>> gdk_atom_intern("UTF8_STRING")
>>> gdk_atom_intern("STRING")
>>> text/rtfCF_RTF = RegisterClipboardFormat("Rich Text Format")
>>> gdk_atom_intern("text/rtf")
>>> gdk_atom_intern("TEXT/RTF")
>>> gdk_atom_intern("application/rtf")
>>> text/html   CF_HTML = RegisterClipboardFormat("HTML Format")
>>> gdk_atom_intern("text/html")
>>> gdk_atom_intern("TEXT/HTML")
>>>
>>>
>>>
>>>
>>> 2) Do we allow only text/* MIME types? Or do we allow all mime types?
>>> For example, is *pasteText(10, 20, "image/jpeg")* allowed? Probably
>>> should be, given that most word processors can paste

Re: [Accessibility-ia2] a11y support registry API

[Arnstein Skåra]

On 28.06.2011 13:35, Alexander Surkov wrote:
> Hi, Pete.
>
>> 1) There are some AT, like GOK, that don't care about relations, especially
>> reverse relations which are costly to compute.
>>- Is there a way for the Gecko code to not compute the reverse relations
>> until requested?
> No relations are computed until requested.
>
>> 2) There are some commonly installed tools, like anti-spyware that invokes
>> the Gecko a11y engine which degrades performance for people who don't need
>> full a11y
>>- Is the solution we are proposing the only solution?  Is this because the
>> anti-spyware code is causing a WM_GETOBJECT?
> Not necessary in Firefox case.
>
>>Is this a bug that needs to be
>> fixed in the anti-spyware code?
> I'd say so. But you cannot deny people to do what they want. One
> approach is evangelism issue. Another approach is thinking of new API
> that allows keeps engine monster on a short leash.
>
>> Are there any other well understood performance issues for which it is felt
>> this proposal is the best solution for?
> Having registry API in general is good idea because it allows server
> to know what client needs and the server doesn't need to divine what's
> will be used. For example, if screen magnifier needs to listen for
> focus event only then the server doesn't need to build whole tree, if
> this is NVDA is running that's going to build own representation of
> the page then the server would need to collect all data when tree is
> constructed.
>
Makes a lot of sense. But which features will be enabled by default? And 
would not the server already only notify the event hooks which have been 
registered, thereby providing the means to allow the server to ignore 
work which haven't been asked for? If I don't want to listen to events 
altogether, can the server take advantage of that fact once the registry 
API is in place?

> Thank you.
> Alex.
>

Out of curiosity, how do you listen to events on other platforms than 
Windows? Anything equivalent to SetWinEventHook?

Thanks,
Arnstein
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] AccessibleAction::keyBinding clarification

[Arnstein Skåra]

Hi, Alex.

On 18.07.2011 07:20, Alexander Surkov wrote:

Hi.

Wording: "The returned strings are the localized human readable key
sequences to be used to activate each action, e.g. "Ctrl+Shift+D".
Since these key sequences are to be used when the object has focus,
they are like mnemonics (access keys), and not like shortcut
(accelerator) keys."

I'm not sure I have clear understanding of the difference between
access keys and shortcut keys and appears these terms are used in
different meanings through the web. If possible can you give me a link
on terms definition or UI example?

I read it as "the object has focus" - is the key here. From MSDN: "To 
use the access key of a menu item, the menu that contains the item must 
be /active/." and "For example, a menu item called New has an access key 
N and a shortcut key CTRL+N.The menu does not have to be active for the 
shortcut key to work." Ref: 
http://msdn.microsoft.com/en-us/library/dd318482%28VS.85%29.aspx


A little more info about access keys and shortcut keys here:
http://msdn.microsoft.com/en-us/library/aa511502.aspx#accessKeys

A filemenu's access keys seem to always be made up of ALT+, but 
context menu's items can be SHIFT+ (Notepad, Wordpad etc), or 
CTRL+SHIFT+ (Firefox, Thunderbird). Actually, FF and TB accepts 
SHIFT, CTRL and CTRL+SHIFT, a tad confusing. What does FF return for 
those items when calling get_accKeyboardShortcut if all three works?
If access keys only were combinations of ALT+ things could've 
been a lot easier, but unfortunately that's impossible.


From the SDK again: "If this property returns a single character, you 
cannot assume it is an access key or a keyboard shortcut."



Wording: "There is no need to implement this method for single action
controls since that would be redundant with the standard MSAA
programming practice of getting the mnemonic from
get_accKeyboardShortcut."

In my opinion, it was an error to call it get_accKeyboardShortcut to 
begin with. It's ambigious. Shortcuts and access keys are orthogonal 
terms, and a menu item can have both.

2) Does it mean this method shouldn't ever return a value for actionIndex == 0?

3) get_accKeyboardShortcut is used to return access key and shortcut,
but if I understand right that only one key can be returned by this
method. So if we have access key (atl+letter) and shortcut key
(ctrl+key) on menu item both (I hope I use these terms rights) then
what are get_accKeyboardShortcut and keyBinding supposed to return?

Thank you.
Alex.
It all depends if an item can receive keyboard focus or not, and only 
one can be returned. From the SDK:
"If the UI element can receive keyboard focus, then you should expose 
the access key for the element. If the UI element cannot receive 
keyboard focus (such as toolbar icons), then you should display the 
shortcut key."


I see it as a problem that get_accKeyboardShortcut can return 
CTRL+SHIFT+, which looks like what most people define as a 
shortcut, actually is an access key. And in most cases, 
get_accKeyboardShortcut will return the access key, because most items 
can receive keyboard focus.


- Arnstein
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IBM bequeaths Symphony code to Apache

[Arnstein Skåra]

Hi.

I second that. We simply stopped installing JAB together with our 
products, and give support to make it work per request instead.

Here is a list of issues we've noted about the last installer made by Sun:
1. It uses a hardcoded path for "Program Files" rendering it 
incompatible with 64bit Windows.
2. The installer takes a very long time to finish, since it will search 
all your drives for the JRE. Took about 12 min on my 1 year old dev 
machine with a 80gb hdd (7200RPM)!
3. The search dialog looks buggy.
You can make your own installer though. When it comes to OOo, the most 
unfortunate design choice is that accessibility has to be enabled 
manually in the settings.

Even more interesting; IA2 can be used to replace the need to use UNO, 
for such simple tasks as finding the caret and manipulating the text in 
the document. UNO is in itself huge and complex, especially for such 
trivial tasks.

- Arnstein


On 20.07.2011 01:07, James Teh wrote:
> Hi.
>
> This is great news. It'd certainly be good to see Symphony's IA2 code
> merged into OOo, as well as further improvements to the code beyond
> that. Currently, OOo's reliance on Java Access Bridge for accessibility
> in Windows makes it extremely difficult and tedious for many users to
> set up. In addition, there are many inherent limitations and bugs in
> both JAB and OOo's support for it. For these reasons, we currently do
> not recommend OOo for most NVDA users, but instead advise them to use
> Symphony. I'm also hoping that this code will benefit from a more open
> development process.
>
> Jamie
>
> On 20/07/2011 1:57 AM, Steve Lee wrote:
>> No doubt some of you saw the news that IBM have given Symphony to Apache.
>>
>> http://www.computerworld.com/s/article/9218421/IBM_bequeaths_Symphony_code_to_Apache?taxonomyId=88
>>
>> This is of interest here as James Teh recently stated that Symphony
>> has a good IA2 implementation and Rob Weir has confirmed the IA2 work
>> is part of what will be contributed to Apache. Malte Timmerman has
>> offered to provide some details of the work.
>>
>> Ross Gardler, is a mentor of Apache OOo, and also my new business
>> partner, so we are in a good position to help OOo accessibility remain
>> a priority..
>>
>> I'm interested to hear what people think is important as we move forward.
>>
>> Steve Lee
>> OpenDirective.com
>> ___
>> Accessibility-ia2 mailing list
>> Accessibility-ia2@lists.linuxfoundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 in Eclipse

[Arnstein Skåra]

On 29.08.2011 18:11, Pete Brunet wrote:

http://www-03.ibm.com/able/news/eclipse_introduces_iaccessible2.html
--
*Pete Brunet*

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Very nice. Congratulations :)

- Arnstein
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] accessibleWithCaret - caretOffset

[Arnstein Skåra]

I agree, -1 would be most desirable.

- Arnstein

On 09.02.2012 04:38, Alexander Surkov wrote:

Hi, Pete. Looks ok except I think it should return -1 when there's no
caret. That's consistent what we do for caretOffset.
Thanks.
Alex.


On Thu, Feb 9, 2012 at 7:51 AM, Pete Brunet  wrote:

I agree that it's OK to keep the offset parameter, primarily so that out of
process AT won't suffer the penalty of process switches resulting from calls
to QI and IAText::caretOffset.  The proposal is at
https://wiki.mozilla.org/Accessibility/IA2_1.3#Caret_offset_and_accessible_containing_the_caret
One additional note is needed:  If there is no object containing a caret the
return value would be S_FALSE and the out parameters would be NULL for the
pointer to the IUnknown and 0 for the long.

Are there any additional issues?

Pete


On 9/7/11 10:02 AM, Alexander Surkov wrote:

Ok, I buy it. That suggestion was a syntax sugar, it could be useful
for those who is out of process and deprecate caretOffset (at least I
don't see a case what caretOffset can be used for having
accessibleWithCaret).

Alex.


On Wed, Sep 7, 2011 at 10:53 PM, Malte Timmermann
  wrote:

Magic value sounds strange to me, especially that it would make the OUT
param an INOUT param.

IA2 is intended to be in process, so I don't think the extra call is a
problem. The AT will make many other calls anyway, like getting text
attributes, object pos/size and other stuff.

Malte.

On 07.09.2011 05:18, Alexander Surkov wrote:

Hi, Pete. The reason is to save an extra call. From my understanding
AT wants to know the caret offset within deepest accessible having a
caret. This doesn't add complexity to server implementation (as you
said all it's needed is to query text interface and call caretOffset).
We could introduce magic value for caret offset argument to specify
that the server shouldn't calculate it.

Thank you.
Alex.


On Sat, Sep 3, 2011 at 5:39 AM, Pete Brunetwrote:

Alex, Why does accessibleWithCaret have an [out] caretOffset?  The user can
QI to IAText and use IAText::offset.  I propose not adding that redundancy
(and thus extra code for the app developers).  -Pete
--
Pete Brunet

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2


--
Pete Brunet

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] IA2 1.3 ready for review

[Arnstein Skåra]

Congratulations all! accessibleWithCaret, thank you very much. Keep up 
the great work.


Best,
Arnstein

On 21.09.2012 04:22, Pete Brunet wrote:
I finished up the IA2 1.3 work over the weekend but due to some 
changes on the LF web site am unable to post it there.  I've provided 
it at a11ysoft.com.  Please review it.  I won't get to the object 
attributes until later (to add explicit-name).


documentation: http://a11ysoft.com/ia2/docs/html
zip file: http://a11ysoft.com/ia2.zip

The one bug I see so far is that I don't have a link for the 
IAccessible2 interface on the main page.  That is at:

http://www.a11ysoft.com/ia2/docs/html/interface_i_accessible2.html

The zip file contains everything I'll eventually post on the LF site, 
among other things, changelog.txt and the merged IDL file, 
ia2_api_all.idl.


Pete
--
*Pete Brunet*

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2



___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2