That creates a rather significant problem. Rich
Rich Schwerdtfeger
From: Pete Brunet <p...@a11ysoft.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc: IA2 List <Accessibility-ia2@lists.linuxfoundation.org>,
accessibility-ia2-boun...@lists.linuxfoundation.org, Alexander
Surkov <surkov.alexan...@gmail.com>
Date: 02/04/2013 09:15 PM
Subject: Re: [Accessibility-ia2] IA2 1.3 ready for review
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
Inactive hide details for Pete Brunet ---02/04/2013
08:47:01
PM---On 2/4/13 8:16 PM, Alexander Surkov wrote: >
Hi, Pete.
Thank 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 <p...@a11ysoft.com>
To: Alexander Surkov <surkov.alexan...@gmail.com>,
Cc: IA2 List <Accessibility-ia2@lists.linuxfoundation.org>
Date: 02/04/2013 08:47 PM
Subject: Re: [Accessibility-ia2] IA2 1.3 ready for review
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
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 <p...@a11ysoft.com>
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
<p...@a11ysoft.com> 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
--
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
--
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
--
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<<inline: graycol.gif>>
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
