Re: Questions on ARIA and HTML interactions for aria-required and aria-invalid

Here is a test of HTML5 'required' attribute  + aria-required='true'
(besides other tests)
See http://www.deque.com/aria-group-viable-alternative-fieldset-legend

Using aria-required=false with HTML5 'required' attribute is author error.

With reference to the aria specs:
> Unless an exactly equivalent native attribute is available,  ...
> Does "available" mean that the element supports that attribute, or that the
> attribute is present in the current instance of markup?
In other words:
What should user agents do when author may not use HTML5 'required'
attribute on an HTML5 page but instead relies on aria-required?
What should user agents do when author uses both attributes?
Also as per above test, screen readers announce 'invalid entry' when
'required' attribute is present and field is unfilled. Is this
correct? ...seems strange when an empty form is first presented to the
user.
It should really be announced as 'required' but that will be
duplication if both attributes are honored by the user agent.
Thanks,
Sailesh Panchang
703-225-0380 ext 105

On 6/4/12, Cynthia Shelly <cyns@microsoft.com> wrote:
> We've come across a couple of places where it's not entirely clear what
> should happen with ARIA markup in HTML 5.  We're hoping for a quick
> turn-around on these questions if at all possible.
>
> 1) Aria-required
>
> <input type=text required aria-required=false>
> The html "required" attribute would win, and the element would be mapped as
> required in the Accessibility API. The string "aria-required=false" would
> still be copied to the AriaProperties property in UIA and the Object
> Attribute in IA2 and ATK.  I would also consider this to be an author
> error.
>
> Less clear is this case, where the HTML "required" attribute is not
> present.
> <input type=text aria-required=true>
>
> The ARIA spec says
> <blockquote>
> The aria spec says:
> http://www.w3.org/TR/wai-aria/states_and_properties#aria-required
> Unless an exactly equivalent native attribute is available, host languages
> SHOULD allow authors to use the aria-required attribute on host language
> form elements that require input or selection by the user.
> </blockquote>
>
> Does "available" mean that the element supports that attribute, or that the
> attribute is present in the current instance of markup?
>
> http://dev.w3.org/html5/spec/wai-aria.html#wai-aria
> Required is listed as having strong native semantics in the HTML 5 spec.
> Does that mean that aria-required is always ignored on elements that support
> @required, or that it is ignored when @required is present in the markup?
>
> The ARIA User Agent Implementation Guide says
> http://www.w3.org/TR/2010/WD-wai-aria-implementation-20100916/#mapping_conflicts
> <blockquote>
> When WAI-ARIA states and properties correspond to host language features
> that have the same implicit WAI-ARIA semantic, it can be particularly
> problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the
> host language feature are both provided but their values are not kept in
> sync, it is uncertain which one is correct. 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.
> </blockquote>
> Which is still unclear as to whether the feature must be ignored when the
> related host language feature is supported but not present in the markup.
>
>
> 2) aria-invalid
> This case does not seem to be explicitly covered in either spec.
>
> <input type=email value="not email" aria-invalid=false>
>
> The value of the element is not a valid format for the input type, so the
> browser would consider it to be invalid.  Does the aria-invalid=false
> override that, so that the accessibility tree node would be marked as
> valid?
>
> Thanks,
> Cynthia
>

Received on Tuesday, 5 June 2012 15:29:13 UTC