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
rel
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
+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: Wou
I agree with James.
In my experience there is very little difference between an error
message and a description.
Both need a programmatic relation to the object that caused them
(because both need to be automatically announced as user focus moves
to the associated object).
aria-describedby already
>-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?
>
>-Original Message-
>From: Joanmarie Diggs [mailto:jdi...@igalia.com]
>Sent: Monday, April 11, 2016 2:23 PM
>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 t
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
