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

John Foliot <john@foliot.ca> wrote:
 
> Specifically (returning to the @checked attribute), the following scenarios,
> based not on "code purity" but rather obvious logic, should stand:
> 
> 	<input type="checkbox" checked aria-checked="true"> = HTML5
> declared, ARIA declared, no conflict
> 		Redundant, but the HTML5 native semantic "wins", report that
> it is checked.
> 

That's true today as I read ARIA section 7.5.

"When a host language declares a WAI-ARIA attribute to be in direct semantic
conflict with a native attribute for a given element, user agents MUST ignore
the WAI-ARIA attribute and instead use the host language attribute with the
same implicit semantic."

> 	<input type="checkbox" checked aria-checked="FALSE"> = HTML5
> declared, ARIA declared, with conflict
> 		HTML5 native semantic "wins", report that it is checked.
> 
> 	<input type="checkbox" aria-checked="FALSE"> = HTML5 *implied*, ARIA
> declared, no conflict
> 		(Redundant, but valid) - report that it is NOT checked.
> 
> 	<input type="checkbox" aria-checked="true"> = HTML5 *implied*, ARIA
> declared, with conflict
> 		When the lack of @checked implies that it is not checked,
> but where the author expressly notes, via ARIA that it is checked - ARIA
> Semantic "wins", report that it is checked.

I agree with all but the last: I think HTML strong native semantics should be
controlling in this example. The lack of @checked implies that the checkbox is
not checked, and the ARIA attribute only affects users of assistive
technologies, speech browsers etc. Thus for most users the control is
(visually) not checked and it has to be an authoring error.

If the control ought to be checked then this will be visually apparent. If it
ought not to be and the ARIA attribute is wrong, this will only become evident
to someone who verifies the ARIA attribute or uses an assistive technology.
Thus I think the omission of the HTML attribute should take precedence here,
and the element should be reported as not checked.

Arguably, this behaviour is also the correct interpretation of the strong
native semantics table in the HTML 5.1 spec (I think it's also in HTML 5
unchanged but haven't verified).

Received on Friday, 9 May 2014 23:55:09 UTC