[ngAria] aria-invalid applied too soon for ngModel

[kschaefe]

ngAria is always setting "aria-invalid" to true or false. The attribute should only be set once the ngModelController.$validators || ngModelController.$asyncValidators have run at least one time.

From aria-invalid definition:

However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.

Although the spec says SHOULD NOT making the current ngAria usage legal, it is not the preferred approach.

[tyleralmond]

Is there any plans to fix this?

[Narretz]

@tyleralmond Not yet. Do you want to take a shot at this?

[chine]

In order to satisfy the SHOULD NOT directive of the spec, would it not be sufficient to just not change the watch value until scope.form.$submitted is also true? Like so:
scope.$watch(function ngAriaInvalidWatch() { return scope.form.$submitted && ngModel.$invalid; }?

Short of that, to prevent aria-invalid from being set to true prematurely perhaps consult ngModel.$pristine in order to inform its value?

Edit: Oy, my last sentence was atrocious.

[manish2535]

My personal opinion is aria-invalid should always be added to any required input field right from the start. The only difference is I would have its value set to "false" initially and then set to true once the form is submitted and if the element is invalid. Something like this:

aria-invalid="{{activateEmailForm.$submitted && activateEmailForm.Email.$invalid ? true : false}}"

The main reason having this attr present right from the start is to prevent the Screen Readers from announcing "Invalid Entry" when a required element is focused. More info here [http://usability.com.au/2013/05/accessible-forms-2-required-fields-and-extra-information/].

[kschaefe]

Hmm, perhaps one should not mix HTML5 required and ARIA attributes. That seems to be the root trouble from what I discern from the post.