705829 - <input required> and <input aria-required="true"> should both provide "error bubble" when input is empty

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[John Foliot]

User Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.7.62 Version/11.01

Steps to reproduce:

See: What should have happened?


Actual results:

See: What should have happened?


Expected results:

<input required> and <input aria-required="true"> should both provide "error bubble" when input is empty; currently only <input required> does so. For legacy reasons authors should use the aria-required="true" as it has better support in screen readers. Since HTML5's "required"  == aria-required="true" in the Accessibility APIs it would be nice if the visual output was equal as well.

Comment 1

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

Note: pros and cons are under debate.

Comment 2

[alexander :surkov (:asurkov)]

ARIA was designed to make custom widgets accessible. I can think of two primary reasons of custom widgets development:
#fancy widgets
#lack of HTML capabilities

HTML5 introduced new widgets and new capabilities so web authors don't need ARIA if they are happy with standard widgets. HTML5 or any HTML follow up should address the 2nd reason in the end. I think as long as HTML5 provides required attribute then there's no point to use aria-required on HTML input if browsers implement HTML5.

(In reply to John Foliot from comment #0)
> For
> legacy reasons authors should use the aria-required="true" as it has better
> support in screen readers.

That sounds like let's make browsers to provide visual presentation for aria-required because some browsers don't support well HTML5. This sound recursive.

But actually that's what ARIA is about. If some widget has bad support accessibility support then use ARIA. So web authors need to do <input required="true" aria-required="true"> to make it working with browsers with poor HTML5 support. Closing bug as wontfix. If you disagree then please feel free to reopen it.

Btw, that doesn't mean I think that ARIA should never affect on UI and that doesn't seem like a bad idea in general. But this is a thin ice and by making this we need to make sure we don't prevent widget custom styling and behaviors.

Comment 3

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

Thanks Alexander. I think that captures most of the twitter conversation as well as some of the phone chat I had.

One other point I made via twitter:
http://twitter.com/#!/davidbolter/status/141320752304619520
"Imagine building custom windows controls and MSAA semantics controlling the visuals - bet devs wouldn't add MSAA then."

Getting the dojo dijit controls to work and look correctly in all the main browsers was very difficult, one great thing about when we added ARIA was that it didn't mess with the UI at all. IMO this is a promise we should be able to keep.

Comment 4

[John Foliot]

(In reply to alexander :surkov from comment #2)
> 
> HTML5 introduced new widgets and new capabilities so web authors don't need
> ARIA if they are happy with standard widgets. HTML5 or any HTML follow up
> should address the 2nd reason in the end. I think as long as HTML5 provides
> required attribute then there's no point to use aria-required on HTML input
> if browsers implement HTML5.

This completely (unfortunately) misses the point - this is a legacy issue with AT that need not be, but exists. It has taken a long time to get AT to now do something with aria-required while at the same time AFAIK no AT is conveying the same AAPI semantic that 'required' is mapped to - they both BTW map to the same thing.

Now that browsers such as Firefox however provide a "built-in benefit" for using 'required' authors will use that, but will likely not also include the same aria-required attribute to convey the same information to the non-sighted user.  

> 
> (In reply to John Foliot from comment #0)
> > For
> > legacy reasons authors should use the aria-required="true" as it has better
> > support in screen readers.
> 
> That sounds like let's make browsers to provide visual presentation for
> aria-required because some browsers don't support well HTML5. This sound
> recursive.

It's not "the browsers", it's the AT that is slow to catch up.

> 
> But actually that's what ARIA is about. If some widget has bad support
> accessibility support then use ARIA. So web authors need to do <input
> required="true" aria-required="true"> to make it working with browsers with
> poor HTML5 support.

Which we all know is likely not to happen.

> Closing bug as wontfix. If you disagree then please feel
> free to reopen it.
> 
> Btw, that doesn't mean I think that ARIA should never affect on UI and that
> doesn't seem like a bad idea in general. But this is a thin ice and by
> making this we need to make sure we don't prevent widget custom styling and
> behaviors.

I filed the bug. You-all disagree, and I disagree with you. Guess it has to stay that way for now. 

Meanwhile, at the other end of town: https://bugs.webkit.org/show_bug.cgi?id=73237

Comment 5

[alexander :surkov (:asurkov)]

(In reply to John Foliot from comment #4)
> > (In reply to John Foliot from comment #0)
> > That sounds like let's make browsers to provide visual presentation for
> > aria-required because some browsers don't support well HTML5. This sound
> > recursive.
> 
> It's not "the browsers", it's the AT that is slow to catch up.

No, the browsers should map aria-required and required attributes into required state of AT APIs like AKT_STATE_REQUIRED on ATK or IA2_STATE_REQUIRED on IAccessible2. So AT doesn't know what was it aria-required or required attribute and they do not care.

> > But actually that's what ARIA is about. If some widget has bad support
> > accessibility support then use ARIA. So web authors need to do <input
> > required="true" aria-required="true"> to make it working with browsers with
> > poor HTML5 support.
> 
> Which we all know is likely not to happen.

I thought that's a whole point of ARIA to make inaccessible widgets accessible. Why no?

> I filed the bug. You-all disagree, and I disagree with you. Guess it has to
> stay that way for now. 
> 
> Meanwhile, at the other end of town:
> https://bugs.webkit.org/show_bug.cgi?id=73237

Ok, let's see what others will say.