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

hi all,

In HTML5 the checked/unchecked state cannot be overriden by an author using
aria-checked [1]

This is sensible. What is the use case for presenting a checked checkbox as
unchecked to AT users?

In HTML5 the required state cannot be overridden by aria-required=true, but
the not required state can.[2]

This is sensible because there is a common pattern of declaring the
required state of a control via the use of text/image/symbol (unlike the
declaring of checkbox state)

name * <input>

name (required) <input>

name <img alt="required"> <input>

Other considerations:

aria-required does not equal HTML5 required:

Setting required on a control sets the state of the control to required and
invalid the equivalent of:

<input aria-required=true aria-invalid=true>

Setting required invokes UI behaviour:
auto validation
auto display  of error message(s)

The above can be suppressed via the use of the formnovalidate attribute [3]

Why would we want to force developers to add required to explicitly
indicate to AT users that a particular control is required?

The differences between the defined requirements for checked and required
may not be theoretically pure, but they are realistically practical.

[1]
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics
[2]
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics
[3]
http://www.w3.org/html/wg/drafts/html/master/forms.html#attr-fs-formnovalidate

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 10 May 2014 00:54, Jason White <jason@jasonjgw.net> wrote:

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