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

2016-04-14 Thread Birkir Gunnarsson
Same thing I proposed in my earlier email.


-Original Message-
From: Matt King [mailto:a11ythin...@gmail.com] 
Sent: Thursday, April 14, 2016 11:20 AM
To: 'Joseph Scheuhammer' <cl...@alum.mit.edu>; 'Joanmarie Diggs' 
<jdi...@igalia.com>; 'James Teh' <ja...@nvaccess.org>
Cc: 'IA2 List' <accessibility-...@lists.linux-foundation.org>; 'ARIA Working 
Group' <public-a...@w3.org>
Subject: RE: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

Joseph, based on what you wrote here, it sounds like error messages are a type 
of element rather than a relationship.

A field could be described by multiple elements, and one of those elements 
could be an error message and others could be arbitrary elements that somehow 
describe the field.

Makes me wonder if we should have an errormessage role and then have the 
element with role errormessage be related to a field via aria-edescribedby. 

Matt


-Original Message-
From: Joseph Scheuhammer [mailto:cl...@alum.mit.edu] 
Sent: Wednesday, April 13, 2016 2:01 PM
To: Matt King <a11ythin...@gmail.com>; 'Joanmarie Diggs' <jdi...@igalia.com>; 
'James Teh' <ja...@nvaccess.org>
Cc: 'IA2 List' <accessibility-...@lists.linux-foundation.org>; 'ARIA Working 
Group' <public-a...@w3.org>
Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

On 2016-04-13 11:46 AM, Matt King wrote:
> When aria-errormessage was first discussed, my understanding was that the 
> purpose is to distinguish an error message from a description so that 
> assistive technologies would have the option to give it special treatment. 
>
> Is there more to it than that?

Aria-errormessage is tied to aria-invalid.  The error message is relevant only 
when the input is invalid.  In contrast, descriptions have no specific 
dependency on validity.

Based on that, the error message is presented only when the input is invalid.  
For a sighted user, the error message is not rendered unless or until the user 
has input invalid information.  At that point the error message is shown near 
or "attached" to the invalid input.  If the user corrects the input, the error 
message vanishes, thereby providing reinforcement that the error has been 
corrected.  On the other hand, the description is presented on demand -- for 
example, as a tooltip when the user mouses over the control.  A corollary is 
that the error message conveys a sense of urgency or obligation -- something 
needs to be fixed
-- whereas the description does not.

--
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-04-14 Thread Matt King
Joseph, based on what you wrote here, it sounds like error messages are a type 
of element rather than a relationship.

A field could be described by multiple elements, and one of those elements 
could be an error message and others could be arbitrary elements that somehow 
describe the field.

Makes me wonder if we should have an errormessage role and then have the 
element with role errormessage be related to a field via aria-edescribedby. 

Matt


-Original Message-
From: Joseph Scheuhammer [mailto:cl...@alum.mit.edu] 
Sent: Wednesday, April 13, 2016 2:01 PM
To: Matt King <a11ythin...@gmail.com>; 'Joanmarie Diggs' <jdi...@igalia.com>; 
'James Teh' <ja...@nvaccess.org>
Cc: 'IA2 List' <accessibility-...@lists.linux-foundation.org>; 'ARIA Working 
Group' <public-a...@w3.org>
Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

On 2016-04-13 11:46 AM, Matt King wrote:
> When aria-errormessage was first discussed, my understanding was that the 
> purpose is to distinguish an error message from a description so that 
> assistive technologies would have the option to give it special treatment. 
>
> Is there more to it than that?

Aria-errormessage is tied to aria-invalid.  The error message is relevant only 
when the input is invalid.  In contrast, descriptions have no specific 
dependency on validity.

Based on that, the error message is presented only when the input is invalid.  
For a sighted user, the error message is not rendered unless or until the user 
has input invalid information.  At that point the error message is shown near 
or "attached" to the invalid input.  If the user corrects the input, the error 
message vanishes, thereby providing reinforcement that the error has been 
corrected.  On the other hand, the description is presented on demand -- for 
example, as a tooltip when the user mouses over the control.  A corollary is 
that the error message conveys a sense of urgency or obligation -- something 
needs to be fixed
-- whereas the description does not.

--
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-04-14 Thread Matt King
It seems like we should revisit the purpose of adding aria-errormessage and 
then ask ourselves whether or not any of these mapping proposals could achieve 
it. If not, perhaps we should give ourselves more time (ARIA 2.0) to identify 
the ideal path to the desired end.

When aria-errormessage was first discussed, my understanding was that the 
purpose is to distinguish an error message from a description so that assistive 
technologies would have the option to give it special treatment. 

Is there more to it than that?

The description of aria-errormessage does not contain any normative statements 
or suggestions that apply to assistive technologies. Are there any assumptions 
about what assistive technologies might do? Judging from this thread, one 
assumption I could derive is that assistive technologies would prioritize 
speaking error messages over descriptions.

All the user experience behaviors described in the aria-errormessage text are 
easily achieved with aria-describedby. If the primary desire was to get 
assistive technologies to prioritize error messages over descriptions, then we 
could as effectively achieve that objective with authoring practices.

It is worth noting that error messages often make field descriptions 
unnecessary. For example, a field description might be "Please enter  a date in 
/mm/dd format." And a corresponding error message may be "Please provide 
the date in yy/mm/dd format." If the error message and description are not 
redundant, then it seems reasonable to ask authors to provide the ID of the 
error message first followed by the ID of the description in the 
aria-describedby property.

Matt

-Original Message-
From: Joanmarie Diggs [mailto:jdi...@igalia.com] 
Sent: Tuesday, April 12, 2016 6:48 AM
To: James Teh <ja...@nvaccess.org>
Cc: IA2 List <accessibility-...@lists.linux-foundation.org>; ARIA Working Group 
<public-a...@w3.org>
Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

Hey Jamie, all.

FWIW, I had proposed exposing it via the existing description-related 
relationships plus an object attribute:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002001.html

And I indicated that I didn't have strong feelings either way about whether or 
not the description was included as part of the alternative text calculation:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002011.html

In other words, I personally do not see it as fundamentally different.
Mind you, knowing that something is an error message might prove handy, hence 
my suggestion of an object attribute on the element that contains the error 
message.

I don't like to take performance hits any more than you do. If you feel like 
this approach will result in a performance hit, then we should rethink things.

All of that said Where I myself am is that we need to map this new ARIA 
feature. And we're trying to get ARIA 1.1 locked down. Given that, along with 
the fact that it is seen as desirable that we keep our platforms aligned 
whenever possible, what I want is *some* mapping. :) I tossed out the new 
relation type because I got the impression that my original proposal was not 
seen as acceptable, and because you suggested a new relation type:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002019.html

--joanie

On 04/11/2016 08:18 PM, James Teh wrote:
> On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:
>> If there's sufficient belief that errormessage is inherently 
>> different
> FWIW, I don't believe this personally--I've not seen a single argument 
> that I wasn't able to defeat--but it seems like this decision has 
> already been made in ARIA. Certainly, NVDA will just be merging it 
> into description internally. What I will say is if ARIA views it as 
> being fundamentally different (as misguided as I think this is), it 
> seems problematic if the accessibility APIs merge it.
> 
> That said, one nasty problem with an additional API or relation is 
> that we have to call/crawl that additional thing for *every* 
> accessible just to find out whether it has an error message. That's 
> kinda ugly from a performance perspective; we hurt performance 
> everywhere just to support aria-errormessage. Still, I guess this is 
> the best we can have given the majority opinion that it is so fundamentally 
> different.
> 
> I'm happy with the names you proposed.
> 
> Jamie
> 



___
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-04-13 Thread James Teh
1. If error message were mapped to description in a11y APIs, the user 
agent can choose to expose it first and only when aria-invalid is true.
2. aria-invalid communicates the state of "urgency". For example, NVDA 
says "invalid entry". I don't think screen readers should provide an 
additional indication for an error message, as that would be redundant, 
but that's an implementation detail, not a spec detail.
3. It occurred to me that one possible annoyance with error message 
being mapped to description is that if both were present, a change in 
one might cause both to be read.
4. We might be able to mitigate the performance concern using the 
invalid state; i.e. we only need to check for error message if invalid 
is set. Joanie, thoughts?


Jamie

On 14/04/2016 7:01 AM, Joseph Scheuhammer wrote:

On 2016-04-13 11:46 AM, Matt King wrote:

When aria-errormessage was first discussed, my understanding was that the 
purpose is to distinguish an error message from a description so that assistive 
technologies would have the option to give it special treatment.

Is there more to it than that?

Aria-errormessage is tied to aria-invalid.  The error message is
relevant only when the input is invalid.  In contrast, descriptions have
no specific dependency on validity.

Based on that, the error message is presented only when the input is
invalid.  For a sighted user, the error message is not rendered unless
or until the user has input invalid information.  At that point the
error message is shown near or "attached" to the invalid input.  If the
user corrects the input, the error message vanishes, thereby providing
reinforcement that the error has been corrected.  On the other hand, the
description is presented on demand -- for example, as a tooltip when the
user mouses over the control.  A corollary is that the error message
conveys a sense of urgency or obligation -- something needs to be fixed
-- whereas the description does not.



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


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

2016-04-13 Thread Joseph Scheuhammer
On 2016-04-13 11:46 AM, Matt King wrote:
> When aria-errormessage was first discussed, my understanding was that the 
> purpose is to distinguish an error message from a description so that 
> assistive technologies would have the option to give it special treatment. 
>
> Is there more to it than that?

Aria-errormessage is tied to aria-invalid.  The error message is
relevant only when the input is invalid.  In contrast, descriptions have
no specific dependency on validity.

Based on that, the error message is presented only when the input is
invalid.  For a sighted user, the error message is not rendered unless
or until the user has input invalid information.  At that point the
error message is shown near or "attached" to the invalid input.  If the
user corrects the input, the error message vanishes, thereby providing
reinforcement that the error has been corrected.  On the other hand, the
description is presented on demand -- for example, as a tooltip when the
user mouses over the control.  A corollary is that the error message
conveys a sense of urgency or obligation -- something needs to be fixed
-- whereas the description does not.

-- 
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-04-12 Thread James Teh

Hey Joanie, all.

Let me try to summarise this mess from my perspective.

1. When you made your initial proposal (description relationships plus 
object attribute), I agreed. You clearly don't see them as fundamentally 
different.
2. However, I noted that if it's being exposed via description 
relationships, it follows that it should also be exposed as part of the 
calculated description text.
3. At this point, it became clear that several people (most notably 
Rich) believe that error messages are fundamentally different to 
descriptions and were thus against (2).

4. If we aren't going to do (2), IMO, (1) doesn't make sense.
5. It's also clear that there is significant disagreement amongst spec 
people as to whether error messages are fundamentally different or not; 
(1) versus (3). That's a major alarm bell for me. IMO, if ARIA and 
accessibility API disagree on this, the whole idea is broken and needs 
to be reconsidered from the ground up.
6. My suggested path forward from here is probably to do (1) and (2), 
despite the objections in (3). We can always change that decision later, 
since this approach is backwards compatible.


Thanks,
Jamie

On 12/04/2016 11:47 PM, Joanmarie Diggs wrote:

Hey Jamie, all.

FWIW, I had proposed exposing it via the existing description-related
relationships plus an object attribute:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002001.html

And I indicated that I didn't have strong feelings either way about
whether or not the description was included as part of the alternative
text calculation:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002011.html

In other words, I personally do not see it as fundamentally different.
Mind you, knowing that something is an error message might prove handy,
hence my suggestion of an object attribute on the element that contains
the error message.

I don't like to take performance hits any more than you do. If you feel
like this approach will result in a performance hit, then we should
rethink things.

All of that said Where I myself am is that we need to map this new
ARIA feature. And we're trying to get ARIA 1.1 locked down. Given that,
along with the fact that it is seen as desirable that we keep our
platforms aligned whenever possible, what I want is *some* mapping. :) I
tossed out the new relation type because I got the impression that my
original proposal was not seen as acceptable, and because you suggested
a new relation type:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002019.html

--joanie

On 04/11/2016 08:18 PM, James Teh wrote:

On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:

If there's sufficient belief that errormessage is inherently different

FWIW, I don't believe this personally--I've not seen a single argument
that I wasn't able to defeat--but it seems like this decision has
already been made in ARIA. Certainly, NVDA will just be merging it into
description internally. What I will say is if ARIA views it as being
fundamentally different (as misguided as I think this is), it seems
problematic if the accessibility APIs merge it.

That said, one nasty problem with an additional API or relation is that
we have to call/crawl that additional thing for *every* accessible just
to find out whether it has an error message. That's kinda ugly from a
performance perspective; we hurt performance everywhere just to support
aria-errormessage. Still, I guess this is the best we can have given the
majority opinion that it is so fundamentally different.

I'm happy with the names you proposed.

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


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

2016-04-12 Thread Rich Schwerdtfeger
Both are are definitely longer strings of text. However, the use case is such 
that for form elements that have description about what the purpose is of the 
form element and which are also marked  as aria-invalid=“true” you then need to 
find an error message which is different. 

Forms often have multiple invalid elements and thus multiple error messages. 
These error messages are often live regions as well, and must be visible to be 
mapped as you would need to navigate to them given that they may have links to 
information help the user in determining how to read them. 

Rich


Rich Schwerdtfeger




> On Apr 12, 2016, at 5:03 AM, Birkir Gunnarsson  
> wrote:
> 
> 

___
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-04-12 Thread Rich Schwerdtfeger
+1 That is clean. 

Rich


Rich Schwerdtfeger




> On Apr 11, 2016, at 1:22 PM, Joanmarie Diggs  wrote:
> 
> Hey again.
> 
> New proposal for the types:
> 
> ERROR_MESSAGE: Would go on the input which is invalid and point to the
> element with the statement of what is wrong.
> 
> ERROR_SOURCE: Would go on the element which contains the statement of
> what is wrong and point to the input which is invalid.
> 
> --joanie
> 
> On 04/11/2016 01:26 PM, Joanmarie Diggs wrote:
>> Hey Jamie, all.
>> 
>> I don't believe we have a conclusion on this. So resuming the conversation.
>> 
>> If there's sufficient belief that errormessage is inherently different
>> and that new API is called for, what about a new relation type?
>> Personally, I am not jazzed by yet another relation type. But it is easy
>> enough to add. We could add ERROR_FOR (or ERROR_MESSAGE_FOR) and ...
>> what would the reciprocal relation be called?
>> 
>> --joanie
>> 
>> On 03/01/2016 06:33 PM, James Teh wrote:
>> 
>>> Everyone else is saying that errormessage is inherently different to
>>> description. If that really is how it's meant to be according to the
>>> ARIA spec (I disagree, but that's not relevant here), then mapping it to
>>> description (even with an attribute) is a big hack. You can't have it
>>> both ways; it's either just a specialisation of description or it's not.
>>> Several people now say it's not the former, so it must be the latter.
>>> And if it *is* the former, then it should be included as part of the
>>> description text as well.
>>> 
>>> FWIW, I don't like this whle thing at all, but it seems wrong to me that
>>> the ARIA spec says it's not at all a description and the a11y specs say
>>> it is. Personally, I think the ARIA spec *should* treat it as just an
>>> extension of description, but I've already made that point and it
>>> doesn't seem popular.
>>> 
>>> Jamie
>>> 
>> 
>> ___
>> 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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-04-12 Thread White, Jason J


>-Original Message-
>From: Joanmarie Diggs [mailto:jdi...@igalia.com]


>I don't believe we have a conclusion on this. So resuming the conversation.
>
>If there's sufficient belief that errormessage is inherently different and that
>new API is called for, what about a new relation type?
>Personally, I am not jazzed by yet another relation type. But it is easy enough
>to add. We could add ERROR_FOR (or ERROR_MESSAGE_FOR) and ...
>what would the reciprocal relation be called?

Perhaps ERROR_CAUSED_BY, or ERROR_RESULTING_FROM, or just ERROR_FROM (I'm 
slightly in favor of the last). This would be placed on the widget that 
triggered the error, presumably, pointing to the element containing the error 
message.




This e-mail and any files transmitted with it may contain privileged or 
confidential information. It is solely for use by the individual for whom it is 
intended, even if addressed incorrectly. If you received this e-mail in error, 
please notify the sender; do not disclose, copy, distribute, or take any action 
in reliance on the contents of this information; and delete it from your 
system. Any other use of this e-mail is prohibited.


Thank you for your compliance.


___
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-04-12 Thread Joanmarie Diggs
Hey Jamie, all.

FWIW, I had proposed exposing it via the existing description-related
relationships plus an object attribute:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002001.html

And I indicated that I didn't have strong feelings either way about
whether or not the description was included as part of the alternative
text calculation:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002011.html

In other words, I personally do not see it as fundamentally different.
Mind you, knowing that something is an error message might prove handy,
hence my suggestion of an object attribute on the element that contains
the error message.

I don't like to take performance hits any more than you do. If you feel
like this approach will result in a performance hit, then we should
rethink things.

All of that said Where I myself am is that we need to map this new
ARIA feature. And we're trying to get ARIA 1.1 locked down. Given that,
along with the fact that it is seen as desirable that we keep our
platforms aligned whenever possible, what I want is *some* mapping. :) I
tossed out the new relation type because I got the impression that my
original proposal was not seen as acceptable, and because you suggested
a new relation type:
https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-February/002019.html

--joanie

On 04/11/2016 08:18 PM, James Teh wrote:
> On 12/04/2016 3:26 AM, Joanmarie Diggs wrote:
>> If there's sufficient belief that errormessage is inherently different
> FWIW, I don't believe this personally--I've not seen a single argument
> that I wasn't able to defeat--but it seems like this decision has
> already been made in ARIA. Certainly, NVDA will just be merging it into
> description internally. What I will say is if ARIA views it as being
> fundamentally different (as misguided as I think this is), it seems
> problematic if the accessibility APIs merge it.
> 
> That said, one nasty problem with an additional API or relation is that
> we have to call/crawl that additional thing for *every* accessible just
> to find out whether it has an error message. That's kinda ugly from a
> performance perspective; we hurt performance everywhere just to support
> aria-errormessage. Still, I guess this is the best we can have given the
> majority opinion that it is so fundamentally different.
> 
> I'm happy with the names you proposed.
> 
> Jamie
> 

___
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-04-11 Thread Joanmarie Diggs
Hey again.

New proposal for the types:

ERROR_MESSAGE: Would go on the input which is invalid and point to the
element with the statement of what is wrong.

ERROR_SOURCE: Would go on the element which contains the statement of
what is wrong and point to the input which is invalid.

--joanie

On 04/11/2016 01:26 PM, Joanmarie Diggs wrote:
> Hey Jamie, all.
> 
> I don't believe we have a conclusion on this. So resuming the conversation.
> 
> If there's sufficient belief that errormessage is inherently different
> and that new API is called for, what about a new relation type?
> Personally, I am not jazzed by yet another relation type. But it is easy
> enough to add. We could add ERROR_FOR (or ERROR_MESSAGE_FOR) and ...
> what would the reciprocal relation be called?
> 
> --joanie
> 
> On 03/01/2016 06:33 PM, James Teh wrote:
> 
>> Everyone else is saying that errormessage is inherently different to
>> description. If that really is how it's meant to be according to the
>> ARIA spec (I disagree, but that's not relevant here), then mapping it to
>> description (even with an attribute) is a big hack. You can't have it
>> both ways; it's either just a specialisation of description or it's not.
>> Several people now say it's not the former, so it must be the latter.
>> And if it *is* the former, then it should be included as part of the
>> description text as well.
>>
>> FWIW, I don't like this whle thing at all, but it seems wrong to me that
>> the ARIA spec says it's not at all a description and the a11y specs say
>> it is. Personally, I think the ARIA spec *should* treat it as just an
>> extension of description, but I've already made that point and it
>> doesn't seem popular.
>>
>> Jamie
>>
> 
> ___
> 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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-03-01 Thread James Teh

On 2/03/2016 12:13 AM, Joanmarie Diggs wrote:

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.

Really? Why can't we map it via described-by/description-for and then
use an object attribute to check if the descriptive element is an object
attribute?
Everyone else is saying that errormessage is inherently different to 
description. If that really is how it's meant to be according to the 
ARIA spec (I disagree, but that's not relevant here), then mapping it to 
description (even with an attribute) is a big hack. You can't have it 
both ways; it's either just a specialisation of description or it's not. 
Several people now say it's not the former, so it must be the latter. 
And if it *is* the former, then it should be included as part of the 
description text as well.


FWIW, I don't like this whle thing at all, but it seems wrong to me that 
the ARIA spec says it's not at all a description and the a11y specs say 
it is. Personally, I think the ARIA spec *should* treat it as just an 
extension of description, but I've already made that point and it 
doesn't seem popular.


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


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

2016-03-01 Thread Joanmarie Diggs
Hey Jamie.

On 02/24/2016 06:14 PM, James Teh wrote:

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

Really? Why can't we map it via described-by/description-for and then
use an object attribute to check if the descriptive element is an object
attribute?

As for a new event, getting the same thing we get when an alert or
doorhanger is showing would be nice. I forget what event that is for you
-- just that whatever it is, I don't have it on my platform. For me it
would be object:state-changed:showing.

> If it's really such a new and separate
> thing, we don't have to worry about existing AT not getting the
> benefit.

Is that why you are proposing a new relationship?

--joanie


___
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-25 Thread Cynthia Shelly
I would prefer not to include it in name and description calculation. Too many 
things are getting added to the description, and it makes for a messy user 
experience.

-Original Message-
From: Joanmarie Diggs [mailto:jdi...@igalia.com] 
Sent: Tuesday, February 23, 2016 3:20 PM
To: James Teh <ja...@nvaccess.org>
Cc: IA2 List <accessibility-...@lists.linux-foundation.org>; ARIA Working Group 
<public-a...@w3.org>
Subject: Re: [Accessibility-ia2] Mapping of aria-errormessage for ATK/AT-SPI2 
and IA2

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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-02-24 Thread James Teh
The same could apply to descriptions (e.g. a description could include a link 
to more info about how to fill in the field), but that's never been a factor 
before. Also, even if you believe this is more likely with errormessage for 
some reason, I'm guessing you still want AT to report the message when it 
appears and/or the control gets focus, in which case it can only be rendered as 
a string anyway.

Sent from a mobile device

> On 25 Feb 2016, at 9:33 AM, Richard Schwerdtfeger  
> wrote:
> 
> 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] 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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-02-24 Thread Joseph Scheuhammer
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-23 Thread Joanmarie Diggs
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] Mapping of aria-errormessage for ATK/AT-SPI2 and IA2

2016-02-23 Thread Joanmarie Diggs
On 02/23/2016 03:02 PM, Joseph Scheuhammer wrote:
> On 2016-02-23 2:42 PM, Joanmarie Diggs wrote:
>> 4. The object attribute is needed to identify which target (if any)
>> is an error message.
> 
> Point of clarification:  do you mean, that the object attribute is
> needed to qualify the target as an error-message.

Yes.

> Also, can you reference an example of such a use in ATK/AT-SPI, where
> there are multiple described-by/description-for relationships in the
> a11y tree?   I just want to see what the tree looks like.

If need be I can do one up in Gtk+ as I don't think there's anything in
ARIA that explicitly calls for there to be multiple
described-by/description-for relations.

That said, the tree would look just like it always does. The presence or
absence of a relationship changes nothing wrt the hierarchy. [*] If you
were using Accerciser, you'd see a more than one item in the list of
Relations in the Interface Viewer. That's it.

--joanie

[*] The exception being if an implementation were to change parent-child
connections due to something like aria-owns.

___
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-23 Thread Joseph Scheuhammer

On 2016-02-23 2:42 PM, Joanmarie Diggs wrote:

4. The object attribute is needed to identify which target (if any)
is an error message.


Point of clarification:  do you mean, that the object attribute is 
needed to qualify the target as an error-message.


Also, can you reference an example of such a use in ATK/AT-SPI, where 
there are multiple described-by/description-for relationships in the 
a11y tree?   I just want to see what the tree looks like.


Thanks.

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