On 2/4/13 9:03 PM, Richard
Schwerdtfeger wrote:
Pete,
Is there a plan to update
AccProbe for the new interfaces?
Hi Rich, AccProbe should be updated but there is no resource to do
it.
Alex: I am concerned about FF
implementing this stuff in the middle of Candidate
Recommendation phase. That would set everything back and there
are already more bugs than I would like to see in FF 21 which
need to be addressed.
It would be best if this were
synched with ARIA 1.1.
Rich
Rich Schwerdtfeger
 Pete Brunet
---02/04/2013 08:47:01 PM---On 2/4/13 8:16 PM, Alexander
Surkov wrote: > Hi, Pete. Thank you for getting back on
this. Answering
From: Pete Brunet
<[email protected]>
To: Alexander Surkov
<[email protected]>,
Cc: IA2 List
<[email protected]>
Date: 02/04/2013 08:47 PM
Subject: Re: [Accessibility-ia2] IA2 1.3
ready for review
Sent by: [email protected]
On 2/4/13 8:16 PM, Alexander Surkov
wrote:
Hi, Pete. Thank you for getting back on this.
Answering inline.
1) It makes sense to allow
IAccessible2_2::attribute to take sequence
of attribute names like "margin-left;margin-right;" to get
these
attribute values for a single call.
Is this important enough to add additional development
effort for server
side implementers?
Let's leave it out of IA2 1.3. Otherwise I afraid we never
get it
done. If the feature is needed by AT then it can be
prototyped in the
browser before we put it into spec since it doesn't require
the
interface changes.
3) Any specific reason to use long for
nTargets in
relationTargetsOfType since it seems it never takes
negative values?
It's a good point, but since an unsigned long wasn't used
anywhere else it
seems like at least for the sake of consistency to leave
it as is.
I don't mind.
6) IAccessibleHypertext2::hyperlinks. Just
to make sure: we decided to
go with array instead EnumVariant? Do AT want to get all
items at once
even if the document is big and has many links?
Back on 14 Aug 2012 you agreed that the array would be
preferred in order to
keep it consistent with the array returned by
IAccessible2_2::relationTargetsOfType.
If I agreed then ok :) It seems our discussion is many years
long. I
can hardly remember where we started from. I think my point
was that
obtaining all hyperlinks can be slow. If it is an issue then
we can
address it the next round if necessary.
8) IA2_RELATION_NODE_PARENT_OF "This object
is a parent of a target
object." It's not clear as well since it doesn't answer
why
get_accParent doesn't work. Maybe you should say it's a
logical parent
and the relation is reverse to RELATION_NODE_CHILD_OF. It
is used, for
example, for flat structured trees.
I could remove it. Noone else showed interest in it other
than for symmetry
with IA2_RELATION_NODE_CHILD_OF. The comment about
get_accParent is a good
one. You asked for this new relation back on 9 Nov 09
because you added it
for ATK and wanted to enhance the symmetry between the ATK
and IA2
interfaces. Or I could just add another sentence, "This
relation is the
reciprocal of IA2_RELATION_NODE_CHILD_OF." I didn't
understand the comment
about flat structured trees but if you want to keep this
relation please
provide an additional sentence.
We shouldn't remove it. It's needed for sync with ATK. Also
this
constant was settled down in ARIA spec implementation guide
already :)
If you use "logical parent" instead "parent" (i.e. not a
parent in the
accessible tree) then it should be fine. It can sound "This
object is
a logical parent of a target object. This relation is the
reciprocal
of IA2_RELATION_NODE_CHILD_OF."
About flat trees. The accessible tree may look like:
<div role="tree">
<div role="treeitem" level="1">item</div>
<div role="treeitem" level="2">sub item</div>
</div>
in this case parent for 'item' and 'subitem' is 'tree' but
logical
parent of 'subitem' is 'item'.
I updated the comments as follows.
Please review.
/** This object is a logical child of a target object. This
relation is the reciprocal
of the IA2_RELATION_NODE_PARENT_OF relation. In some cases an
application's accessible
tree is such that an object can have a logical parent which is
not its parent in the
tree of accessibles. */
const WCHAR *const IA2_RELATION_NODE_CHILD_OF = L"nodeChildOf";
/** This object is a logical parent of a target object. This
relation is the reciprocal
of the IA2_RELATION_NODE_CHILD_OF relation. In some cases an
application's accessible
tree is such that an object can have a logical parent which is
not its parent in the
tree of accessibles. */
const WCHAR *const IA2_RELATION_NODE_PARENT_OF =
L"nodeParentOf";
Thank you.
Alex.
On Tue, Feb 5, 2013 at 8:13 AM, Pete Brunet <[email protected]> wrote:
Hi Alex, I am going to try to get some
momentum going on this again...
On 9/23/12 11:52 PM, Alexander Surkov wrote:
Hi, Pete. Here's my two cents.
1) It makes sense to allow IAccessible2_2::attribute to
take sequence
of attribute names like "margin-left;margin-right;" to get
these
attribute values for a single call.
Is this important enough to add additional development
effort for server
side implementers?
2) It'd be nice to add a reference to relation constants
for
relationTargetsOfType method description, see "[in] type
The requested
relation type."
Done.
3) Any specific reason to use long for nTargets in
relationTargetsOfType since it seems it never takes
negative values?
It's a good point, but since an unsigned long wasn't used
anywhere else it
seems like at least for the sake of consistency to leave
it as is.
4) Should we keep IAccessibleDocument restricted to HTML
documents?
After all HTML sounds like an implementation detail. The
idea it
serves to is when the loaded document shouldn't be read
from the
beginning.
I changed it to:
/** @brief Returns the most recently used anchor target
within a document.
A document's most recently targeted in-page anchor is
returned. A
typical use
of this method is to fetch the anchor target within an
HTML document.
In this
case anchor targets are those which has been defined
with the <a> tag.
5) "Document that copyText, cutText, and pasteText are
deprecated."
Can you please refresh me on it? The reason specified is
"This
function is available via the application's GUI." but it
seems it can
be applied to the whole IAccessibleEditableText interface.
This was a long discussion involving several people back
in June 2011 from
the 7th to the 29th and this is what we ended up with. It
was determined
that the three deprecated methods are clipboard operations
and there are too
many differences and ambiguities in how applications
implement their
clipboard functionality. Also copy/cut/paste methods are
not in use while
the other ones are so we can't deprecate the entire
interface. We also
talked about adding, if needed at some later date, five
new actions for cut,
copy, pasteDefault, pasteFormatted, pasteUnformatted.
6) IAccessibleHypertext2::hyperlinks. Just to make sure:
we decided to
go with array instead EnumVariant? Do AT want to get all
items at once
even if the document is big and has many links?
Back on 14 Aug 2012 you agreed that the array would be
preferred in order to
keep it consistent with the array returned by
IAccessible2_2::relationTargetsOfType.
7) IA2_RELATION_GROUPING_OBJECT_FOR: "This object is a
grouping object
for the target object." - it'd be nice to give a hint for
implementers. After a time I don't really remember what is
it about :)
Actually this got into this draft of the spec by mistake.
We agreed it was
not needed back on 1 March 12. Ditto with
IA2_RELATION_POPUP_INITIATOR_FOR. I removed them both.
8) IA2_RELATION_NODE_PARENT_OF "This object is a parent of
a target
object." It's not clear as well since it doesn't answer
why
get_accParent doesn't work. Maybe you should say it's a
logical parent
and the relation is reverse to RELATION_NODE_CHILD_OF. It
is used, for
example, for flat structured trees.
I could remove it. Noone else showed interest in it other
than for symmetry
with IA2_RELATION_NODE_CHILD_OF. The comment about
get_accParent is a good
one. You asked for this new relation back on 9 Nov 09
because you added it
for ATK and wanted to enhance the symmetry between the ATK
and IA2
interfaces. Or I could just add another sentence, "This
relation is the
reciprocal of IA2_RELATION_NODE_CHILD_OF." I didn't
understand the comment
about flat structured trees but if you want to keep this
relation please
provide an additional sentence.
9) Description for IA2_RELATION_POPUP_INITIATOR_FOR
doesn't make
things really clear for implementers too. Btw, the used
string is
"popInitiatorFor", I'm not sure if this is on demand,
should it be
"popupInitiatorFor" instead?
Removed. See #7.
10) Both IAccessibleHypertext and IAccessibleText are
marked as
deprecated (see http://a11ysoft.com/ia2/docs/html/), however
IAccessibleHypertext2 and IAccessibleText2 are inherited
from them.
What does deprecation mean here?
Thanks for noticing that Alex. Does anyone see any issues
if I remove the
inheritance?
Thank you.
Alex.
On Fri, Sep 21, 2012 at 11:22 AM, Pete Brunet <[email protected]> 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), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.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), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
--
Pete Brunet
a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G _______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
|
