706816 - Make HTML constraints validation message accessible via AccDescription

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Situation:
If an HTML input, textarea, select or button has a validation rule/pattern, is required, or is of a certain type, and if the validation is not given (e. g. an e-mail is not entered correctly), a validation message is provided in two ways:
1. On hovering the mouse over the given form element.
2. On attempting to submit the form and the form is not set to not auto-validate. In this instance, an alert is generated and focus is set to the offending form element.

In both cases, this form element is already marked as invalid via Accessible States.

While instance 2 works very well for screen reader users once the user submits the form, instance 1 is totally inaccessible. Most screen readers are set to not read tool tips automatically, which is a good thing because blind users tend to position the mouse randomly, and the so generated tool tip verbiage is distracting.

Therefore, I have the following proposal:

If the form field has a validation message, prepend it to whatever other info there might be for the AccDescription. This validation message, if any, should come before anything else, since it is a message that requires immediate attention. Upon reading name, type, description and content of the form field, this info will automatically be read as part of the AccDescription and alert the user similar to a mouse user being alerted immediately when they hover the mouse over an invalid form element. This would not require any change to screen reader settings on the user's part, but would give those users the same benefits as a mouse user.

Note that if a form field validates, e. g. the e-mail address or URL is correct, a required field is not empty etc., the validationMessage will be empty.

Thoughts?

Comment 1

[alexander :surkov (:asurkov)]

Marco, could you upload testcase to play with it?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

I'm wondering if there is a more general thing we can do with tooltips.

Comment 3

[Marco Zehe (:MarcoZ)]

Attachment: Testcase

This file shows the different types of possible validation. The first is a pattern validation, the second and third are specific input types, and the last is just a required textarea with a custom error message we can provide via the non-standard x-moz-errormessage attribute.

Comment 4

[Marco Zehe (:MarcoZ)]

(In reply to David Bolter [:davidb] from comment #2)
> I'm wondering if there is a more general thing we can do with tooltips.

Well, we *do* provide the title of any given HTML element, which visually generates a tool tip, via accessibility APIs, usually via AccDescription, in some rare cases as second or last fall-back for accessible name if all else fails. I'm not sure if there are any more tool tips we need.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Marco Zehe (:MarcoZ) from comment #4)
> (In reply to David Bolter [:davidb] from comment #2)
> > I'm wondering if there is a more general thing we can do with tooltips.
> 
> Well, we *do* provide the title of any given HTML element, which visually
> generates a tool tip, via accessibility APIs, usually via AccDescription, in
> some rare cases as second or last fall-back for accessible name if all else
> fails. I'm not sure if there are any more tool tips we need.

Yeah I was thinking longer term (desktop API change).

Your proposal seems reasonable to me in the meantime.

Comment 6

[alexander :surkov (:asurkov)]

I'd say not prepend but use it if nothing left. So if aria-describedby is used then do not expose it as description.

The reason is that people needs to know the tooltip content when they typed something wrong and left the control. Otherwise they aren't so much interested in it because accessible name (and description) are supposed to provide enough information. 

But if something went wrong then screen reader might want aloud the tooltip content which might be different from description. For that it'd be nice to figure out solution.

Comment 7

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #6)
> I'd say not prepend but use it if nothing left. So if aria-describedby is
> used then do not expose it as description.

Well, yes, but the case could be that aria-describedby is present, but the tooltip will be present showing an error message why this element is invalid nevertheless.

> The reason is that people needs to know the tooltip content when they typed
> something wrong and left the control. Otherwise they aren't so much
> interested in it because accessible name (and description) are supposed to
> provide enough information. 

Again, this kind of tooltip is only shown if the form field doesn't validate. If it validates, the string is empty.

> But if something went wrong then screen reader might want aloud the tooltip
> content which might be different from description. For that it'd be nice to
> figure out solution.

That case is already taken care of. For example in my attached test case, input just your first name or an incomplete e-mail address (for example leave out the "com" part at the end), and tab to the Submit button and press it. Watch what happens.

Comment 8

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #7)

> Again, this kind of tooltip is only shown if the form field doesn't
> validate. If it validates, the string is empty.

that makes more sense but we need to do some trick to not expose tooltip twice.

> > But if something went wrong then screen reader might want aloud the tooltip
> > content which might be different from description. For that it'd be nice to
> > figure out solution.
> 
> That case is already taken care of. For example in my attached test case,
> input just your first name or an incomplete e-mail address (for example
> leave out the "com" part at the end), and tab to the Submit button and press
> it. Watch what happens.

Not exactly. If I typed wrong value then left the control I can see red border around it then I hover a mouse and read the tooltip. I don't do submission.

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #8)
> Not exactly. If I typed wrong value then left the control I can see red
> border around it then I hover a mouse and read the tooltip. I don't do
> submission.

And this is exactly why I want the tooltip you see to come first in the accDescription at this point, since it will give me an explanation straight away why the screen reader is telling me this field is invalid. Remember ATs do pick up the invalid state already.

Comment 10

[alexander :surkov (:asurkov)]

I just said that it would be nice if screen readers tells you automatically what's wrong with typed value when you tab out the control.

Comment 11

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #10)
> I just said that it would be nice if screen readers tells you automatically
> what's wrong with typed value when you tab out the control.

Yes, that would be my preferred solution, too, but that would require changing the whole UI interaction model, e. g. triggering the same kind of alert already when a particular form control loses focus, as is done for when "submit" is pressed and the whole form gets checked. However, since that always redirects the focus, the user might get stuck on a particular field which they might not be able to fill out properly yet. e. g. when having to tab to a link to get an Audio Captcha, which is located after the actual field for the captcha text in the tab order.

So I am proposing the above to give screen reader users something to go on when they focus a particular form field, much as sighted users get when hovering the mouse over a field.

Comment 12

[alexander :surkov (:asurkov)]

Mounir, how is the default tooltip of invalid value input implemented?

Comment 13

[Mounir Lamouri (:mounir)]

It has been implemented in bug 581947. It's implemented in browser/base/content/browser.js (see FillInHTMLTooltip method). Basically, we put element.validationMessage into the tooltip when appropriate. The code should be easy to understand.

Comment 14

[alexander :surkov (:asurkov)]

Jamie, should we use IA2_RELATION_ERROR / IA2_RELATION_ERROR_FOR to point out to a error tooltip when input's value is invalid?

Comment 15

[alexander :surkov (:asurkov)]

just in case HTML-AAM related issue: https://github.com/w3c/html-aam/issues/47

Comment 16

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #14)
> Jamie, should we use IA2_RELATION_ERROR / IA2_RELATION_ERROR_FOR to point
> out to a error tooltip when input's value is invalid?

I think that makes sense. Note that NVDA doesn't support these error relations yet, so NVDA shouldn't be used for verification.

Comment 17

[alexander :surkov (:asurkov)]

and input is supposed to expose IA2_STATE_INVALID_ENTRY?

Comment 18

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #17)
> and input is supposed to expose IA2_STATE_INVALID_ENTRY?

Correct, invalid state should be exposed while the error is present. This allows clients to optimise and not query for the relation unless they need to. It also makes sense semantically.