RE: @required and @disabled - strong or weak ? (was RE: Does the HTML5 required attribute have the same accessibility affect as aria-required for an ARIA defined widget?)

James Craig wrote:
>
> On May 8, 2014, at 4:06 PM, James Nurthen
> <james.nurthen@oracle.com> wrote:
>
>
> > There is a huge backwards-compatibility argument to allowing <input
type="text"
> > aria-required="true"> to act as a required field to the AT APIs.
>
> The same argument applies to <input type="text" required
aria-required="true"> and
> no one is opposed to allowing authors this redundancy for the sake of
> backwards-compatibility.

No argument. What James N. notes, and I agree with, is that there is already
a fairly large corpus of content out there that exhibits <input type="XXX"
aria-required="true">; and that you are now stating is not valid due to
HTML5's new implied boolean of @required. You are suggesting that browsers
"break" that based upon an apparent dichotomy.

We cannot undo hixie's mess, but we also cannot create a new mess based upon
"code purity". You stated:

  "We can't write a spec that has a one-way dependency on a boolean
attribute. It doesn't make sense. You're effectively saying "True is true,
except in some cases where it's not." "

Why not? We can certainly state that under a specific condition (when
applied to an <input> element) the ARIA semantic takes precedence: this is
testable, scalable and while from a purity perspective upside down, it can
still be made valid and conformant. I will further assert (again) that for
non-experts <input type="XXX" aria-required="true"> makes perfect sense.

JF

Received on Thursday, 8 May 2014 23:50:54 UTC