@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:
>
> Clarifying a detail and apologies to Steve for forgetting the context.
> This was resolved partially (see comment #6, the spec is no longer in
> conflict with itself), but I'm still of the opinion that @required and
> @disabled should be in the Strong semantics table. If so, they would
> trump @aria-required and @aria-disabled on native HTML5 form elements.
> John F, if you agree, will you clone bug 23377?
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377#c6

Hi James, Steve, Jon,

Having read through the details of bug 23377, and thinking about Jon's
initial question, I see a few problems:

- @required and @disabled as attributes can only be applied to form inputs,
whereas in Jon's initial question he was applying aria-required to a <div>
(<div role="gridcell" aria-required="true"></div>), which is conformant, so
we aren't always comparing apples to apples. I think then that the semantics
are related to the element upon which the aria-* attributes are applied,
where form input elements are handled differently than other elements.

- in at least the case of @required, "failing" the form input requirement
invokes some alternative native styling at the browser levels, as well as
error message generation (see:
http://john.foliot.ca/required-inputs/#native).

Because of this, I could foresee some authors not wanting that kind of
visual output being generated, and rather than fiddling around with
attempting to suppress that via CSS, the "easier" thing to do would to
simply not apply the @required attribute (but just, you know, put a red
asterix or something <grin>). For this reason I think that:

James Craig wrote:
>  4. <input type="checkbox" aria-required="true">

<snip>

> Example #4 is invalid and not required because there *is* an
> html:@required attribute available on html:input, so the lack
> of this boolean attribute means the element is not required.
> The explicit ARIA attribute aria-required="true" is in direct
> conflict with this value, so the host language attribute should
> win.

...should actually be considered wrong (and harmful) - @aria-required used
in that example conveys the "important" semantic to the acc API, while at
the same time supressing the native styling that using @required would
invoke on the browser GUI. (On the surface, it also seems to make sense to
non-experts).

** The 'automatic' addition of the styling and error messages by the
browsers makes this a very real problem scenario! **


The problem of course is that when these html5 attributes were crufted,
rather than making them real boolean attributes the editor chose to make
them implied booleans, which means the absence implies their values as set
to "false" (rather than not-declared).

To Jame's question then, I think that the @required and @disabled attributes
should only trump the aria-* attributes when both are present, but that the
absence of @required and @disabled when the aria-* attributes are authored
should shift the "weight" to what the author has declared (as opposed to
perhaps accidentally implied, due to the lack of the native attribute).

Examples:

   <input type="checkbox" required aria-required="false"> - HTML5 native
semantic "wins" (This is where I agree with James)

   <input type="checkbox" aria-required="false"> - (redundant and stupid,
but still, the HTML5 native semantic "wins")

   <input type="checkbox" required aria-required="true"> - (redundant but
less stupid based upon my 2 year old blog post, but still, the HTML5 native
semantic "wins")

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


I'm not sure how that is going to shake out in the spec, but from my vantage
point, I believe this is what we should be seeking. In Comment #6
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377#c6), Steve wrote:

	"I will follow you advice and move into implicit only table, but
will keep restraint that when required is present aria-required, if
specified, must be set to true. Sound OK?"

Sounds OK, but what happens when it is not set to true? (conflict
resolution) That is the first of the 4 examples I showed, and I (and I
believe James) think that the stronger semantic of the native attribue
should trump when used on form inputs (only).


Thoughts?

JF

Received on Thursday, 8 May 2014 20:03:28 UTC