Pete,

Is there a plan to update AccProbe for the new interfaces?

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



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

<<inline: graycol.gif>>

_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Reply via email to