Maybe, except that as far as a user is concerned, it is just extra
descriptive text. Certainly, I don't see a point in handling it
separately in NVDA as far as configuration goes. The aria-invalid state
is enough to tell the user that this is an error.
Jamie
On 24/02/2016 10:07 AM, Cynthia Shelly wrote:
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:[email protected]]
Sent: Tuesday, February 23, 2016 3:20 PM
To: James Teh <[email protected]>
Cc: IA2 List <[email protected]>; ARIA Working Group
<[email protected]>
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
[email protected]
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: [email protected]
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
