Re: ARIA UAIG test case failure

Mm, so if I had <input role="combobox" disabled="true"
aria-disabled="false"> then input's disabled state is ignored? But if
no combobox role then disabled wins over aria-disabled. It sounds like
it complicates implementation much. Is the behavior an usecase driven?
Alex.

On Tue, Oct 15, 2013 at 1:30 PM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> Hi Alex,
>
>
>> This one goes probably from native markup. So if div was
>> used instead input then test should be working.
>
>
> Confirmed (with a span).
>
>
>> Or more generic question does ARIA win over native markup
>> when they are in direct conflict like <input disabled="true"
>> aria-disabled="false">?
>
>
> The spec states that native states/properties win over ARIA
> states/properties.  But, it's the opposite for roles:  ARIA roles win over
> native roles.  The details are here:
> http://www.w3.org/WAI/PF/aria/host_languages#host_general_conflict
>
> Quoting from that section:
> "When a WAI-ARIA role is provided, user agents MUST use the semantic of the
> WAI-ARIA role for processing, not the native semantic, unless the role
> requires WAI-ARIA states and properties whose attributes are explicitly
> forbidden on the native element by the host language."
>
>
>> So the question is
>> should aria-autocomplete:none override value provided by input
>> control?
>
>
> The <input> in the test file has role="combobox".  That role wins over the
> <input type="text">, and, in fact, the accessible in the a11y tree has a
> role of combobox.  If the author has further explicitly declared this
> combobox as having no autocompletion, why does the <input>'s native
> autocompletion have any influence here?
>
>
> --
> ;;;;joseph.
>
>
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>              - J. D. Klaun -
>

Received on Tuesday, 15 October 2013 17:52:20 UTC