Re: [Accessibility-ia2] HTML placeholder attribute
This makes sense to me too. Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Alexander Surkov [mailto:surkov.alexan...@gmail.com] Sent: Wednesday, September 14, 2016 4:56 PM To: James Teh <ja...@nvaccess.org> Cc: Brett Lewis <ble...@vfo-group.com>; accessibility-...@lists.linux-foundation.org Subject: Re: [Accessibility-ia2] HTML placeholder attribute Fine with me. On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org<mailto:ja...@nvaccess.org>> wrote: Visually, placeholder is certainly more like a value than a name/description. However, arguably, it is semantically different to a value in that it's more of a hint for the user as to what to enter there. The reason for the name mapping was partially because it's a nice fallback: having no label at all is probably an authoring error, so it's reasonable to fall back to placeholder. I think I originally supported the description idea, but on further reflection, I'm not so sure this isn't going to cause problems. It just occurred to me that if an author sets title or aria-describedby, that will get mapped to description, thus killing the placeholder. So, we definitely need to expose the placeholder attribute. However, once we have that (plus AT support), we then always have to compare description with placeholder "just in case", which is pretty ugly. Name is different because while no name is probably authoring error, no description certainly isn't. In short, I'd like to propose that we: 1. Expose the placeholder attribute; 2. Keep the current behaviour of falling back to placeholder for name as a last resort; 3. When 1) happens, expose explicit-name:false; 4. Don't ever fall back to placeholder for description. Jamie On 15/09/2016 2:38 AM, Alexander Surkov wrote: Jamie, do you have objections? On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>> wrote: Hi, I have always thought of the placeholder more like a value for the edit field rather than a name or description. However, I think the important thing is that we have a mechanism that allows assistive technology to “know” that the place holder is present and what the value of the placeholder is. Your suggestions accomplish that. Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Alexander Surkov [mailto:surkov.alexan...@gmail.com<mailto:surkov.alexan...@gmail.com>] Sent: Tuesday, September 13, 2016 1:52 PM To: Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>>; James Teh <ja...@nvaccess.org<mailto:ja...@nvaccess.org>> Cc: accessibility-...@lists.linux-foundation.org<mailto:accessibility-...@lists.linux-foundation.org> Subject: Re: [Accessibility-ia2] HTML placeholder attribute Hi, Brett and all. There's some discrepancy in the specs between UIA and IAccessible2 mappings. UIA column states [1] that HTML placeholder is mapped to accessible name and description, while IAccessible2 column says HTML placeholder has same mapping as aria-placeholder. aria-placeholder is exposed it in AriaProperties [2] for UIA and as object attribute for IAccessible2, the generic name computation doesn't mention aria-placeholder [3]. Leaving aside the specs, in case of IAccessible2 Firefox does similar things to UIA. Iirc we agreed [4] to expose placeholder as name/description, because it requires zero adoption efforts from AT, and since nobody claimed they need semantics of placeholder. If semantics loss is crucial for you, then I think we could fix it by exposing HTML placeholder this way: * name and description as Firefox does (fix the spec to make it clear) * expose placeholder object attribute * do not expose explicit-name='true' object attribute if placeholder was used as name aria-placeholder may be left with the current mapping. How does it sound? [1] https://w3c.github.io/aria/html-aam/html-aam.html [2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html [3] https://w3c.github.io/aria/accname-aam/accname-aam.html [4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817 On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>> wrote: Hi All: I have been looking at how the HTML placeholder attribute is supported by IA2. According to the HTML accessibility API mappings at: https://www.w3.org/TR/html-aam-1.0/ The placeholder in HTML should be handled just like the aria-placeholder. According to the core api accessibility mappings http://w3c.github.io/aria/core-aam/core-aam.html The aria-placeholder is mapped to an Ia2
[Accessibility-ia2] HTML placeholder attribute
Hi All: I have been looking at how the HTML placeholder attribute is supported by IA2. According to the HTML accessibility API mappings at: https://www.w3.org/TR/html-aam-1.0/ The placeholder in HTML should be handled just like the aria-placeholder. According to the core api accessibility mappings http://w3c.github.io/aria/core-aam/core-aam.html The aria-placeholder is mapped to an Ia2 object attribute of placeholder. So, it sounds like the HTML placeholder should be mapped to an IA2 object attribute of placeholder. Currently Firefox seems to support the placeholder as the name of the field if there is no other name provided by the page author (from https://bugzilla.mozilla.org/show_bug.cgi?id=545817. This seems to contradict the description of aria-placeholder from the WAI-ARIA) 1.1 spec at http://rawgit.com/w3c/aria/master/aria/aria.html#aria-placeholder Says: “[ARIA 1.1] Defines a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format. Authors should not use aria-placeholder instead of a label as their purposes are different: The label indicates what kind of information is expected. The placeholder text is a hint about the expected value. See related aria-labelledby and aria-label. Authors should present this hint to the user by displaying the hint text at any time the control's value is the empty string. This includes cases where the control first receives focus, and when users remove a previously-entered value. NOTE As is the case with the related HTML placeholder attribute, use of placeholder text as a replacement for a displayed label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control's label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.” I am suggesting that we all agree to present the HTML placeholder just like the aria-placeholder using the IA2 object attribute of placeholder? This provides the most flexibility for screenreaders to present the placeholder information anyway they see fit. Using the placeholder as the name is not as flexible as the screenreader cannot distinguish between the placeholder and the label in this case. What does everyone think? Thanks, Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships
Hi Rich, I think you nicely articulated our concerns w/r/t the concatenation of error/description information. In particular, it is really hard to separate out error information from a description if the user wants it for some reason while concatenating the information is not too difficult. Let’s not concatenate. Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com] Sent: Tuesday, September 06, 2016 1:36 PM To: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <ble...@vfo-group.com>; jdi...@igalia.com Cc: accessibility-...@lists.linux-foundation.org Subject: Agreement on concatenation of aria-describedby and aria-errormessage relationships The ARIA working group is against concatenating the description and relationship strings. I will try to summarize: Specifically, concatenation by browsers could: 1. Defeat the purposes of aria-errormessage. The aria-errormessage relationship is designed to ensure assistive technology users are as aware of error messages as other users and to enable them to distinguish between error messages and field descriptions. The constraints of ARIA 1.0, and every other accessibility standard and API that preceded it, have forced developers to blend error messages and field descriptions. This blending has long inhibited both the perception and understanding of error messages, which are critical to effective operation of many user interfaces. 2. increase cognitive load for users when errors are present. Especially for screen reader users, we already have severe challenges with excess verbosity that forces the user to expend energy sorting out the most important aspects of screen reader feedback. Concatenating potentially very disparate content in this manner would aggravate the verbosity problem. 3. Reduce assistive technology flexibility. Part of the power of ARIA is that it gives assistive technologies the ability to present content in the manner best suited for their target audiences. When browsers eliminate semantically relevant distinctions, this type of flexibility is diminished. If this concatenation were performed, it would essentially eliminate the semantic distinctions. If an assistive technology developer wanted to present the field description separate from the error messages, the developer would be forced to ignore the browser-computed description when error messages are present and reconstruct the description computation within the assistive technology. 4. Lead either browsers or authors to devise their own string-based tokenization capability. Because aria-errormessage is a separate relationship, there will be designers and developers who want to ensure there is a method for parsing the string into its separate components. This would reduce the robustness of the solution and create both inconsistencies and complexity, especially when localizing implementations. 5. Introduce serious problems with globalization: namely there is no clean way to concatenate the 2 strings in a way that will make sense. We cannot put in a space as some languages don't have them (Mandarin). Concatenating them together does not read properly. The aria-errormessage relationship is intended to address long-standing accessibility issues faced by both developers and end users. The energy required to find effective remedies to those issues will definitely pay dividends for assistive technology users. Would each of you weigh in. Again this is now holding up 3 working groups going on 3 weeks now. Do we agree on not concatenating the two strings? Rich Rich Schwerdtfeger ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] Form role mapping
Hi Rich, I think this is fine. This seems like a reasonable way to move forward. Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com] Sent: Tuesday, September 06, 2016 12:55 PM To: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <ble...@vfo-group.com>; jdi...@igalia.com Cc: accessibility-...@lists.linux-foundation.org Subject: Form role mapping Jamie, Alex, Brett, We need to reach consensus on the element and role="form" mapping. Can we agree on the following? : 1. that the IA2 IDL supports IA2_ROLE_LANDMARK and IA2_ROLE_FORM (so that old versions of FF and other applications using the form role can still work with ATs) 2. For Firefox updates here on out the element and role="form" map to IA2_ROLE_LANDMARK and xml-roles="form" This way AT vendors can check if something is a landmark to determine if something is a landmark and then expose xml-roles="form" Eventually, it would be better to not have to make an exception for the Form role when all the other landmark roles are represented as IA2_ROLE_LANDMARK with xml-roles="form" This and the other discussion items of the last 2 weeks are holding up 3 working groups - ARIA, HTML, and SVG. Rich Schwerdtfeger ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] Reverse relationships
Hi, Is that documented somewhere? I read through the information on error and I don’t see anything about AT skipping error messages if encountering them while reading through the virtual buffer. Have I misunderstood something? Thanks, Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Alexander Surkov [mailto:surkov.alexan...@gmail.com] Sent: Wednesday, September 07, 2016 8:02 AM To: Brett Lewis <ble...@vfo-group.com> Cc: Richard Schwerdtfeger <sch...@us.ibm.com>; ja...@nvaccess.org; jdi...@igalia.com; accessibility-...@lists.linux-foundation.org Subject: Re: Reverse relationships Hi, Brett. Can you please elaborate your use case? My understanding is AT skips error/details, if the user encounters them, but announce them, when the user navigates to an element related with error/details. Why would AT need to find a related element by error/details? Thanks. Alex. On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>> wrote: Hi Rich, I think we do need the reverse relationships. Web authors can place the error/details anywhere on the page and there doesn’t seem to be any simple way for the user to determine what element the error message or details applies to without such a reverse relation. Brett Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com<mailto:sch...@us.ibm.com>] Sent: Tuesday, September 06, 2016 12:57 PM To: ja...@nvaccess.org<mailto:ja...@nvaccess.org>; surkov.alexan...@gmail.com<mailto:surkov.alexan...@gmail.com>; Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>>; jdi...@igalia.com<mailto:jdi...@igalia.com> Cc: accessibility-...@lists.linux-foundation.org<mailto:accessibility-...@lists.linux-foundation.org> Subject: Reverse relationships We need agreement: Should the error message and details relationships have reverse mappings? Rich Rich Schwerdtfeger ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] Plea for a new function
Hi, I could live with option 4, it would just make my life easier to have the function. I am OK either way on this. Brett -Original Message- From: accessibility-ia2-boun...@lists.linuxfoundation.org [mailto:accessibility-ia2-boun...@lists.linuxfoundation.org] On Behalf Of James Teh Sent: Wednesday, February 06, 2013 2:22 PM To: accessibility-ia2@lists.linuxfoundation.org Subject: Re: [Accessibility-ia2] Plea for a new function Brett, can you comment as to whether (and why) option 4 isn't feasible? Thanks, Jamie On 7/02/2013 3:43 AM, Pete Brunet wrote: Since there is a need for this and the solution is easy to implement it seems worth adding. Here is a draft for review. HRESULT IAccessible2_2::offsetInParentText ( [out] long* offset ); Return text offset in parent. Determine the parent accessible which implements IAccessibleText and return the offset in that object which corresponds to the beginning of the text associated with this accessible. If this accessible implements IAccessibleText, 0 will be returned. Returns: S_OK is returned if this accessible or a parent accessible implements IAccessibleText. S_FALSE is returned if no nodes implementing IAccessibleText are found; [out] value is 0. On 2/5/13 10:58 PM, Alexander Surkov wrote: Hi, Pete. Options were discussed: 1) make text leaf accessible implement IAccessibleText (I didn't like it, seehttp://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012- November/001731.html) 2) make text leaf accessible implement IAccessibleHyperLink (I didn't like it, seehttp://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012- November/001731.html) 3) add a new method DescendantOffset(IAccessible* acc, long* offset) like Brett suggested (see http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-November/001729.html). I don't mind. It's easy to implement. 4) do nothing (Jamie mentioned that pure IAccessibleText/HyperLink/HyperText should work also as alternative approach to the approach described by Brett, but here we probably run into restrictions of proprietary softwares). Thank you. Alex. On Wed, Feb 6, 2013 at 2:31 AM, Pete Brunetp...@a11ysoft.com wrote: To all, Please review the thread Brett started at: http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2012-No vember/001729.html to see if any further progress can be made on this issue. On 2/5/13 8:46 AM, Brett Lewis wrote: Hi, I wish we could get it in but it definitely sounded like there was no consensus on the issue, so let's let it go. Thanks, Brett From: Pete Brunet [mailto:p...@a11ysoft.com] Sent: Monday, February 04, 2013 7:02 PM To: Brett Lewis Cc: IAccessible2 mailing list Subject: Re: [Accessibility-ia2] Plea for a new function Hi Brett, Is this still an issue for you? We're very near the end of discussions for IA2 1.3 and wanted to see if more discussion is needed on this issue. -Pete On 11/26/12 7:03 PM, James Teh wrote: On 27/11/2012 8:02 AM, Brett Lewis wrote: I am getting the Iaccessible tree. I then find that I want the text attributes for one of my leaf nodes and find that I have to go back up the Iaccessible tree to find the nearest Iaccessible node that allow QI to IAccessibleText and then trying to figure out how to map the result back down to my Iaccessible leaf node. If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e. pretend they don't exist. That way, you're only dealing with nodes that support IAccessibleText. However, there may well be a good reason you can't do this. Jamie -- 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 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
Re: [Accessibility-ia2] Plea for a new function
Hi, I wish we could get it in but it definitely sounded like there was no consensus on the issue, so let's let it go. Thanks, Brett From: Pete Brunet [mailto:p...@a11ysoft.com] Sent: Monday, February 04, 2013 7:02 PM To: Brett Lewis Cc: IAccessible2 mailing list Subject: Re: [Accessibility-ia2] Plea for a new function Hi Brett, Is this still an issue for you? We're very near the end of discussions for IA2 1.3 and wanted to see if more discussion is needed on this issue. -Pete On 11/26/12 7:03 PM, James Teh wrote: On 27/11/2012 8:02 AM, Brett Lewis wrote: I am getting the Iaccessible tree. I then find that I want the text attributes for one of my leaf nodes and find that I have to go back up the Iaccessible tree to find the nearest Iaccessible node that allow QI to IAccessibleText and then trying to figure out how to map the result back down to my Iaccessible leaf node. If you can, for Mozilla, it's best to ignore leaf nodes altogether; i.e. pretend they don't exist. That way, you're only dealing with nodes that support IAccessibleText. However, there may well be a good reason you can't do this. Jamie -- Pete Brunet a11ysoft - Accessibility Architecture and Development (512) 467-4706 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), ptbru...@live.commailto: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
Re: [Accessibility-ia2] Plea for a new function
Hi, I am getting the Iaccessible tree. I then find that I want the text attributes for one of my leaf nodes and find that I have to go back up the Iaccessible tree to find the nearest Iaccessible node that allow QI to IAccessibleText and then trying to figure out how to map the result back down to my Iaccessible leaf node. You can see a case by just adding a sup tag to a web page: 2sup32/sup And view it in firefox, there is a paragraph Iaccessible with two text children. The two text children correspond to 2 and 32. Each of these leaf nodes does not support the IAccessibleText but the paragraph parent does. This is a pretty trivial case but illustrates what I am talking about. Brett -Original Message- From: accessibility-ia2-boun...@lists.linuxfoundation.org [mailto:accessibility-ia2-boun...@lists.linuxfoundation.org] On Behalf Of James Teh Sent: Monday, November 26, 2012 1:28 PM To: IAccessible2 mailing list Subject: Re: [Accessibility-ia2] Plea for a new function Hi Brett, Out of curiosity, how are you getting the text leaf nodes in the first place? Ideally, this should all be done using the IAccessibleText interface on the parent. I'm keenly aware that there are cases where this isn't practical, but I thought I'd ask nevertheless. Jamie On 27/11/2012 5:14 AM, Brett Lewis wrote: Hi, I don't have a strong preference for a given solution. If everyone prefers implementing IAccessibleHyperLink on the leaf nodes, that is fine. Alex said it would be hard to implement IAccessibleText on all the text leaf nodes so Jamie's IAccessibleHyperLink solution or A pair of new functions to retrieve child at offset and offset of descendant seem like the only options. As I said, the two cases of concern for me are identifying the text attributes for a given text leaf node that doesn't support IaccessibleText and to obtain the rectangle enclosing specific characters in a text leaf node. Thanks, Brett -Original Message- From: accessibility-ia2-boun...@lists.linuxfoundation.org [mailto:accessibility-ia2-boun...@lists.linuxfoundation.org] On Behalf Of Alexander Surkov Sent: Tuesday, November 20, 2012 8:30 PM To: James Teh Cc: IAccessible2 mailing list Subject: Re: [Accessibility-ia2] Plea for a new function Hi, Jamie. I think Brett meant accessible object for text node (aka text leaf accessible). In general accessible objects for text nodes aren't really necessary since they dupe info that is provided by IAccessibleText on the container. So there's no need for them in IA2 world, they are rather MSAA heritage. However I has been told that having accessible objects for text nodes is still useful for AT (I'm not really aware of details) and that's why we keep them in Firefox btw. This is a reason why I don't want text nodes to implement IAccessibleText (besides it won't be trivial to implement). IAccessibleHyperlink idea might be ok, it's not backward compatible though and makes nsIAccessibleHyperText nearly useless since it dupes IAccessbile/IAccessbile2 methods. Having a new method that returns an offset for a child (and child by offset?) might be ok. Thank you. Alex. On Wed, Nov 21, 2012 at 9:11 AM, James Teh ja...@nvaccess.org wrote: Hi. There are two problems here: 1. It's unclear what is considered the text of a descendant node which doesn't support IAccessibleText. It could be accName, accValue, accDescription, etc. or some combination thereof. 2. This assumes that a descendant node's text actually is contained in the ancestor IAccessibleText object, which might not be the case. Of course, I guess the method could just fail if this weren't the case. Also, why not just implement IAccessibleText on the descendant nodes? In any case, I don't think a new method is required for this. You can implement IAccessibleHyperlink on the descendant nodes. The startIndex and endIndex properties of IAccessibleHyperlink should give you what you need. Jamie On 21/11/2012 9:30 AM, Brett Lewis wrote: All: I have recently run into a situation for which there presently doesn't appear to be a good solution. 1. The problem. I wished to obtain the attributes for the text at a particular offset. This is straightforward using IAccessibleText and just asking for the attributes at the offset of interest. The difficulty is that the node whose text attributes I wanted didn't support IAccessibleText. One of its ancestors did and this ancestor did contain information about the attributes I needed. The question then became, how can I find out where in a given IAccessibleText string does a descendants node text begin. I haven't found an easy way to answer this question. 2. Proposed solution: Add a new function that returns the offset in the current IAccessibleText text string for a given IAccessible for a descendant. So something like: DescendantOffset(IAccessible* acc,VARIANT varChild, long
[Accessibility-ia2] Plea for a new function
All: I have recently run into a situation for which there presently doesn't appear to be a good solution. 1. The problem. I wished to obtain the attributes for the text at a particular offset. This is straightforward using IAccessibleText and just asking for the attributes at the offset of interest. The difficulty is that the node whose text attributes I wanted didn't support IAccessibleText. One of its ancestors did and this ancestor did contain information about the attributes I needed. The question then became, how can I find out where in a given IAccessibleText string does a descendants node text begin. I haven't found an easy way to answer this question. 2. Proposed solution: Add a new function that returns the offset in the current IAccessibleText text string for a given IAccessible for a descendant. So something like: DescendantOffset(IAccessible* acc,VARIANT varChild, long* offset) I have no strong preference for exactly how this should be handled, just the need for such a function. I know the 1.3 version of the IAccessible2 specification is nearly ready, but I would like to see if this new function could be included. In addition to the attributes for text at a given offset, I have also seen a case where we needed the rectangle for particular characters. Again, in this instance, we needed to locate the nearest ancestor supporting IAccessibleText and try to determine the offset in this ancestor of the node of interest. What does everyone think about such an addition? Any feedback would be much appreciated. Thanks, Brett Lewis ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] HTML table summary mapping to IA2
Hi, What prompted this thread for me is my trying to obtain caption and summary via the IAccessibleTable interface. By convention using name and description is fine but doesn't really seem to correctly implement IAccessibleTable and is only somewhat intuitive. I like the idea of having the get_summary and get_Caption return a variant with either the text or the IAccessible. Brett -Original Message- From: Alexander Surkov [mailto:surkov.alexan...@gmail.com] Sent: Monday, August 08, 2011 8:58 PM To: James Teh Cc: IAccessible2 mailing list; Brett Lewis Subject: Re: [Accessibility-ia2] HTML table summary mapping to IA2 Hi, Jamie. It appears AT want to get summary and caption (not a name or description since they can be different). Brett, do you have scenarios to share? Thank you. Alex. On Tue, Aug 9, 2011 at 12:42 PM, James Teh ja...@nvaccess.org wrote: Hi Alex, Why are accName/accDescription insufficient? Thanks, Jamie On 9/08/2011 1:36 PM, Alexander Surkov wrote: Hi. IATable2 provides caption and summary properties that return accessible objects. HTML table summary is provided by @summary attribute so there's no accessible object that's created from DOM element. This can be workarounded by artificial accessible object creation that is attached or not attached to the tree but this complicates implementation and I would try to avoid it. Can we extend the IAccessibleTable2 by summaryText and captionText attributes or introduce summary and caption object attributes on table accessible if interface change is not desired for this? Thank you. Alexander. ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 -- 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
