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?)

sorry - meant to reply all previously. Please see inline.
Regards,
James
On 5/8/2014 2:26 PM, James Craig wrote:
> On May 8, 2014, at 1:02 PM, John Foliot <john@foliot.ca> wrote:
>
>> <input type="checkbox" aria-required="true"> - ARIA semantic "wins", as
>> it was explicitly applied by the author (and based upon James' earlier
>> email, this is where I disagree with James)
>
> 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."
>
> The only arguments I've heard against this are stylistic and functional behaviors that can both be resolved with CSS and JavaScript. If you don't like the native styling of input[required], fix it by adding an input[required] {} block in your CSS. If you don't like the auto-submission behavior of a required form field, fix it in the JavaScript submit handler.
>
> Otherwise, if you don't want to do either of these things, don't use a native form field. Use <div contenteditable role="textbox" aria-required="true"> or something else.
This sounds like a very drastic requirement in order to resolve this. I 
certainly would not want to suggest that authors do something like this.

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. Pretty much every browser out exposes this as a required field 
today and there is a large amount of code out in the wild that does 
this. Changing this behaviour will make these pages less accessible.

Regards,
James





>
> James
>
>

Received on Thursday, 8 May 2014 23:07:24 UTC