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 Thursday, 10 April 2014 14:09:29 UTC