RE: Using Aria-Invalid to Indicate An Error Field - for Apr 10 call

Sailesh, let me repeat what I think you are saying is a clear case to use
aria-invalid.

1. A situation where fields are indicated at the top of a form in error
and then indicated visually in a non-color way by each field e.g. bolding.
In this case use of aria-invalid would provide a semantic equivalent for
the bolding.

Jonathan

-----Original Message-----
From: Sailesh Panchang [mailto:sailesh.panchang@deque.com]
Sent: Thursday, April 10, 2014 10:09 AM
To: Andrew Kirkpatrick; w3c-wai-gl@w3.org
Cc: Loretta Guarino Reid; James Nurthen
Subject: Re: Using Aria-Invalid to Indicate An Error Field - for Apr 10
call

On 4/9/14, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 1. ARIA1  (about aria-describedby for UI elements) essentially covers
> a variety of situations for programmatically associating additional /
> related text for a UI control. So error text too is covered, though
> this is not stated explicitly and an example is not included. (I could
> take this as an action item)
>
> I think I agree that this should be sufficient (using describedby to
> convey the information about error state) - I worry that the
> information seems to be lagging behind in time when using some tools,
> but agree that this is a user agent issue (and then gets us into
> accessibility support questions).  I say that I think I agree because
> part of me thinks that perhaps the aria-invalid is special and needs
> to be flagged every time a control is not correctly filled - this may
> not do much different today, but perhaps screen readers will enable
> users to quickly visit invalid controls, and using aria-invalid would
enable that, but aria-describedby  wouldn't?
Sailesh: When screen-readers / magnifiers etc. catch on and implement such
navigation, the technique will need revisiting.

> 2. By Reading the specs for aria-invalid in its entirety, I can only
> conclude that  it is meant for flagging a field that has failed
> validation after the form (or control) has been validated.
> Other users have no such indication for an empty field before form
> submission.
> An empty field , say 4-digit PIN,  if not required with
> aria-invalid=true is very misleading for an AT user.
> The specs say authors may prevent form submission based on
> aria-invalid=true.  That will be a problem if the field is not
> required and is empty.
>
> I'm not sure what the problem here is...
>
Sailesh:During the call on Apr 8, there was a comment that the specs say
'do not turn aria-invalid only for required fields before form
submission'. My above response addresses that.
> 3. Several other techniques including ARIA1 are sufficient by
> themselves (without aria-
> invalid) for SC 3.3.1.
> In those situations, adding  aria-invalid is superfluous from a
> compliance standpoint.
> Maybe it is bbest practice to add aria-invalid in some situations but
> that's moot.
> Note: In complying with SC 3.3.3 (level AA) if the programmatically
> associated text for the fix also identifies the field, then this text
> satisfies SC 3.3.1 (A)too and  aria-invalid is redundant.
>
> Again, I think I agree, and my thinking is evolving as I look into
> this more.  I'm thinking that maybe there are multiple ways to meet
> 3.3.1 but perhaps a control that is in an error state that doesn't
> convey that state would fail 4.1.2? It seems like a page can pass
> 3.3.1 by identifying the errors, but the user interface control needs
> to correctly represent itself, and that is what 4.1.2 requires.
>
Sailesh: Visually, "field in error" is  not a general or universal state
like "checked" or "selected" and SC 4.1.2 may not apply.
Aria-invalid only works as a state for certain AT users. The technique's
description clarifies the objective.
> 4. In example #2,  the error text "Input data missing" is associated
> using
> aria- describedby.
> As a user I think if aria-invalid is also present in this situation,
> it is a nuisance and does not add value. Without it I get the same
> info as any other user.
>
> Can you clarify how it is a nuisance?  What does it read in both ways?
> Sailesh: The programmatically associated label and error text for the
control are read and that info is complete. So when it also reads "invalid
entry", it is superfluous and an unnecessary duplication of sorts. On the
other hand if only 2 digits are entered for the 4-digit PIN, the field's
label + invalid-entry completely identify the field and the problem.
> 5. If an error icon is present,  it should have suitable alt and be
> associated with the field.
> See example at
> http://mars.dequecloud.com/demo/form-alert2.htm
>
> sure.
>
> 6. If a CSS error icon is used, it fails SC 1.1.1 (See F3). Yet, if it
> is acceptable, one may use aria-invalid to help screen-reader users
> in this situation.
>
> I think you mean "if a CSS error icon is used on its own if fails SC
> 1.1.1".
>
Sailesh: Thanks Andrew for correcting that.
> 7. How user agents / AT will handle aria-invalid in the future is not
> relevant here now.
> The technique can be amended  if needed when that happens.
>
> So the question is when is aria-invalid by itself sufficient to meet
> SC 3.3.1.
> The technique under discussion tries to address this. Sure it can be
> improved  to make it more lucid. Some who answered the survey approved
> the technique and some suggested 'accept with changes'.
>
> So maybe it isn't sufficient to meet 3.3.1.  In your
> http://mars.dequecloud.com/demo/Form-AriaLiveWithJQ.htm example I
> think that the reason that it would meet 3.3.1 is because invalid
> states that the field is in error and the error is described in text
> via the label which indicates that the field is required.  Loretta and
James?
>
Sailesh: The example in fact demonstrates how it is sufficient for SC
3.3.1. As documented in the technique description and under examples, the
label conveys purpose of field including expected data format. So the
label +aria-invalid precisely identifieds the field for the AT user in
addition to the general h2 text for failed submission. So the example
demonstrates when it is appropriate to use the attribute effectively.

Received on Friday, 11 April 2014 18:37:57 UTC