from:"Richard Schwerdtfeger"

>*AT and browsers support those roles, if Firefox Nightly starts to expose IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it >breaks all existing screen reader versions. In case of commercial screen readers this is painful for the users, since they have to buy a >new version of their screen reader.
Good point. I will switch back to IA2_ROLE_FORM for forms. We still need IA2_ROLE_LANDMARK for the other land marks.
Rich
Rich Schwerdtfeger
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: James Teh <ja...@nvaccess.org>Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Brett Lewis <ble...@freedomscientific.com>, Joanmarie Diggs <jdi...@igalia.com>, IAccessible2 mailing list <accessibility-...@lists.linux-foundation.org>Subject: Re: Form role mappingDate: Wed, Sep 7, 2016 10:58 AM
There's a point in discussing, the spec can be changed, if there's solid ground for that.My concerns are: * Both IA2 and ATK have a better role match for both role='form' and HTML form, which is ATK_ROLE_FORM and IA2_ROLE_FORM. Thus if there's no strong reason why we have to use a 'weaker' role, then I'd say we should go with the match. * AT and browsers support those roles, if Firefox Nightly starts to expose IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it breaks all existing screen reader versions. In case of commercial screen readers this is painful for the users, since they have to buy a new version of their screen reader. * I'm not certain if changing IA2_ROLE_FORM to IA2_ROLE_LANDMARK adds any benefits for screen readers. I'd be curious to hear about them.
On Tue, Sep 6, 2016 at 7:15 PM, James Teh <ja...@nvaccess.org> wrote:

Hi Rich,
I've already stated my view on this:
I understand the reason for the use of the landmark role for role="form". However, I disagree with the HTML form element being mapped to the landmark role because semantics are lost. The fact that something is a form has more semantic value than just being a landmark. Still, if the spec already requires this, I guess we have little choice but to comply at this stage.

At the end of the day, I'm not sure why this is still an open question, since it seems that the spec groups have already made a decision on this:
The HTML the form element now uses the ARIA mappings for the form role. See "Use WAI-ARIA mapping” under the form element. This is for all platforms.In other words, we can't comply with the spec unless we do as you suggest, so there is no other choice. There is no point in discussing this further.Thanks,Jamie
On 7/09/2016 5:54 AM, Richard Schwerdtfeger wrote:
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
--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org

___
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

Yes it may provide alternative content as well.
Rich Schwerdtfeger
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: James Teh <ja...@nvaccess.org>Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list <accessibility-...@lists.linux-foundation.org>, Brett Lewis <ble...@freedomscientific.com>, Joanmarie Diggs <jdi...@igalia.com>, Dominic Mazzoni <dmazz...@google.com>Subject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationshipsDate: Wed, Sep 7, 2016 11:15 AM
Shouldn't it be same speed as walking the virtual buffer? I assume aria-details may contain complex content, for example Pythagorean Theorem from [1], that may be not suitable for stringification in general.[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
On Tue, Sep 6, 2016 at 11:31 PM, James Teh <ja...@nvaccess.org> wrote:

That doesn't solve the need to walk the tree to gather the error message, which is the real problem.
On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:
I think Dominic's suggestion on an interface tester with bit flags works well.
Rich
Rich Schwerdtfeger
- Original message -----From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: Accessibility-ia2@lists.linux-foundation.orgSubject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationshipsDate: Tue, Sep 6, 2016 7:19 PM
Fair enough. Thanks for the clear reasoning.
My one remaining concern is performance, but we will clearly need to find an alternative technical solution to this problem. In short, not concatenating means that for every focus event, we need to check for the invalid state plus an errormessage relation and then, if one is found, walk the tree for the target to gather the message. The latter in particular could be unacceptably slow.

On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:
The ARIA working group is against concatenating the description and relationship strings. I will try to summarize:
Specifically, concatenation by browsers could:
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.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.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.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.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

--James TehEx

Re: [Accessibility-ia2] Reverse relationships

Hi Alex,
 
Correct, aria-details requires no special role. However, the use case is for the digital publishing industry. They want to be able to take a piece of content and go to the alternative content that provides detailed information which could be alternative content as we discussed previously. The user may or may not wish to go back to the content the details is being provided for.
 
The need for a reverse relationship for the error message is more critical.
 
So, do we agree on a reverse relationship for error message and not details?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: Brett Lewis <ble...@vfo-group.com>Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org" <ja...@nvaccess.org>, "jdi...@igalia.com" <jdi...@igalia.com>, "accessibility-...@lists.linux-foundation.org" <accessibility-...@lists.linux-foundation.org>Subject: Re: Reverse relationshipsDate: Wed, Sep 7, 2016 10:34 AM 
You're right. An element referred by aria-errormessage can be an alert of live region and thus should be announced by a screen reader, when it pops up. In this case, it seems the screen reader may need to find a context element, and if this is true, then the reverse relation is needed. 
aria-details are different, since they are more like labels and descriptions, and I guess thus they should be skipped when navigating the virtual buffer. That suggests that aria-details either needs a role (or xml-roles object attribute) or a reverse relation.
 
On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis <ble...@vfo-group.com> wrote:

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
blewis@vfo-group.com
www.vfo-group.com
 
 
From: Alexander Surkov [mailto:surkov.alexander@gmail.com]Sent: Wednesday, September 07, 2016 8:02 AMTo: Brett Lewis <ble...@vfo-group.com>Cc: Richard Schwerdtfeger <sch...@us.ibm.com>; ja...@nvaccess.org; jdi...@igalia.com; Accessibility-ia2@lists.linux-foundation.orgSubject: 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> 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
blewis@vfo-group.com
www.vfo-group.com
 
 
From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com]Sent: Tuesday, September 06, 2016 12:57 PMTo: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <ble...@vfo-group.com>; jdi...@igalia.comCc:  Accessibility-ia2@lists.linux-foundation.orgSubject: 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] Reverse relationships

To be clear, we would not document them in the mapping specification if they are not implemented.
 
When I say add them later I am referring to the mapping spec. and browsers. However, doing that has ramifications for AT vendors.
Rich Schwerdtfeger
 
 
- Original message -From: James Teh <ja...@nvaccess.org>To: Dominic Mazzoni <dmazz...@google.com>, Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-...@lists.linux-foundation.orgSubject: Re: [Accessibility-ia2] Reverse relationshipsDate: Wed, Sep 7, 2016 12:26 AM 
That's fair. The only problem is that if they're documented in the mapping spec, browsers are technically non-compliant if they don't implement. 

On 7/09/2016 2:58 PM, Dominic Mazzoni wrote:
Is there any reason we shouldn't *define* the reverse relationships now? Browsers can choose not to implement them now for performance reasons, and AT can choose to ignore them.
  

On Tue, Sep 6, 2016 at 7:16 PM Richard Schwerdtfeger <sch...@us.ibm.com> wrote:
Jamie,
 
 
Well you can add reverse relationships later if it becomes an issue. The only problem with adding it later is you will also then need to test if that reverse relation ship exists and what to do with older browsers that won't have the relationship.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: accessibility-...@lists.linux-foundation.orgSubject: Re: Reverse relationshipsDate: Tue, Sep 6, 2016 7:34 PM 
As I noted previously:
 
 
5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept that this use case may one day arise. 

 Right now, we have no plans to implement a "jump to field for error message" command or similar. Perhaps we will one day, but it seems flawed to sacrifice performance for something no one is using yet.Jamie 
On 7/09/2016 5:56 AM, Richard Schwerdtfeger wrote:
We need agreement:
 
Should the error message and details relationships have reverse mappings?
 
Rich
 
Rich Schwerdtfeger 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org
 ___Accessibility-ia2 mailing listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org
 

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

Re: [Accessibility-ia2] Form role mapping

Jamie,
I thought I addressed this before: The HTML AAM points to the ARIA core mapping specification now. They will implement what we have. One of the reasons ARIA in HTML is being held up is for us. The plan is for the host language platforms to use as much of the ARIA spec. as possible to avoid duplication of effort. Here is the link to the spec.: http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
If you go down to the form element mapping you will see it says "Use WAI-ARIA mapping"
So, for backward compatibility you test for both the IA2 form role and all ARIA 1.1 and HTML 5.2 level browsers support the IA2_ROLE_LANDMARK for all landmarks and use the xml-roles object attribute to get the landmark type, ... in this case "form".
Rich
Rich Schwerdtfeger
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: accessibility-...@lists.linux-foundation.orgSubject: Re: Form role mappingDate: Tue, Sep 6, 2016 6:15 PM
Hi Rich,
I've already stated my view on this:
I understand the reason for the use of the landmark role for role="form". However, I disagree with the HTML form element being mapped to the landmark role because semantics are lost. The fact that something is a form has more semantic value than just being a landmark. Still, if the spec already requires this, I guess we have little choice but to comply at this stage.

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org

___
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

I think Dominic's suggestion on an interface tester with bit flags works well.
Rich
Rich Schwerdtfeger
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: accessibility-...@lists.linux-foundation.orgSubject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationshipsDate: Tue, Sep 6, 2016 7:19 PM
Fair enough. Thanks for the clear reasoning.
My one remaining concern is performance, but we will clearly need to find an alternative technical solution to this problem. In short, not concatenating means that for every focus event, we need to check for the invalid state plus an errormessage relation and then, if one is found, walk the tree for the target to gather the message. The latter in particular could be unacceptably slow.

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org

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

Re: [Accessibility-ia2] Reverse relationships

Jamie,
 
 
Well you can add reverse relationships later if it becomes an issue. The only problem with adding it later is you will also then need to test if that reverse relation ship exists and what to do with older browsers that won't have the relationship.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: accessibility-...@lists.linux-foundation.orgSubject: Re: Reverse relationshipsDate: Tue, Sep 6, 2016 7:34 PM 
As I noted previously:
 
 
5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept that this use case may one day arise. 

 Right now, we have no plans to implement a "jump to field for error message" command or similar. Perhaps we will one day, but it seems flawed to sacrifice performance for something no one is using yet.Jamie 
On 7/09/2016 5:56 AM, Richard Schwerdtfeger wrote:
We need agreement:
 
Should the error message and details relationships have reverse mappings?
 
Rich
 
Rich Schwerdtfeger 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org
 

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

Re: [Accessibility-ia2] Bitmask for rare accessibility attributes

That makes sense to me. 
Rich Schwerdtfeger
 
 
- Original message -From: Dominic Mazzoni via Accessibility-ia2 Sent by: accessibility-ia2-boun...@lists.linuxfoundation.orgTo: accessibility-...@lists.linux-foundation.orgCc:Subject: [Accessibility-ia2] Bitmask for rare accessibility attributesDate: Tue, Sep 6, 2016 5:42 PM 
One of the objections Jamie brought up to making aria-errormessage an additional interface is that it increases the number of interfaces AT needs to call on every single accessible. I've also thought about this same issue, as the number of nodes in an average web page continues to grow along with the number of interfaces in IA2.
 
What would folks think of adding some sort of bitmask to allow AT to quickly test for the presence of lots of properties at the same time? Something like:
 
HRESULT propertyBitmask([out, retval] IA2PropertyBitmask *bitmask)
 
enum   IA2PropertyBitmask { 
  IA2_HAS_NAME = 0x01,
  IA2_HAS_DESCRIPTION = 0x02,
  IA2_HAS_ERRORMESSAGE = 0x04,  ...

}
 
One could imagine variants of this, for example AT could fill in the bitmask with properties it's interested in, and the browser would only have to compute those.
 
- Dominic
 
___Accessibility-ia2 mailing listAccessibility-ia2@lists.linuxfoundation.orghttps://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] 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:
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.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.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.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.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

[Accessibility-ia2] 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] IA2 Role Landmark

2016-08-29 Thread Richard Schwerdtfeger

Jamie, Alex,
There is far too much resistance to concatenating the description with the error message. It will never carry with the working group. I am sorry. Right now we are holding up ARIA in HTML in ARIA.
Can we agree:
1. For the Firefox mapping of the form element, and ARIA 1.1 form role, IA2_ROLE_LANDMARK is exposed with xml-roles="form"
2. IA2_ROLE_FORM will not be deprecated for backward compatibility
3. We expose IA2_RELATION_DETAILS and IA2_RELATIONSHIP_ERROR_MESSAGE - It that you both agreed on separate relationships and these were the names Alex suggested.
Beyond that I need an answer on the reverse relationship that Joanie requested. It you can't agree I will leave them out of the IA2 spec. I do believe that Joanie might implement the reverse relationship for her platform but I have not asked. Joanie?
Alex, would you please send me an updated IDL for IA2?
Regards,
Rich
Rich Schwerdtfeger
- Original message -From: Rich Schwerdtfeger Sent by: accessibility-ia2-boun...@lists.linuxfoundation.orgTo: Alexander Surkov Cc: Joseph Scheuhammer , Stefan Schnabel , Steven Faulkner , IA2 List , ARIA Working Group Subject: Re: [Accessibility-ia2] IA2 Role LandmarkDate: Sun, Aug 28, 2016 7:20 AM I would also argue that, today, navigating a web page should be by regional landmarks first. They create a table of contents for the page and we advise all IBM developers to ensure all content is contained within a landmark. This way content is not orphaned. To that end a form should be treated as a landmark and should appear in the table of contents used for navigation by ATVs.
We are way beyond one off landmarks (just a form) and starting with heading navigation today.
Rich
Rich Schwerdtfeger

On Aug 25, 2016, at 10:51 AM, Rich Schwerdtfeger wrote:

Well it is used by the most pervasive apps on the planet using IA2 already. Chrome, FF, and eclipse-based apps.Sent from my iPhone
On Aug 25, 2016, at 10:45 AM, Alexander Surkov wrote:
I definitely agree that IA2 needs a flexible mechanism to expose roles, I'm just not sure it should be xml-roles object attribute.
On Thu, Aug 25, 2016 at 11:15 AM, Rich Schwerdtfeger wrote:

Alex, those object attributes should have been included in IA2 a long time ago. I in no way see these as a hack. Eclipse uses them too.Sent from my iPhone
On Aug 25, 2016, at 9:49 AM, Alexander Surkov wrote:
This is true, however xml-roles is not standard attribute in IA2, it's rather a browser specific hack to expose the semantics, that otherwise was missed. So if the API provides a way to expose an element semantics more fully, then I'd say it's the way to go.Having said that, I'm also concerned about backward-compatibility issue.
On Thu, Aug 25, 2016 at 10:37 AM, Joanmarie Diggs wrote:

Sorry for being spammy, but with respect to the loss of semantics: Thetype of landmark is still being exposed via object attribute. So I'llstill know if an ATK_ROLE_LANDMARK is a form, or navigation, or
On 08/25/2016 10:24 AM, Joanmarie Diggs wrote:> Hi Alex, all.>> I don't recall saying "kill the form role" in ATK. We have no plans to> deprecate ATK_ROLE_FORM. Instead, I believe I said something along the> lines of the following:>> Q: Should HTML's form element be treated like a landmark for the> purposes of navigation?>> If Yes: Map it to ATK_ROLE_LANDMARK> If No: Continue mapping it to ATK_ROLE_FORM>> --joanie>> On 08/25/2016 10:08 AM, Alexander Surkov wrote:>> I don't think Jamie argues that FORM is not a landmark. The point is>> that FORM is a form and also a landmark. IA2 provides a special FORM>> role, which is used both for ARIA and HTML currently, and adopted by>> browsers and screen readers. If we use weaker role for forms, then we loose semantics as Jamie>> pointed out, and we make a not backward compatible change. All JAWS and>> other commercial screen reader users will have to buy a new screen>> reader version. ATK gained this role, because it doesn't have a mechanism to fetch all>> landmarks on a page other than query it by role. And thus they are ok to>> sacrifice ATK form role for performance reasons I think. Note, ATK world>> doesn't have so acute problem of backward compatibility as IA2 has, so>> they have a larger room for changes. IA2 landmark role is a ATK toll to>> keep IA2 compatible with, this is a primary reason, if I do understand>> that right. However I'm not confident too that we should take ATK path>> and kill a form role too. On Thu, Aug 25, 2016 at 3:34 AM, Schnabel, Stefan>> > wrote: Hi James, __ __ currently Jaws treats forms like

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping [Issue-1044]

2016-08-25 Thread Richard Schwerdtfeger

Alex, Jamie,
We discussed this concatenation and Microsoft (Cynthia Shelly) and also Matt King and the more we look at concatenation the worse it looks. This impact more than IA2. It would effect the UIA Mapping for Edge and it creates problems for internationalization whereby we can't put a space in between for all languages.
Matt King (Facebook), will respond with another list of problems as will Cynthia. The whole point in the first place was to separate them out in all languages. Another reason is the size of the string that could result.
Rich
Rich Schwerdtfeger
- Original message -From: Richard Schwerdtfeger/Austin/IBMTo: surkov.alexan...@gmail.comCc: accessibility-ia2@lists.linuxfoundation.org, ja...@nvaccess.org, jdi...@igalia.comSubject: Re: aria-details and aria-errormessage mappingDate: Tue, Aug 23, 2016 3:21 PM
Alex,
You can't expose aria-details as an action it is a relationship to the extended detail. Who said you were to implement an action? It is not a longdesc.
It could point to a details/summary which shows and hides the content itself. The target might be hidden by book readers until the user turns on a facility to show the extended description.
Here is an example:

Jamie, are we going with a new relation for aria-details or can you think of another mechanism to expose it? Thanks.Alexander.
On Sun, Aug 21, 2016 at 8:46 PM, James Teh <ja...@nvaccess.org> wrote:

Hi Rich,
Thanks for the clear explanations; I really do appreciate it. Part of the confusion here is that I've unintentionally conflated aria-details with aria-errormessage.
Regarding aria-details, what you say absolutely makes sense. Given that, reading the details automatically as a simple message doesn't make sense anyway. Instead, we'd report their presence and let the user act, just as we do for longdesc now.
However, this same logic does not apply to errormessage. From an author perspective, I follow that we don't want error messages "stomping" on describedby. However, from an accessibility client perspective, I still don't see the difference. They could still be exposed as part of the description string if they're visible. Aside from being simpler, that would also be better for performance, since an AT doesn't then have to crawl the tree "stringifying" the error messages itself. Can you please explain why this approach doesn't work? Again, please note that I'm talking about the accessibility API mapping, *not* the ARIA attributes; I understand why errormessage and describedby are separate ARIA attributes for authors.Thanks.Jamie
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
James,
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions.
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution tha

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-24 Thread Richard Schwerdtfeger

Well, If you had an error message I can certainly see the need for the user to, after they have gone to the error message, go back to the associated control to fix the error. ... aria-details reverse relationship, I don't believe, is as critical.  We do not, however, put normative requirements on ATVs in terms of the user experience.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs <jdi...@igalia.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-ia2@lists.linuxfoundation.org, cl...@alum.mit.eduSubject: Re: [Accessibility-ia2] aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 1:50 PM 
Hi Rich.My previously-stated [1] position has not changed, namely:IF ATs will be expected to provide navigation between error messages andelements with errors regardless of circumstances, THEN I think we needthe reverse relationship because doing a complete tree dive looking forthe element which points to the error is not reasonable.On the other hand, if my scenario is so artificial that it would neverhappen, then I'm fine with having to keep track of the field beforemoving the user to the error.Whether or not ATs will be expected to provide such navigation, I couldnot tell you. Once we know that answer, you can plug it into the quotedstatement to get my response. ;)[1]https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-August/002064.html--joanieOn 08/24/2016 02:26 PM, Richard Schwerdtfeger wrote:> These were the original relation names for error message and details>  > IA2_RELATION_DETAILS> IA2_RELATION_ERROR_MESSAGE>  > I also have these relationships for ATK/ATSPI:> RELATION_DETAILS> RELATION_ERROR_MESSAGE>  > They are listed in this branch I am working on:> https://rawgit.com/w3c/aria/action2102/core-aam/core-aam.html>  > Unless stated otherwise these are what I am putting in the spec. Joanie,> I need you an Jamie to settle on whether there is a reverse relationship.>  > I have opened an issue against the name and description spec. regarding> concatenation: https://www.w3.org/WAI/ARIA/track/issues/1044>  > I have included Joseph on CC so that he is aware of the name and> description issue.>> Rich Schwerdtfeger>  >  >>     - Original message ->     From: Richard Schwerdtfeger/Austin/IBM@IBMUS>     Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org>     To: jdi...@igalia.com>     Cc: accessibility-ia2@lists.linuxfoundation.org>     Subject: Re: [Accessibility-ia2] aria-details and aria-errormessage>     mapping>     Date: Wed, Aug 24, 2016 10:01 AM>      >     ok.>      >     So, Alex, please provide me the name of the two IA2 relationships>     fore details and error message? I will work with joseph and amelia>     to look at concatenation of error messages in the description.>      >     Also, Joanie expressed a desire to have reverse relationships for>     details and error message. I would like you all to give a definitive>     answer on that. If you decide to go with a reverse relationship then>     I will need the the names for the spec.>      >     Keep in mind that after IA2 and ATK/ATSPI we also have to deal with>     UIA and MacOSX.>      >     Regards,>     Rich>>     Rich Schwerdtfeger>      >      >>         - Original message ->         From: Joanmarie Diggs <jdi...@igalia.com>>         To: Richard Schwerdtfeger/Austin/IBM@IBMUS>         Cc: ja...@nvaccess.org,>         accessibility-ia2@lists.linuxfoundation.org,>         surkov.alexan...@gmail.com>         Subject: Re: aria-details and aria-errormessage mapping>         Date: Wed, Aug 24, 2016 9:52 AM>          >         Hey Rich.>>         On matters where I have no strong opinion, but Jamie does, I>         defer to>         Jamie. Mapping of aria-details and aria-errormessage for my platform>         falls into this category, at least currently. Let's suck it and see.>>         --joanie>>         On 08/24/2016 10:39 AM, Richard Schwerdtfeger wrote:>         > Alright. I am looking at the ARIA spec. and it does not preclude>         > concatenating the strings for error messages. Our name and>         description>         > spec. will take a hit as will the SVG a11y mapping spec. I>         will need to>         > discuss this with Joseph Scheuhammer. Joanie do you support James'>         > rational for concatenation?>         >  >         > We do need separate relationships on the platform for details,>         > descriptions, and error messages.>         >  >         > Rich>         >>         >>         > Rich Schwerdtfeger>         >  >         >  >         >>         >     - Original message ->

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-24 Thread Richard Schwerdtfeger

These were the original relation names for error message and details
 
IA2_RELATION_DETAILS
IA2_RELATION_ERROR_MESSAGE
 
I also have these relationships for ATK/ATSPI:
RELATION_DETAILS
RELATION_ERROR_MESSAGE
 
They are listed in this branch I am working on: https://rawgit.com/w3c/aria/action2102/core-aam/core-aam.html
 
Unless stated otherwise these are what I am putting in the spec. Joanie, I need you an Jamie to settle on whether there is a reverse relationship.
 
I have opened an issue against the name and description spec. regarding concatenation: https://www.w3.org/WAI/ARIA/track/issues/1044
 
I have included Joseph on CC so that he is aware of the name and description issue. Rich Schwerdtfeger
 
 
- Original message -From: Richard Schwerdtfeger/Austin/IBM@IBMUSSent by: accessibility-ia2-boun...@lists.linuxfoundation.orgTo: jdi...@igalia.comCc: accessibility-ia2@lists.linuxfoundation.orgSubject: Re: [Accessibility-ia2] aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 10:01 AM 
ok.
 
So, Alex, please provide me the name of the two IA2 relationships fore details and error message? I will work with joseph and amelia to look at concatenation of error messages in the description.
 
Also, Joanie expressed a desire to have reverse relationships for details and error message. I would like you all to give a definitive answer on that. If you decide to go with a reverse relationship then I will need the the names for the spec. 
 
Keep in mind that after IA2 and ATK/ATSPI we also have to deal with UIA and MacOSX.
 
Regards,
RichRich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs <jdi...@igalia.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: ja...@nvaccess.org, accessibility-ia2@lists.linuxfoundation.org, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 9:52 AM 
Hey Rich.On matters where I have no strong opinion, but Jamie does, I defer toJamie. Mapping of aria-details and aria-errormessage for my platformfalls into this category, at least currently. Let's suck it and see.--joanieOn 08/24/2016 10:39 AM, Richard Schwerdtfeger wrote:> Alright. I am looking at the ARIA spec. and it does not preclude> concatenating the strings for error messages. Our name and description> spec. will take a hit as will the SVG a11y mapping spec. I will need to> discuss this with Joseph Scheuhammer. Joanie do you support James'> rational for concatenation?>  > We do need separate relationships on the platform for details,> descriptions, and error messages.>  > Rich>>> Rich Schwerdtfeger>  >  >>     - Original message ->     From: James Teh <ja...@nvaccess.org>>     To: Richard Schwerdtfeger/Austin/IBM@IBMUS>     Cc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com,>     surkov.alexan...@gmail.com>     Subject: Re: aria-details and aria-errormessage mapping>     Date: Tue, Aug 23, 2016 8:02 PM>      >>     Hi Rich,>>      >     On 24/08/2016 5:14 AM, Richard Schwerdtfeger wrote:>>     1.There is only one method in each platform to place a>>     description. If you have describedby and errormessage>>     relationships which wins?>     Concatenate, which brings us to:>      >>     2. We cannot guarantee that concatenating them both into one big>>     description will make sense to the user as they were not designed>>     to work that way. Also, the user might want not want to listen to>>     them both together.>     If the field is invalid, we're going to read the error message>     anyway and it's going to be read as well as the description and any>     other info. The practical upshot is that we end up with the same>     result as concatenation.>      >>     3. Error messages are typically created as alerts as they pop up>>     and need to be spoken. So, the user will hear them. The issue is>>     which one belongs to which form element.>     When an invalid form element gets focus, I'm guessing it makes sense>     for the user to receive the error message. That requires it to be>     stringified.>      >>     4. We don't want to have the user agent have to stringify the text>>     either for performance reasons.>     It's more performant for a user agent to stringify than it is for an>     AT. Also, user agents are already stringifying aria-labelledby,>     aria-describedby, name from content, etc., so that argument doesn't>     really hold.>>      >>     So, I would not want you to stringify the error text. The only>>     times you will need to provide access to the error message is when>>     you:>>     1. Have an invalid element (aria-invalid)>     At which point we need to stringify it. I'm only suggesting that it>     be stringified by the UA

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-24 Thread Richard Schwerdtfeger

ok.
 
So, Alex, please provide me the name of the two IA2 relationships fore details and error message? I will work with joseph and amelia to look at concatenation of error messages in the description.
 
Also, Joanie expressed a desire to have reverse relationships for details and error message. I would like you all to give a definitive answer on that. If you decide to go with a reverse relationship then I will need the the names for the spec. 
 
Keep in mind that after IA2 and ATK/ATSPI we also have to deal with UIA and MacOSX.
 
Regards,
RichRich Schwerdtfeger
 
 
- Original message -From: Joanmarie Diggs <jdi...@igalia.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: ja...@nvaccess.org, accessibility-ia2@lists.linuxfoundation.org, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Wed, Aug 24, 2016 9:52 AM 
Hey Rich.On matters where I have no strong opinion, but Jamie does, I defer toJamie. Mapping of aria-details and aria-errormessage for my platformfalls into this category, at least currently. Let's suck it and see.--joanieOn 08/24/2016 10:39 AM, Richard Schwerdtfeger wrote:> Alright. I am looking at the ARIA spec. and it does not preclude> concatenating the strings for error messages. Our name and description> spec. will take a hit as will the SVG a11y mapping spec. I will need to> discuss this with Joseph Scheuhammer. Joanie do you support James'> rational for concatenation?>  > We do need separate relationships on the platform for details,> descriptions, and error messages.>  > Rich>>> Rich Schwerdtfeger>  >  >>     - Original message ->     From: James Teh <ja...@nvaccess.org>>     To: Richard Schwerdtfeger/Austin/IBM@IBMUS>     Cc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com,>     surkov.alexan...@gmail.com>     Subject: Re: aria-details and aria-errormessage mapping>     Date: Tue, Aug 23, 2016 8:02 PM>      >>     Hi Rich,>>      >     On 24/08/2016 5:14 AM, Richard Schwerdtfeger wrote:>>     1.There is only one method in each platform to place a>>     description. If you have describedby and errormessage>>     relationships which wins?>     Concatenate, which brings us to:>      >>     2. We cannot guarantee that concatenating them both into one big>>     description will make sense to the user as they were not designed>>     to work that way. Also, the user might want not want to listen to>>     them both together.>     If the field is invalid, we're going to read the error message>     anyway and it's going to be read as well as the description and any>     other info. The practical upshot is that we end up with the same>     result as concatenation.>      >>     3. Error messages are typically created as alerts as they pop up>>     and need to be spoken. So, the user will hear them. The issue is>>     which one belongs to which form element.>     When an invalid form element gets focus, I'm guessing it makes sense>     for the user to receive the error message. That requires it to be>     stringified.>      >>     4. We don't want to have the user agent have to stringify the text>>     either for performance reasons.>     It's more performant for a user agent to stringify than it is for an>     AT. Also, user agents are already stringifying aria-labelledby,>     aria-describedby, name from content, etc., so that argument doesn't>     really hold.>>      >>     So, I would not want you to stringify the error text. The only>>     times you will need to provide access to the error message is when>>     you:>>     1. Have an invalid element (aria-invalid)>     At which point we need to stringify it. I'm only suggesting that it>     be stringified by the UA if all conditions are met; invalid,>     visible, etc.>>     2. An error message is provided.>     At which point we also need to stringify it, but in fairness, this>     will probably be an alert anyway, so I'm less worried about this one.>>     Jamie>      >     -->     James Teh>     Executive Director, NV Access Limited>     Ph +61 7 3149 3306>     www.nvaccess.org <http://www.nvaccess.org>>     Facebook: http://www.facebook.com/NVAccess>     Twitter: @NVAccess>     SIP: ja...@nvaccess.org <mailto:ja...@nvaccess.org>>>  >  
 

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

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-21 Thread Richard Schwerdtfeger

Hi James,
If you wanted to reuse the existing description relationships (with a separate description relationship instance) and place an object attribute on the error message target to indicate that it is an error message I think that makes perfect sense. It just can't be stringified. However, the errormessage is not to be stringified as the content must be visible and it will often have content in it, including links, that the user may need to navigate to to get help about the error. The aria referenced error messages are all required to be visible to apply the relatinship.
Rich Schwerdtfeger
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.com, surkov.alexan...@gmail.comSubject: Re: aria-details and aria-errormessage mappingDate: Sun, Aug 21, 2016 7:46 PM
Hi Rich,
Thanks for the clear explanations; I really do appreciate it. Part of the confusion here is that I've unintentionally conflated aria-details with aria-errormessage.
Regarding aria-details, what you say absolutely makes sense. Given that, reading the details automatically as a simple message doesn't make sense anyway. Instead, we'd report their presence and let the user act, just as we do for longdesc now.
However, this same logic does not apply to errormessage. From an author perspective, I follow that we don't want error messages "stomping" on describedby. However, from an accessibility client perspective, I still don't see the difference. They could still be exposed as part of the description string if they're visible. Aside from being simpler, that would also be better for performance, since an AT doesn't then have to crawl the tree "stringifying" the error messages itself. Can you please explain why this approach doesn't work? Again, please note that I'm talking about the accessibility API mapping, *not* the ARIA attributes; I understand why errormessage and describedby are separate ARIA attributes for authors.Thanks.Jamie
On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:
>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
James,
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions.
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply does not meet the needs of digital publishing community. What is more they plan to support it in their digital books once a mechanism is put in place, within browsers, to show and hide content reference by aria-details in order to preserve the needs of publishers who don't want extended descriptions rendered by default. We definitely, don't want this functionality applied to aria-describedby.
>2. Having errormessage/details as completely separate concepts from description means an AT now

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-19 Thread Richard Schwerdtfeger

>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
 
James,
 
I appreciate your willingness to work with us on this. However, let me provide you with the full picture.
 
1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions. 
 
The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply does not meet the needs of digital publishing community. What is more they plan to support it in their digital books once a mechanism is put in place, within browsers, to show and hide content reference by aria-details in order to preserve the needs of publishers who don't want extended descriptions rendered by default. We definitely, don't want this functionality applied to aria-describedby.
 
>2. Having errormessage/details as completely separate concepts from description means an AT now has two more things it has to fetch for *every single object that gets focus*. This is >yet another perf problem.
 
Error messages are not the same as extended descriptions and we don't want the same functionality to duplicated with error messages as I described above. The need for error messages arose many major companies rendering visible, popup, error messages for each invalid form entry. They want to have people with disabilities get access to each error messages associated with the invalid control and they want to also have access to the hidden aria-describedby help information they provide for that control. So, stomping on one in favor of the other is a very bad experience. They are indeed distinct and separate concepts.
>3. That said, since the no description/no stringification decision has already been made (despite the concerns above which I raised months ago), relations is the only mapping that >doesn't violate the spec.
 
See above. I hope I have addressed most of your concerns.
>4. Since we're not stringifying as part of description, it does not make sense to map these to the describedBy relation. Thus, we need two new relations.
 
ok
>5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept >that this use case may one day arise.
Joanie Diggs asked for reverse relationships as she wants to be able to traverse back to the source. She is on CC and will be back from vacation next week.
 
Best,
Rich
Rich Schwerdtfeger
 
 
- Original message -From: James Teh <ja...@nvaccess.org>To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.comCc: accessibility-ia2@lists.linuxfoundation.org, jdi...@igalia.comSubject: Re: aria-details and aria-errormessage mappingDate: Thu, Aug 18, 2016 9:45 PM 
Hi.
 I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. Given that this has basically become a circular t

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-18 Thread Richard Schwerdtfeger

We *cannot* map aria-errormessage or aria-details to a string description. That is absolutely prohibited in the aria specification. It is not to be stringified. Neither is aria-details. Also, in the aria spec. if aria-details and aria-describedby cannot be mapped separately aria-details takes precedence.
 
These are intended to be references so that we can also get access to the structural markup.
 
Now, if you are going to overload the description relationships we need something on the target that indicates they are an error or an extended description. We need to have the distinctions. Object attributes are an option.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: "accessibility-ia2@lists.linuxfoundation.org" <accessibility-ia2@lists.linuxfoundation.org>, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>Subject: Re: aria-details and aria-errormessage mappingDate: Fri, Aug 12, 2016 7:42 PM 
I'd love to hear Jamie on this honestly, but his wording was:"
To me, it sounds like errormessage just makes the rules slightly simplyto make life simpler for authors; errormessage isn't presented unlessinvalid is true, errormessage must be visible to be presented, etc. Thatmight be fair enough. However, that doesn't mean it's an entirelyfundamentally separate concept, and thus, there's a good argument formapping it to description in a11y APIs (with appropriate rules)."Do we a real example/scenario where AT has to know that a message on the screen is an error message, and this knowledge would improve the user experience?
 
On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger <sch...@us.ibm.com> wrote:

Yes, we heard. So, we need to be able to differentiate an associated error message from a help descriptions. So, you could have a second aria-details relationship in the list of relationships as it would not be stringified (a necessity), BUT you would need to put something on the target ID container to indicate to the AT that it is an error message. Otherwise you need a different relationship. If you are not having reverse relationships and AT vendors would provide a mechanism to go back to the element that was invalid then you would be fine. The use cases we have seen in practices is that multiple form elements become invalid and each has an associated popup error message.
 
We cannot mix descriptions and error messages and the error messages must be visible to all users to be mapped.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUSCc: "accessibility-ia2@lists.linuxfoundation.org" <accessibility-ia2@lists.linuxfoundation.org>, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>Subject: Re: aria-details and aria-errormessage mappingDate: Wed, Aug 10, 2016 12:48 PM 
Note, Jamie has been objecting against new relation for aria-errormessage [1].[1] https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-April/002046.html
 
On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov <surkov.alexan...@gmail.com> wrote:

All reverse relations go at performance/memory cost, I would introduce them iff AT needs them. I'm not sure I see a valid scenario, when they were useful, thus deferring a decision to Joanie and Jamie, who knows more about AT internal gear than me.
 
On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger <sch...@us.ibm.com> wrote:

Those would be great. What would you have for reverse relationships?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: "accessibility-ia2@lists.linuxfoundation.org" <accessibility-ia2@lists.linuxfoundation.org>, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>, Richard Schwerdtfeger/Austin/IBM@IBMUSCc:Subject: aria-details and aria-errormessage mappingDate: Tue, Aug 9, 2016 2:12 PM 
Hi.ARIA 1.1 got two relation-like attributes: aria-details [1] and aria-errormessage [2], used to connect an element with content providing extra info. Rich mentioned that these attributes are likely need new IAccessible2 relations to expose them, which sounds reasonable. If that's the case, then we should end up with something like: 
An object containing details for the target object.
IA2_RELATION_DETAILS
An object containing an error message for the target object.
IA2_RELATION_ERROR_MESSAGEThanks.Alex.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
 
 
 

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

Re: [Accessibility-ia2] aria-details and aria-errormessage mapping

2016-08-09 Thread Richard Schwerdtfeger

Those would be great. What would you have for reverse relationships?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov <surkov.alexan...@gmail.com>To: "accessibility-ia2@lists.linuxfoundation.org" <accessibility-ia2@lists.linuxfoundation.org>, James Teh <ja...@nvaccess.org>, Joanmarie Diggs <jdi...@igalia.com>, Richard Schwerdtfeger/Austin/IBM@IBMUSCc:Subject: aria-details and aria-errormessage mappingDate: Tue, Aug 9, 2016 2:12 PM 
Hi.ARIA 1.1 got two relation-like attributes: aria-details [1] and aria-errormessage [2], used to connect an element with content providing extra info. Rich mentioned that these attributes are likely need new IAccessible2 relations to expose them, which sounds reasonable. If that's the case, then we should end up with something like: 
An object containing details for the target object.
IA2_RELATION_DETAILS
An object containing an error message for the target object.
IA2_RELATION_ERROR_MESSAGEThanks.Alex.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage
 

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

Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-02-24 Thread Richard Schwerdtfeger

We want to separate out errors from help information. aria-errormessage only 
takes an IDREF.

> On Feb 24, 2016, at 5:14 PM, James Teh  wrote:
> 
> I thought aria-describedby could refer to multiple nodes. As such, I don't 
> follow why authors were "stuck" when they wanted both an error message and a 
> description. They could just put both in aria-describedby.
> 
> If you really do want errormessage to be treated as an entirely separate 
> thing, then I have to change my position on this: we need a new relation and 
> new events. If it's really such a new and separate thing, we don't have to 
> worry about existing AT not getting the benefit.
> 
> Sent from a mobile device
> 
>> On 25 Feb 2016, at 1:50 AM, Joseph Scheuhammer  wrote:
>> 
>> Part of the rationale for introducing aria-errormessage was that authors 
>> were already using aria-describedby for the error message, but were stuck 
>> when they wanted to provide a description separate from the error message. 
>> Thus, a reason for introducing aria-errormessage was to distinguish it from 
>> the description.  Consider also that error messages are transient, whereas 
>> descriptions are not.
>> 
>> Conflating the two at the AAPI level is counterproductive.
>> 
>>> On 2016-02-23 6:20 PM, Joanmarie Diggs wrote:
>>> Hey Jamie.
>>> 
>>> Yeah, we have a description property which is a string. Right now, I
>>> don't have a strong feeling either way about whether aria-errormessage's
>>> text belongs as part of that value. So if you think it should be there
>>> in addition to exposed via the relationship pair, I don't mind.
>>> 
>>> --joanie
>>> 
 On 02/23/2016 06:03 PM, James Teh wrote:
> Sounds great. I'm happy with this mapping.
> 
> Would this message be included in the concatenated description string
> for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2),
> you can call the accDescription property and it provides the description
> as a string. Right now, that would include the text of anything listed
> in aria-describedby. I think it*should*  include the error message myself.
> 
> Jamie
> 
> On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:
>>> Hey all.
>>> 
>>> We need to map aria-errormessage on the various platforms, including
>>> ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
>>> homogeneity, I'll toss out what I was thinking for my platform for
>>> consideration by IA2 folks.
>>> 
>>> Proposal: Connect the message to the element with the error via the
>>> RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
>>> "errormessage" as an object attribute.
>>> 
>>> Rationale:
>>> 
>>> 1. An error message provides descriptive information about an object.
>>> 
>>> 2. Exposure via a relation eliminates the need to tree dive to find
>>>the error.
>>> 
>>> 3. Accessible relations can have multiple targets, so this exposure
>>>does not stomp on a non-error description while at the same time
>>>eliminating the need for each platform to create a new relation
>>>type(s).
>>> 
>>> 4. The object attribute is needed to identify which target (if any)
>>>is an error message.
>>> 
>>> Thoughts?
>>> --joanie
>>> ___
>>> Accessibility-ia2 mailing list
>>> Accessibility-ia2@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
> 
>> 
>> 
>> -- 
>> joseph.
>> 
>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>>- C. Carter -
>> 
> 

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

Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-02-24 Thread Richard Schwerdtfeger

Error messages may have additional content in there that needs greater semantic 
structure. For example, what if the error message had a link to a online help 
area about the topic. Converting it to a string would not work.

Rich
> On Feb 23, 2016, at 5:20 PM, Joanmarie Diggs  wrote:
> 
> Hey Jamie.
> 
> Yeah, we have a description property which is a string. Right now, I
> don't have a strong feeling either way about whether aria-errormessage's
> text belongs as part of that value. So if you think it should be there
> in addition to exposed via the relationship pair, I don't mind.
> 
> --joanie
> 
> On 02/23/2016 06:03 PM, James Teh wrote:
>> Sounds great. I'm happy with this mapping.
>> 
>> Would this message be included in the concatenated description string
>> for an object? I'm not sure if ATK has this, but in MSAA (and thus IA2),
>> you can call the accDescription property and it provides the description
>> as a string. Right now, that would include the text of anything listed
>> in aria-describedby. I think it *should* include the error message myself.
>> 
>> Jamie
>> 
>> On 24/02/2016 5:42 AM, Joanmarie Diggs wrote:
>>> Hey all.
>>> 
>>> We need to map aria-errormessage on the various platforms, including
>>> ATK/AT-SPI2 and IA2. Given the ongoing desire for cross-platform
>>> homogeneity, I'll toss out what I was thinking for my platform for
>>> consideration by IA2 folks.
>>> 
>>> Proposal: Connect the message to the element with the error via the
>>> RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR relation pair and expose
>>> "errormessage" as an object attribute.
>>> 
>>> Rationale:
>>> 
>>> 1. An error message provides descriptive information about an object.
>>> 
>>> 2. Exposure via a relation eliminates the need to tree dive to find
>>>the error.
>>> 
>>> 3. Accessible relations can have multiple targets, so this exposure
>>>does not stomp on a non-error description while at the same time
>>>eliminating the need for each platform to create a new relation
>>>type(s).
>>> 
>>> 4. The object attribute is needed to identify which target (if any)
>>>is an error message.
>>> 
>>> Thoughts?
>>> --joanie
>>> ___
>>> 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] aria-colcount and aria-rowcount mapping, again

2016-01-04 Thread Richard Schwerdtfeger

Although it is possible to have 2 cells I don't think this even close to
the norm. Why would we we not just have the screen reader ask to go to a
row and column number? It is not difficult to ask the user agent to
navigate to compute the effective cell to the right and ask for the user
agent to navigate there. We can add a parameter that states to navigate to
the first non-empty cell to the ... or whatever algorithm we choose.

Rich

Rich Schwerdtfeger

From:   Dominic Mazzoni <dmazz...@google.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, James Teh
<ja...@nvaccess.org>
Cc: IAccessible2 mailing list
<accessibility-...@lists.linux-foundation.org>,
accessibility-ia2-boun...@lists.linuxfoundation.org
Date:   01/04/2016 10:47 AM
Subject:Re: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again

Rich, I think the problem is, what if the table consists of just two cells,
(1, 1) and (999, 999) - the screen reader wants to go to the

Jamie, as an alternative, couldn't the screen reader try navigating to the
next / previous cell using the row, column index, but if that fails, fall
back on DOM navigation?

For example, given a current cell (x, y), if the user wants to go right -
to the next cell in the same row, try (x + 1, y) but if that's empty, use
the accessibility tree to navigate to the next sibling.

Similarly, given (x, y) if the user wants to go down - to the same column
in the next row, try (x, y + 1), but if that's empty, use the accessibility
tree to navigate to the next row, then try column x in that row, and if
that fails, navigate to the first cell in that row.

Anyway, I would be fine with also extending IAccessibleTableCell.

On Mon, Jan 4, 2016 at 6:51 AM Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:
  Would it not be better to just navigate to a given row and column index?
  Why limit it to just the cell in a direction?

  Rich Schwerdtfeger

  James Teh ---01/03/2016 10:55:11 PM---On 29/12/2015 5:52 AM, Dominic
  Mazzoni via Accessibility-ia2 wrote: > Totally agreed that screen rea

  From: James Teh <ja...@nvaccess.org>
  To: Dominic Mazzoni <dmazz...@google.com>, IAccessible2 mailing list <
  accessibility-...@lists.linux-foundation.org>
  Date: 01/03/2016 10:55 PM
  Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping,
  again
  Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org

  On 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
  > Totally agreed that screen readers need to be able to navigate from
  > cell to cell and fetch rows at a time. Note that the spec requires the
  > numbering to be sequential, so you don't need to worry about that.
  When I said sequential, I also meant contiguous; i.e. 1, 2, 3, not 1, 2,
  5.
  >
  > I'd like to point out that in vanilla HTML it's quite common for
  > tables to have missing cells already.
  Missing cells only towards the end of rows, never in the middle or at
  the start. So, you might not be able to move to the next cell at the end
  of an incomplete row, but that's okay because you've already seen all of
  the cells on that row. Conversely, if there are cells missing at the
  start or in the middle of a row, it may be impossible to get to other
  cells in the row.

  > Screen readers shouldn't have to do any extra work to deal with most
  > such tables because they already need to be able to handle missing
  > cells, so this wouldn't be any different.
  >
  See above. Start/middle gaps are a problem and I can't even think of a
  good way to handle this. This is why I am probably more for this
  solution:

  > The alternative proposal seems to be to export the ARIA attributes
  > and/or use group position and have the screen reader announce the ARIA
  > row and column indexes but otherwise explore the table from the DOM.

  > * Screen readers wouldn't be able to jump to a cell by row, column
  > index. (JAWS has a keystroke for this now.)
  Hmm. That certainly is a problem, yes.

  I guess another solution could be to extend IAccessibleTableCell to
  provide a way to get to the next cell in a given direction. I *think*
  that would solve the start/middle gap problem.

  Jamie

  --
  James Teh
  Executive Director, NV Access Limited
  Ph +61 7 3149 3306
  www.nvaccess.org
  Facebook: http://www.facebook.com/NVAccess

  Twitter: @NVAccess
  SIP: ja...@nvaccess.org

  ___
  Accessibility-ia2 mailing list
  Accessibility-ia2@lists.linuxfoundation.org

  https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

  [attachment "graycol.gif" deleted by Richard Schwerdtfeger/Austin/IBM]
  [attachment "graycol.gif" deleted by Richard Schwerdtfeger/Austin/IBM]

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

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

2016-01-04 Thread Richard Schwerdtfeger


Would it not be better to just navigate to a given row and column index?
Why limit it to just the cell in a direction?


Rich Schwerdtfeger



From:   James Teh 
To: Dominic Mazzoni , IAccessible2 mailing
list 
Date:   01/03/2016 10:55 PM
Subject:Re: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



On 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
> Totally agreed that screen readers need to be able to navigate from
> cell to cell and fetch rows at a time. Note that the spec requires the
> numbering to be sequential, so you don't need to worry about that.
When I said sequential, I also meant contiguous; i.e. 1, 2, 3, not 1, 2, 5.
>
> I'd like to point out that in vanilla HTML it's quite common for
> tables to have missing cells already.
Missing cells only towards the end of rows, never in the middle or at
the start. So, you might not be able to move to the next cell at the end
of an incomplete row, but that's okay because you've already seen all of
the cells on that row. Conversely, if there are cells missing at the
start or in the middle of a row, it may be impossible to get to other
cells in the row.

> Screen readers shouldn't have to do any extra work to deal with most
> such tables because they already need to be able to handle missing
> cells, so this wouldn't be any different.
>
See above. Start/middle gaps are a problem and I can't even think of a
good way to handle this. This is why I am probably more for this solution:

> The alternative proposal seems to be to export the ARIA attributes
> and/or use group position and have the screen reader announce the ARIA
> row and column indexes but otherwise explore the table from the DOM.

> * Screen readers wouldn't be able to jump to a cell by row, column
> index. (JAWS has a keystroke for this now.)
Hmm. That certainly is a problem, yes.

I guess another solution could be to extend IAccessibleTableCell to
provide a way to get to the next cell in a given direction. I *think*
that would solve the start/middle gap problem.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org

___
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] aria-colcount and aria-rowcount mapping, again

2015-12-31 Thread Richard Schwerdtfeger


What I mean by the DOM going away is accessibility test tools, today, don't
get access to the Web Components DOM. It is hidden. This is a gap. Also, if
you were to traverse the IE DOM you would not reach the Web Components DOM.
So, we have a gap here too strategically.

I understand that web components make use of a DOM tree but it is separate.

So, regarding API mappings you want to have the ATs control the browser
(move focus and have the browser load more content)?


Rich Schwerdtfeger



From:   Dominic Mazzoni <dmazz...@google.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: IAccessible2 mailing list
<accessibility-...@lists.linux-foundation.org>,
accessibility-ia2-boun...@lists.linuxfoundation.org
Date:   12/31/2015 04:07 PM
Subject:Re: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again



On Thu, Dec 31, 2015 at 1:51 PM Richard Schwerdtfeger <sch...@us.ibm.com>
wrote:
  Hi Dominic,

  We can look at adding this work as part of ARIA 2.0 and the common
  accessibility api work for browsers.


I don't think anything I'm asking for is a change in the ARIA spec. I'm
basically okay with what's in ARIA 1.1 now. However, we need to nail this
down as part of the User Agent Implementation Guide for ARIA 1.1.
  The need for this goes beyond screen readers. Alternative input solutions
  will need this too.


Sure, of course.
  Also, the traditional DOM is going away with web components if that takes
  off necessitating more work like this.


What makes you say the DOM is going away? Web components are just an
extension of the DOM by letting authors define their own elements, but
there's still a pretty well-defined "composed" DOM tree. Assistive
technology shouldn't know or care about whether there are web components or
not. I think some work is needed to address some gaps right now (for
example the IDREF issue that makes some ARIA attributes not work well with
web components) but there are workarounds.

- Dominic




  Rich


  Rich Schwerdtfeger

  graycol.gifDominic Mazzoni via Accessibility-ia2 ---12/30/2015 07:00:47
  PM---Hi, This is a follow-up to a mail thread from June on the correct
  mapping of

  From: Dominic Mazzoni via Accessibility-ia2 <
  accessibility-ia2@lists.linuxfoundation.org>
  To: IAccessible2 mailing list <
  accessibility-...@lists.linux-foundation.org>
  Date: 12/30/2015 07:00 PM
  Subject: [Accessibility-ia2] aria-colcount and aria-rowcount mapping,
  again
  Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org








  Hi,

  This is a follow-up to a mail thread from June on the correct mapping of
  aria-rowcount, aria-colcount, aria-rowindex, aria-colindex, etc. to
  IAccessible2.

  The primary intended use case is when all of the rows and columns can't
  be loaded, for performance reasons.

  The current spec does not solve the problem that screen readers need a
  way to request that the page load more rows / columns. I agree this is
  important and I'd be happy to discuss this in a separate thread, but I
  think it's out of the scope of what can be done in ARIA and I don't see
  any reason why we shouldn't move forwards with the current proposal in
  the meantime.

  Jamie wrote:


In order to do table navigation, screen readers need to be able to
navigate
from a given cell to the cell in the next column or the next row,
as
well as being able to fetch all cells in a given row or column. If
the
numbering is not sequential, we can't simply increase indexes to
do
this. No API I know of supports something like this.

  Totally agreed that screen readers need to be able to navigate from cell
  to cell and fetch rows at a time. Note that the spec requires the
  numbering to be sequential, so you don't need to worry about that.

  I'd like to point out that in vanilla HTML it's quite common for tables
  to have missing cells already. Here's a trivial example:

  
    
      1, 1
    
    


      1, 2f



      2, 2
    
  

  In this table, there's no cell 2, 1 even though there are 2 columns and 2
  rows. When a screen reader calls IAccessibleTable2::cellAt(2, 2) it
  returns null.

  Therefore my proposal is to do the same thing with a table that uses ARIA
  to change its row and column indexes. The browser would do the work of
  interpreting the ARIA and would present a virtual table via IAccessible2,
  with some cells missing. Screen readers shouldn't have to do any extra
  work to deal with most such tables because they already need to be able
  to handle missing cells, so this wouldn't be any different.

  The obvious interpretation of aria-rowindex=-1 would be for the browser
  to return an error from IAccessibleTable2::nRows. We'll have to figure
  out what to do if that breaks existing screen readers.

  The alternative proposal seems to be to export the ARIA attributes and/or
  use g

Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

2015-12-31 Thread Richard Schwerdtfeger


Hi Dominic,

We can look at adding this work as part of ARIA 2.0 and the common
accessibility api work for browsers. The need for this goes beyond screen
readers. Alternative input solutions will need this too.

I am trying to wrap ARIA 1.1 up on time so that we can do all the
long-needed essential cross-platform API-related work like this moving.

Also, the traditional DOM is going away with web components if that takes
off necessitating more work like this.

Rich


Rich Schwerdtfeger



From:   Dominic Mazzoni via Accessibility-ia2

To: IAccessible2 mailing list

Date:   12/30/2015 07:00 PM
Subject:[Accessibility-ia2] aria-colcount and aria-rowcount mapping,
again
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



Hi,

This is a follow-up to a mail thread from June on the correct mapping of
aria-rowcount, aria-colcount, aria-rowindex, aria-colindex, etc. to
IAccessible2.

The primary intended use case is when all of the rows and columns can't be
loaded, for performance reasons.

The current spec does not solve the problem that screen readers need a way
to request that the page load more rows / columns. I agree this is
important and I'd be happy to discuss this in a separate thread, but I
think it's out of the scope of what can be done in ARIA and I don't see any
reason why we shouldn't move forwards with the current proposal in the
meantime.

Jamie wrote:
  In order to do table navigation, screen readers need to be able to
  navigate
  from a given cell to the cell in the next column or the next row, as
  well as being able to fetch all cells in a given row or column. If the
  numbering is not sequential, we can't simply increase indexes to do
  this. No API I know of supports something like this.

Totally agreed that screen readers need to be able to navigate from cell to
cell and fetch rows at a time. Note that the spec requires the numbering to
be sequential, so you don't need to worry about that.

I'd like to point out that in vanilla HTML it's quite common for tables to
have missing cells already. Here's a trivial example:


  
    1, 1
  
  
    1, 2f
    2, 2
  


In this table, there's no cell 2, 1 even though there are 2 columns and 2
rows. When a screen reader calls IAccessibleTable2::cellAt(2, 2) it returns
null.

Therefore my proposal is to do the same thing with a table that uses ARIA
to change its row and column indexes. The browser would do the work of
interpreting the ARIA and would present a virtual table via IAccessible2,
with some cells missing. Screen readers shouldn't have to do any extra work
to deal with most such tables because they already need to be able to
handle missing cells, so this wouldn't be any different.

The obvious interpretation of aria-rowindex=-1 would be for the browser to
return an error from IAccessibleTable2::nRows. We'll have to figure out
what to do if that breaks existing screen readers.

The alternative proposal seems to be to export the ARIA attributes and/or
use group position and have the screen reader announce the ARIA row and
column indexes but otherwise explore the table from the DOM. A couple of
downsides of this are:

* Users wouldn't get any support at all if they use an older screen reader
* Screen readers wouldn't be able to jump to a cell by row, column index.
(JAWS has a keystroke for this now.)

- Dominic
___
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] aria-current thread on ia2

2015-12-01 Thread Richard Schwerdtfeger



http://lists.linux-foundation.org/pipermail/accessibility-ia2/2015-September/001939.html

Alex, why would you not want the active state on non-widgets? For example,
if you have a list of links in a navigation landmark section you do not
want to mix focus with active. This is because what is active was the last
navigation item you activated.

Rich


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

Re: [Accessibility-ia2] aria-errormessage

2015-08-11 Thread Richard Schwerdtfeger


Sure, but then you need to separate out descriptions from error messages,
including text extraction for descriptions. We would have to do this for
descriptions and error messages.

Which evil do people prefer?


Rich Schwerdtfeger



From:   Joanmarie Diggs jdi...@igalia.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Alexander Surkov
surkov.alexan...@gmail.com
Cc: accessibility-ia2@lists.linuxfoundation.org
accessibility-ia2@lists.linuxfoundation.org,
accessibility-ia2-boun...@lists.linuxfoundation.org
Date:   08/11/2015 12:06 PM
Subject:Re: [Accessibility-ia2] aria-errormessage



Do we really need a dedicated relationship for this? Because the
target of an AtkRelation is an array of objects, I would think we
could use an existing relationship (e.g. described-by/description-for).
Then we could examine the target object(s) to see if it's the one
defined by aria-errormessage (exposed via object attribute).

--joanie

On 08/11/2015 12:48 PM, Richard Schwerdtfeger wrote:
 yes. We need it for ATK/ATSPI also.


 Rich Schwerdtfeger

 Inactive hide details for Alexander Surkov ---08/11/2015 11:34:44
 AM---Hi. It looks like we need a new relation to expose aria-Alexander
 Surkov ---08/11/2015 11:34:44 AM---Hi. It looks like we need a new
 relation to expose aria-errormessage which refers to an element cont

 From: Alexander Surkov surkov.alexan...@gmail.com
 To: accessibility-ia2@lists.linuxfoundation.org
 accessibility-ia2@lists.linuxfoundation.org
 Date: 08/11/2015 11:34 AM
 Subject: [Accessibility-ia2] aria-errormessage
 Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org

 



 Hi. It looks like we need a new relation to expose aria-errormessage
 which refers to an element containing the error message. Should we have
 a pair IA2_RELATION_ERROR_FOR/BY for that?

 THanks!
 Alexander.

 [1]

_https://rawgit.com/w3c/aria/master/aria/aria.html#aria-errormessage

 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] Fw: ARIA 1.1 feature status aria-rowspan and aria-colspan

2015-07-29 Thread Richard Schwerdtfeger

Yes, that is possible. He also said that would be hideous. :-)

One concern is the growth of object attributes and the mechanism to get them. 
Perhaps we need a new interface to object attributes like a hashing table.

Rich

Sent from my iPad

 On Jul 28, 2015, at 2:32 PM, Alexander Surkov surkov.alexan...@gmail.com 
 wrote:
 
 I'd say the problem is in restrictions of IAccessibleTable as it describes 
 the continuous model only, while ARIA allows to have gaps in tables. So if 
 a table has a gap and spanning right before the gap then we should use a 
 mechanism other than IAccessibleTable. Jamie suggested to use object 
 attributes which sounds reasonable.
 Alex.
 
 On Tue, Jul 28, 2015 at 10:40 AM, Richard Schwerdtfeger sch...@us.ibm.com 
 wrote:
 I am continuing the discussion on the list. It sounds like we have two 
 models - contiguous rows/columns vs. author specified. 
 
 Should we say that if the author is going to provide row and column spans 
 that user agents NOT compute the indices? IOW, It must all be left up to the 
 author. 
 
 It sounds like the issue is that we are fighting with trying to compute the 
 results vs. what the author is putting in. 
 
 Rich
 
 
 Rich Schwerdtfeger
 - Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/28/2015 09:31 AM 
 -
 
 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Richard Schwerdtfeger/Austin/IBM@IBMUS
 Cc: Brett Lewis ble...@freedomscientific.com, David Bolter 
 dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
 Date: 07/28/2015 09:19 AM
 Subject: Re: ARIA 1.1 feature status
 
 
 
 Hi, Rich. Here's Jamie's example [1] where putting ARIA span into 
 IAccessibleTable interface may be not trivial. I suggest to move discussion 
 to IA2 channel if possible.
 
 [1] 
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html
 
 On Tue, Jul 28, 2015 at 8:38 AM, Richard Schwerdtfeger sch...@us.ibm.com 
 wrote:
 That does not make sense. It is essentially the same attribute.
 
 
 Rich Schwerdtfeger
 
 M2.gifAlexander Surkov ---07/27/2015 08:16:15 PM---They are exposed via 
 IAccessibleTable interface which seems to be inapplicable for ARIA spanning.
 
 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Richard Schwerdtfeger/Austin/IBM@IBMUS
 Cc: Brett Lewis ble...@freedomscientific.com, David Bolter 
 dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
 Date: 07/27/2015 08:16 PM
 
 Subject: Re: ARIA 1.1 feature status
 
 
 
 
 They are exposed via IAccessibleTable interface which seems to be 
 inapplicable for ARIA spanning.
 
 On Mon, Jul 27, 2015 at 8:59 PM, Richard Schwerdtfeger sch...@us.ibm.com 
 wrote:
 How do you expose rowspan and colspan for HTML tables?
 
 
 Rich Schwerdtfeger
 
 M2.gifAlexander Surkov ---07/27/2015 04:06:58 PM---Hi, Brett. All but 
 colspan/rowspan are implemented by Nightly. 
 arai-colcount/rowcount/colindex/rowin
 
 From: Alexander Surkov surkov.alexan...@gmail.com
 To: Brett Lewis ble...@freedomscientific.com
 Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank 
 DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter dbol...@mozilla.com
 Date: 07/27/2015 04:06 PM
 Subject: Re: ARIA 1.1 feature status
 
 
 
 Hi, Brett. All but colspan/rowspan are implemented by Nightly. 
 arai-colcount/rowcount/colindex/rowindex are exposed as GroupPosition on 
 cells and rows. There's no understanding yet on how to expose 
 aria-colspan/rowspan [1].
 
 [1] 
 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html
 
 On Mon, Jul 27, 2015 at 4:49 PM, Brett Lewis ble...@freedomscientific.com 
 wrote:
 Hi Alex,
 I am starting work on JAWS support for the new ARIA 1.1 features.
 I wanted to see where you are w/r/t Firefox support for these.
 I was thinking of starting with the table related roles, does Firefox 
 support these?
 How about:
 aria-colcount
 aria-rowcount
 aria-colindex
 aria-rowindex
 aria-colspan
 aria-rowspan
 
 Do you have a general time line for all the ARIA 1.1 features?  (even just 
 an ordering of which features will be implemented first)?
 Do you have a bug record for these?
 Thanks for any info you might have.
 Brett
 
 
 Brett Lewis
 Software Developer
 Freedom Scientific, Inc
 727-299-6270 
 ble...@freedomscientific.com
 
 www.freedomscientific.com
 
 Connect with us:
  

 
 
 ___
 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] Fw: ARIA 1.1 feature status aria-rowspan and aria-colspan

2015-07-28 Thread Richard Schwerdtfeger



I am continuing the discussion on the list. It sounds like we have two
models - contiguous rows/columns vs. author specified.

Should we say that if the author is going to provide row and column spans
that user agents NOT compute the indices? IOW, It must all be left up to
the author.

It sounds like the issue is that we are fighting with trying to compute the
results vs. what the author is putting in.

Rich


Rich Schwerdtfeger
- Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/28/2015 09:31 AM
-

From:   Alexander Surkov surkov.alexan...@gmail.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Brett Lewis ble...@freedomscientific.com, David Bolter
dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
Date:   07/28/2015 09:19 AM
Subject:Re: ARIA 1.1 feature status



Hi, Rich. Here's Jamie's example [1] where putting ARIA span into
IAccessibleTable interface may be not trivial. I suggest to move discussion
to IA2 channel if possible.

[1]
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html

On Tue, Jul 28, 2015 at 8:38 AM, Richard Schwerdtfeger sch...@us.ibm.com
wrote:
  That does not make sense. It is essentially the same attribute.


  Rich Schwerdtfeger

  Inactive hide details for Alexander Surkov ---07/27/2015 08:16:15
  PM---They are exposed via IAccessibleTable interface which seAlexander
  Surkov ---07/27/2015 08:16:15 PM---They are exposed via IAccessibleTable
  interface which seems to be inapplicable for ARIA spanning.

  From: Alexander Surkov surkov.alexan...@gmail.com
  To: Richard Schwerdtfeger/Austin/IBM@IBMUS
  Cc: Brett Lewis ble...@freedomscientific.com, David Bolter 
  dbol...@mozilla.com, Frank DiPalermo/Austin/Contr/IBM@IBMUS
  Date: 07/27/2015 08:16 PM



  Subject: Re: ARIA 1.1 feature status



  They are exposed via IAccessibleTable interface which seems to be
  inapplicable for ARIA spanning.

  On Mon, Jul 27, 2015 at 8:59 PM, Richard Schwerdtfeger sch...@us.ibm.com
   wrote:
How do you expose rowspan and colspan for HTML tables?


Rich Schwerdtfeger

Inactive hide details for Alexander Surkov ---07/27/2015 04:06:58
PM---Hi, Brett. All but colspan/rowspan are implemented by Ni
Alexander Surkov ---07/27/2015 04:06:58 PM---Hi, Brett. All but
colspan/rowspan are implemented by Nightly.
arai-colcount/rowcount/colindex/rowin

From: Alexander Surkov surkov.alexan...@gmail.com
To: Brett Lewis ble...@freedomscientific.com
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Frank
DiPalermo/Austin/Contr/IBM@IBMUS, David Bolter dbol...@mozilla.com

Date: 07/27/2015 04:06 PM
Subject: Re: ARIA 1.1 feature status



Hi, Brett. All but colspan/rowspan are implemented by Nightly.
arai-colcount/rowcount/colindex/rowindex are exposed as
GroupPosition on cells and rows. There's no understanding yet on
how to expose aria-colspan/rowspan [1].

[1]

http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001913.html


On Mon, Jul 27, 2015 at 4:49 PM, Brett Lewis 
ble...@freedomscientific.com wrote:
  Hi Alex,
  I am starting work on JAWS support for the new ARIA 1.1
  features.
  I wanted to see where you are w/r/t Firefox support for
  these.
  I was thinking of starting with the table related roles, does
  Firefox support these?
  How about:
  aria-colcount
  aria-rowcount
  aria-colindex
  aria-rowindex
  aria-colspan
  aria-rowspan

  Do you have a general time line for all the ARIA 1.1
  features?  (even just an ordering of which features will be
  implemented first)?
  Do you have a bug record for these?
  Thanks for any info you might have.
  Brett


  Brett Lewis
  Software Developer
  Freedom Scientific, Inc
  727-299-6270
  ble...@freedomscientific.com

  www.freedomscientific.com

  Connect with us:








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

Re: [Accessibility-ia2] placeholder mapping

2015-05-01 Thread Richard Schwerdtfeger


The problem with the name computation is that:

If you use it to compute a name only and then type over it you lose the
hint. ... e.g. a placeholder value of MMDDYY. The AT can always ask for the
placeholder value.

Rich


Rich Schwerdtfeger



From:   Alexander Surkov surkov.alexan...@gmail.com
To: Joseph Scheuhammer cl...@alum.mit.edu
Cc: IAccessible2 mailing list
accessibility-...@lists.linux-foundation.org, Steve Faulkner
faulkner.st...@gmail.com
Date:   05/01/2015 09:20 AM
Subject:Re: [Accessibility-ia2] placeholder mapping
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



So it seems like we all agree to introduce placeholder object attribute in
IAccessible2. IA2 spec doesn't define markup mappings so it doesn't have to
say about HTML5 placeholder and ARIA aria-placeholder attributes. Anyway,
it doesn't prevent us from discussing it here :) So are there benefits in
changing of current HTML5 placeholder mappings into accessible name and
description?

Btw, Joseph, I didn't really suggested to change GTK+ mappings :)

On Thu, Apr 30, 2015 at 12:05 PM, Joseph Scheuhammer cl...@alum.mit.edu
wrote:
  On 2015-04-29 7:48 AM, Alexander Surkov wrote:
   I support the idea that the browser should find a best match for
   accessible name and description. Btw, current version of HTML a11y spec
   agrees on it [1]. After all there's backward compatibility issue If
   placeholder is exposed leaving accessible name blank.

   [1]
   
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-calculation

  That's not backward compatible with the GNOME desktop (GTK+), where
  placeholder text is not mapped to an empty accessible name.  Thus, there
  is now a mismatch between desktop widgets and widgets within a web page,
  on one desktop.


  --
  joseph.

  'Array(16).join(wat - 1) +  Batman!'
             - G. Bernhardt -

___
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] placeholder mapping

2015-04-27 Thread Richard Schwerdtfeger


I want to also consider HTML5.1 native host language semantics. If we have
an HTML5 checkbox I would think that the native placeholder attribute would
win, over aria-placeholder, as that text would be visible.

Do you agree Steve?




Rich Schwerdtfeger



From:   Joanmarie Diggs jdi...@igalia.com
To: Alexander Surkov surkov.alexan...@gmail.com
Cc: IAccessible2 mailing list
accessibility-...@lists.linux-foundation.org
Date:   04/27/2015 03:32 PM
Subject:Re: [Accessibility-ia2] placeholder mapping
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



Hey Alex.

On 04/27/2015 12:58 PM, Alexander Surkov wrote:

[...]

 Also it's backward compatible approach. So does the following make sense?

 1) If placeholder is used to label the control, i.e accessible name is
 not provided otherwise then map placeholder (aria-placeholder) into
 accessible name
 2) Expose placeholder as object attribute on the accessible object if it
 wasn't used as name.

What about changing 2) to just Expose placeholder as object
attribute.? In other words, independent of what happens in terms of the
name mapping. That's what's happening -- and has been happening for
several years -- in Gtk+ and WebKitGtk for native (non-ARIA) placeholder
text.

--joanie


___
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] placeholder mapping

2015-04-27 Thread Richard Schwerdtfeger


Joseph, fyi:  assuming Joanie and Alex agree on an object attribute, see
below.


Rich


Rich Schwerdtfeger



From:   Steve Faulkner faulkner.st...@gmail.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Joanmarie Diggs jdi...@igalia.com, IAccessible2 mailing list
accessibility-...@lists.linux-foundation.org,
accessibility-ia2-boun...@lists.linuxfoundation.org, Alexander
Surkov surkov.alexan...@gmail.com
Date:   04/27/2015 04:52 PM
Subject:Re: [Accessibility-ia2] placeholder mapping




On 27 April 2015 at 22:40, Richard Schwerdtfeger sch...@us.ibm.com wrote:
  I want to also consider HTML5.1 native host language semantics. If we
  have an HTML5 checkbox I would think that the native placeholder
  attribute would win, over aria-placeholder, as that text would be
  visible.

  Do you agree Steve?

Suggest; If the element supports placeholder and the placeholder attribute
is present and non empty and aria-placeholder is also present and non empty
then the value exposed as a placeholder object attribute should be the
native placeholder content.

--

Regards

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

Re: [Accessibility-ia2] IAccessible2 Proxy.DLL for 64 bit browser support

2014-11-04 Thread Richard Schwerdtfeger


We are also building a 64-bit proxy dll. I can look at open sourcing it
although not in the next month as I have travel.


Rich Schwerdtfeger



From:   James Teh ja...@nvaccess.org
To: accessibility-ia2@lists.linuxfoundation.org
Date:   11/03/2014 06:38 PM
Subject:Re: [Accessibility-ia2] IAccessible2 Proxy.DLL for 64 bit
browser support
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



As far as I know, there is no official 64 bit proxy dll. However, you
are correct that one is needed to use IA2 out-of-process where a 64 bit
process is involved.

We build our own 64 bit proxy for NVDA, so you could download NVDA and
get it from there. Note that this is integrated into our build system,
so it isn't available separately. I'm not sure if this would cause any
licensing/legal issues for you.

Jamie

On 3/11/2014 5:46 PM, Rajesh V R wrote:
 Hello,

 I'm working with some browser depending projects, and using VC++. So how
 can I use the  IAccessible2 Proxy.DLL for 64 bit browsers? Is there
 any other 64bit version available?
 Because, everytime I'm getting the error code 80040154 [HRESULT:
 0x80040154 (REGDB_E_CLASSNOTREG)].
 I'm registering the IAccessible2Proxy.DLL from Syswow64 folder using
 the command regsvr32.
 The problem is mainly with Google Chrome 64bit. Please help me to solve
 this issue.

 Thanks,
 Rajesh


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


--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org
___
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] IAccessible2

2014-07-08 Thread Richard Schwerdtfeger



Hi Pete, Janina,

As you may know ARIA 1.1 will require some modifications to platform
accessibility APIs. Alex Surkov, from Mozilla, has agreed to take over
Pete's position in the Linux Foundation to make the necessary changes, as
well as other enhancements, required for IA2 implementers. He also needs to
coordinate with the ATK/ATSPI effort to ensure consistency across
platforms.

Alex would like some assistance on process for producing documentation and
updated IDL documents and any other processes and coordination efforts in
the Linux Foundation.

Please lend him any assistance you can to help get him started.

Best,

Rich


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

Re: [Accessibility-ia2] IAccessible2

2014-07-08 Thread Richard Schwerdtfeger


Super.

Alex is gong to be great. Thank you for all your wonderful work  on IA2
Pete!


Rich Schwerdtfeger



From:   Pete Brunet p...@a11ysoft.com
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: IAccessible2 mailing list
accessibility-ia2@lists.linuxfoundation.org
Date:   07/08/2014 12:15 PM
Subject:Re: IAccessible2



Hi Rich, I'll be in contact with Alex for the handoff.  -Pete

On 7/8/14, 11:36 AM, Richard Schwerdtfeger wrote:


  Hi Pete, Janina,

  As you may know ARIA 1.1 will require some modifications to platform
  accessibility APIs. Alex Surkov, from Mozilla, has agreed to take
  over Pete's position in the Linux Foundation to make the necessary
  changes, as well as other enhancements, required for IA2
  implementers. He also needs to coordinate with the ATK/ATSPI effort
  to ensure consistency across platforms.

  Alex would like some assistance on process for producing
  documentation and updated IDL documents and any other processes and
  coordination efforts in the Linux Foundation.

  Please lend him any assistance you can to help get him started.

  Best,

  Rich


  Rich Schwerdtfeger



--
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

Re: [Accessibility-ia2] IAccessibleTable2::caption/summary deprecation notes need correcting

2013-10-12 Thread Richard Schwerdtfeger

Thanks Pete.

Sent from my iPad

 On Oct 12, 2013, at 12:43 AM, Pete Brunet p...@a11ysoft.com wrote:
 
 The IAccessibleTable2 spec has an error.  The deprecation note on the caption 
 method indicates that a describedBy relation should be used and the 
 deprecation note on the summary method indicates that a labeledBy relation 
 should be used instead.  This is backwards and I will submit a replacement 
 soon. 
 
 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

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


Hi Pete,

The reason for the editing functions was to allow a voice reco solution to
select text, edit it, and perform clipboard operations for the mobility
impaired. It is additional work to have a voice reco solution have to go
through the additional work of doing the additional keyboard simulations
for doing that function.

So, these are single actions. AccessibleEditableText also allows you to
replace text, and set attributes, which takes offsets and replacement
text/attributes. Accessible actions are single action functions that don't
take parameters. ReplaceText is not the same as pasting from the clipboard.
It is really nice to have all the features in the same interface. Note: One
could bind the single command functions (cut, copy, paste) to the same
actions in accessible actions.

The other problem you have with actions is where do you apply it. Do you
know to apply it only to the document. If Editable text is applied to text
content within the document then you should now where to find the
interface.

Rich


Rich Schwerdtfeger



From:   Pete Brunet p...@a11ysoft.com
To: Alexander Surkov surkov.alexan...@gmail.com,
Cc: IAccessible2 mailing list
accessibility-ia2@lists.linuxfoundation.org
Date:   02/04/2013 07:49 PM
Subject:Re: [Accessibility-ia2] IA2 1.3 ready for review
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org




On 10/10/12 2:07 AM, Alexander Surkov wrote:
  Hi, Jamie. Answering inline.


  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.


I believe there was some talk a while ago about making these
all actions
which can be triggered using the standard action mechanism.
This would
require a way to perform an action given a constant. It is why
the idea of
using negative action indices came up.


  It seems it doesn't answer why we can't turn out the whole
  IAccessibleEditableText interface into actions.
  Btw, I would prefer doAction taking a BSTR rather than negative
  constant. Otherwise we should standardize all possible actions and we
  don't leave a room for the server to introduce non-standard actions.


  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?


  It seems we didn't go with EnumVariant at all but we added maxCount
  'in' argument. Should we have it here as well?
Hi Alex, I assume you are referring to
IAccessible2_2::relationTargetsOfType which along with
IAccessible2::relations and IAccessibleRelation::targerts are the only
methods with a valid max count [in] parameter.  (There are several others
but those methods were coded in error and their max count [in] parameters
are to be ignored.)  IAccessibleHypertext2::hyperlinks doesn't have a max
[in] parameter and Jamie said in a followup note that he's unaware of any
need for one.



  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 :)


I guess a grouping object/container would expose this relation
referring to
all objects it contains. Is this really useful?


  It'd be nice to have examples. Does it applicable to HTML fieldset
  and
  HTML form? Should it include the element connected by node_child_of
  relation if the element is not a descendant?

  Thank you.
  Alex.


  On Wed, Oct 10, 2012 at 3:39 PM, James Teh ja...@nvaccess.org
  wrote:

On 24/09/2012 2:52 PM, Alexander Surkov wrote:


  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.


I believe there was some talk a while ago about making these
all actions
which can be triggered using the standard action mechanism.
This would
require a way to perform an action given a constant. It is why
the idea of

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


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 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=1item/div
div role=treeitem level=2sub 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 = LnodeChildOf;

/** 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

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


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

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

Did you check with Nuance? What appends if replacetext is removed? 

Even if Nuance has not implemented it for say FF has someone approached them? 
We can' t just  be supporting vision impairments.

Sent from my iPad

On Feb 4, 2013, at 9:35 PM, Pete Brunet p...@a11ysoft.com wrote:

 Hi Rich, At this point, since we couldn't find consensus and since this 
 release was supposed to done last Fall and since I was informed that noone 
 has implemented or shown a need for the three clipboard operations, I'm 
 inclined to not hold up the release any further and handle this in a 
 follow-on release if a project comes along that needs clipboard functionality 
 and provides resource to drive the spec toward a well thought out definition 
 of the clipboard methods.
 
 Pete
 
 On 2/4/13 8:51 PM, Richard Schwerdtfeger wrote:
 Hi Pete,
 
 The reason for the editing functions was to allow a voice reco solution to 
 select text, edit it, and perform clipboard operations for the mobility 
 impaired. It is additional work to have a voice reco solution have to go 
 through the additional work of doing the additional keyboard simulations for 
 doing that function. 
 
 So, these are single actions. AccessibleEditableText also allows you to 
 replace text, and set attributes, which takes offsets and replacement 
 text/attributes. Accessible actions are single action functions that don't 
 take parameters. ReplaceText is not the same as pasting from the clipboard. 
 It is really nice to have all the features in the same interface. Note: One 
 could bind the single command functions (cut, copy, paste) to the same 
 actions in accessible actions.
 
 The other problem you have with actions is where do you apply it. Do you 
 know to apply it only to the document. If Editable text is applied to text 
 content within the document then you should now where to find the interface. 
 
 Rich
 
 
 Rich Schwerdtfeger
 
___
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

Whe are relations deprecated? They are used extensively in both FF, Chrome, and 
Symphony.

Rich

Sent from my iPad

On Feb 4, 2013, at 8:32 PM, Pete Brunet p...@a11ysoft.com wrote:

 
 On 10/10/12 1:29 AM, James Teh wrote:
 Hi all, 
 
 Sorry for taking so long. Here is my feedback: 
 
 Accessible2.idl: 
 IAccessible2 has been removed from the Interfaces section. It should still 
 be included. (I see Pete has already acknowledged this.) 
 I'm not sure it makes sense to say the older interfaces (except 
 IAccessibleTable, which has essentially been completely replaced) are 
 deprecated, as the newer ones subclass them.
 I've removed the deprecated text from IAHypertext and IAText.  I think it 
 still make sense to indicate IARelation is deprecated.
 The IAccessible2 interface still contains the modifications relevant to 
 IAccessible2_2. Specifically, the max parameters for extendedStates and 
 localizedExtendedStates have been removed and the new methods attribute, 
 accessibleWithCaret and relationTargetsOfType have been added. I assume this 
 was unintentional in this latest version. This critical, as it will breka 
 binary compatibility.
 Yes, That was unintentional.  I diffed the old and new IAccessible2 and fixed 
 the problems.
 
 
 AccessibleDocument.idl: 
 Regarding IAccessibleDocument::anchorTarget, I wonder whether a relation 
 fits here, which would eliminate the need for this interface. I think this 
 was discussed before, but I can't remember why this idea was dropped. After 
 all, it just returns an accessible.
 Back on 12 Feb 12 you said:
 I feel a relation fits well enough here, but I don't feel strongly enough 
 about it to fight for it if others disagree. I'd pose the question: what 
 makes this so special as to justify a new method? Why is it more special 
 than, say, flowsTo or labelledBy? I guess it doesn't fit relations entirely, 
 as it isn't strictly related so much as state information. If that argument 
 is consensus, fair enough. 
 And I responded:
 Thanks Jamie, It appears there is no strong preference by anyone for any of 
 the various options.  Your observation about state vs relationship is 
 interesting and is enough to motivate me to choose a method over a relation.
 
 AccessibleHypertext2.idl: 
 The comments for the IAccessibleHypertext2 interface say: 
  The %IAccessibleHypertext interface is the main interface to expose 
   hyperlinks in a document, typically a text document... 
 This is a bit confusing, as this documentation is for IAccessibleHypertext2, 
 not IAccessibleHypertext. It should probably just mention that this extends 
 IAccessibleHypertext. 
 The same goes for IAccessibleText2.
 Thanks Jamie, I fixed that.
 
 I'll reply to Alex's feedback separately. 
 
 Thanks, 
 Jamie 
 
 On 21/09/2012 12:22 PM, 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
 
 -- 
 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

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

It appears the relations were moved to the new ia22 interface. Is that why you 
are deprecating the relations interface?

Sent from my iPad

On Feb 4, 2013, at 10:15 PM, Richard Schwerdtfeger sch...@us.ibm.com wrote:

 Whe are relations deprecated? They are used extensively in both FF, Chrome, 
 and Symphony.
 
 Rich
 
 Sent from my iPad
 
 On Feb 4, 2013, at 8:32 PM, Pete Brunet p...@a11ysoft.com wrote:
 
 
 On 10/10/12 1:29 AM, James Teh wrote:
 Hi all, 
 
 Sorry for taking so long. Here is my feedback: 
 
 Accessible2.idl: 
 IAccessible2 has been removed from the Interfaces section. It should still 
 be included. (I see Pete has already acknowledged this.) 
 I'm not sure it makes sense to say the older interfaces (except 
 IAccessibleTable, which has essentially been completely replaced) are 
 deprecated, as the newer ones subclass them.
 I've removed the deprecated text from IAHypertext and IAText.  I think it 
 still make sense to indicate IARelation is deprecated.
 The IAccessible2 interface still contains the modifications relevant to 
 IAccessible2_2. Specifically, the max parameters for extendedStates and 
 localizedExtendedStates have been removed and the new methods attribute, 
 accessibleWithCaret and relationTargetsOfType have been added. I assume 
 this was unintentional in this latest version. This critical, as it will
breka binary compatibility.
 Yes, That was unintentional.  I diffed the old and new IAccessible2 and 
 fixed the problems.
 
 
 AccessibleDocument.idl: 
 Regarding IAccessibleDocument::anchorTarget, I wonder whether a relation 
 fits here, which would eliminate the need for this interface. I think this 
 was discussed before, but I can't remember why this idea was dropped. After 
 all, it just returns an accessible.
 Back on 12 Feb 12 you said:
 I feel a relation fits well enough here, but I don't feel strongly enough 
 about it to fight for it if others disagree. I'd pose the question: what 
 makes this so special as to justify a new method? Why is it more special 
 than, say, flowsTo or labelledBy? I guess it doesn't fit relations entirely, 
 as it isn't strictly related so much as state information. If that 
 argument is consensus, fair enough. 
 And I responded:
 Thanks Jamie, It appears there is no strong preference by anyone for any of 
 the various options.  Your observation about state vs relationship is 
 interesting and is enough to motivate me to choose a method over a relation.
 
 AccessibleHypertext2.idl: 
 The comments for the IAccessibleHypertext2 interface say: 
  The %IAccessibleHypertext interface is the main interface to expose 
   hyperlinks in a document, typically a text document... 
 This is a bit confusing, as this documentation is for 
 IAccessibleHypertext2, not IAccessibleHypertext. It should probably just 
 mention that this extends IAccessibleHypertext.   
 The same goes for IAccessibleText2.
 Thanks Jamie, I fixed that.
 
 I'll reply to Alex's feedback separately. 
 
 Thanks, 
 Jamie 
 
 On 21/09/2012 12:22 PM, 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
 
 -- 
 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

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