666544 - presence of html5 required attribute = alert low and alert high states

Status: UNCONFIRMED

(Firefox :: Disability Access, defect)

Description

[steve faulkner]

User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:6.0a2) Gecko/20110618 Firefox/6.0a2
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:6.0a2) Gecko/20110618 Firefox/6.0a2

the presence of the html5 required results in both the alert high and alert low states being present although the form has not been submitted. this translates to the user being told a text field is invalid when it recieves focus

Reproducible: Always

Steps to Reproduce:
1.go to http://www.html5accessibility.com/tests/form-describedby.html
2. focus on the first input (has a required attribute)
3. use an inspect tool to see 
"State:	focused,focusable,alert low,alert high"



Actual Results:  
text input (name) with required attribute has "State:	focused,focusable,alert low,alert high"

Expected Results:  
before user attempts to submit: text input with required attribute has "State:	focused,focusable,alert low"
after user attempts to submit:
text input with required attribute has "State:	focused,focusable,alert low,alert high"

note: text input (age) has aria-required instead, it only has the alert low state.

Comment 1

[Marco Zehe (:MarcoZ)]

(In reply to comment #0)
> 1.go to http://www.html5accessibility.com/tests/form-describedby.html
> 2. focus on the first input (has a required attribute)
> 3. use an inspect tool to see 
> "State:	focused,focusable,alert low,alert high"

This is correct and so set by the engine's HTML5 validation, to which the a11y APIs just react. As soon as you type a letter into the box, the "invalid" state clears. As soon as you remove that letter, the "invalid" state returns. This is not just a11y APIs, but if you query the element's validity via JS at these two points, you'll get these answers back, too.

And since an empty required field is not valid, this is not a bug.

> note: text input (age) has aria-required instead, it only has the alert low
> state.

Right, since the ARIA-invalid state must be set via JS, and thus one has to implement their own validation in JS to accomplish the same.

Comment 2

[steve faulkner]

(In reply to comment #1)
> (In reply to comment #0)
> > 1.go to http://www.html5accessibility.com/tests/form-describedby.html
> > 2. focus on the first input (has a required attribute)
> > 3. use an inspect tool to see 
> > "State:	focused,focusable,alert low,alert high"
> 
> This is correct and so set by the engine's HTML5 validation, to which the
> a11y APIs just react. As soon as you type a letter into the box, the
> "invalid" state clears. As soon as you remove that letter, the "invalid"
> state returns. This is not just a11y APIs, but if you query the element's
> validity via JS at these two points, you'll get these answers back, too.
> 
> And since an empty required field is not valid, this is not a bug.
> 
> > note: text input (age) has aria-required instead, it only has the alert low
> > state.
> 
> Right, since the ARIA-invalid state must be set via JS, and thus one has to
> implement their own validation in JS to accomplish the same.

seems odd, since sighted users do not get told there is an issue until the user attempts to submit the form.

Comment 3

[steve faulkner]

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > 1.go to http://www.html5accessibility.com/tests/form-describedby.html
> > > 2. focus on the first input (has a required attribute)
> > > 3. use an inspect tool to see 
> > > "State:	focused,focusable,alert low,alert high"
> > 
> > This is correct and so set by the engine's HTML5 validation, to which the
> > a11y APIs just react. As soon as you type a letter into the box, the
> > "invalid" state clears. As soon as you remove that letter, the "invalid"
> > state returns. This is not just a11y APIs, but if you query the element's
> > validity via JS at these two points, you'll get these answers back, too.
> > 
> > And since an empty required field is not valid, this is not a bug.
> > 
> > > note: text input (age) has aria-required instead, it only has the alert low
> > > state.
> > 
> > Right, since the ARIA-invalid state must be set via JS, and thus one has to
> > implement their own validation in JS to accomplish the same.
> 
> seems odd, since sighted users do not get told there is an issue until the
> user attempts to submit the form.

actually a red border appears around a text field with a required attribute if the user types something into the text field, then removes it, but not if the user tabs through it without entering anything.An error message is shown after the user attempts to submit the form.

Comment 4

[steve faulkner]

(In reply to comment #1)
> (In reply to comment #0)
> > 1.go to http://www.html5accessibility.com/tests/form-describedby.html
> > 2. focus on the first input (has a required attribute)
> > 3. use an inspect tool to see 
> > "State:	focused,focusable,alert low,alert high"
> 
> This is correct and so set by the engine's HTML5 validation, to which the
> a11y APIs just react. As soon as you type a letter into the box, the
> "invalid" state clears. As soon as you remove that letter, the "invalid"
> state returns. This is not just a11y APIs, but if you query the element's
> validity via JS at these two points, you'll get these answers back, too.
> 
> And since an empty required field is not valid, this is not a bug.
> 
> > note: text input (age) has aria-required instead, it only has the alert low
> > state.
> 
> Right, since the ARIA-invalid state must be set via JS, and thus one has to
> implement their own validation in JS to accomplish the same.

Do you think we should be advising authors to also set aria-invalid=true on text fields that are required so the same states (alert low,alert high) are conveyed and the user gets the same message  aswith required?

Comment 5

[Rich Schwerdtfeger]

The field should not be marked invalid unless the field is set with an invalid value or the user has actually entered an invalid value. 

ALL users need to know that something was done incorrectly and not just AT users.

Comment 6

[alexander :surkov (:asurkov)]

alert-low and alert-high MSAA states are used for required and invalid control states accordingly, that is a hack for old screen readers introduced before IA2. So is there anything we should fix here? wontfix?

Comment 7

[Adam Rodenbeck]

If the field has never been focused, the user is just discovering the fields requiredness, it is at that point not invalid until the field is blurred.