Quick reminder. ARIA can be used outside HTML 4, so redundancy with HTML 4 is not an issue. We provide support for accessible interoperable semantics in any environment or markup, including proprietary ones and I think it is important that we continue to do so. All the best Lisa Seeman Athena ICT Accessibility Projects LinkedIn, Twitter ---- On Fri, 09 May 2014 02:50:22 +0300 John Foliot<john@foliot.ca> wrote ---- 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 Friday, 9 May 2014 05:28:50 UTC