Re: The use of aria-readonly on contenteditable elements

Hey Fred.

On 05/09/2016 03:17 PM, Fred Esch wrote:

> To your last point (Back to the matter at hand:) would a statement
> -/don't do dumb things/ be sufficient? Or do you want us to try and 
> list
> every possible dumb thing not to do. Folks are inventive, the list 
> could
> get long.

What prompted me to raise the issue is coming across the following
WebKit layout test:
https://trac.webkit.org/browser/trunk/LayoutTests/accessibility/aria-readonly.html

In it you will see the following:

    <!-- These reflect the native writable state, but can be overridden
by @aria-readonly. -->

    [...]

    <div contenteditable id="htmlEditableDiv2" aria-readonly="true"
data-expectedwritable="false"></div>

    [...]

    <div role="group" contenteditable id="htmlEditableDiv5"
aria-readonly="true" data-expectedwritable="false"></div>

So WebKit is deliberately having the value of aria-readonly override the
contenteditable attribute. Personally, I disagree with that decision.
But I don't see anything in the specs which definitively states that the
above behavior is non-compliant.* And I do see things in the spec which
could be taken to mean that the above behavior IS compliant. In fact,
the language in the very section you cited (7.5) suggests that the above
behavior is compliant:

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

The host language did declare it for input; I don't see such a
declaration for contenteditable. If there is no declaration for
contenteditable, I do not think the "MUST ignore" still applies.

> Therefore, to prevent providing conflicting states and properties to
> assistive technologies, host languages MUST explicitly declare where
> the use of WAI-ARIA attributes on each host language element conflicts
> with native attributes for that element.

Again, the host language has not explicitly declared it (that I've
found, anyway).

And in the first paragraph of that same section, it states:

     Except for the cases outlined below, user agents MUST always
     use the WAI-ARIA semantics to define how it exposes the element
     to accessibility APIs, rather than using the host language
     semantics.

The only thing in the "cases outlined below" that could be used to say
that the current WebKit behavior is officially incorrect is:

     there are elements that are inappropriate to override with
     WAI-ARIA. This could be because identical host language
     semantics exist, so WAI-ARIA is not needed, or because semantics
     from WAI-ARIA directly conflict with host language semantics.

I think the examples above fall under the heading of "inappropriate to
override ... because semantics from WAI-ARIA directly conflict with host
language semantics." But I'm not sure that everyone would agree (see the
aforementioned layout test).

>From all of the the language quoted above, it seems to me that the
WebKit behavior is arguably compliant.

--joanie

*Other than the fact that it's being used on unsupported roles. But
change the role of the above test cases to textbox and that objection no
longer applies.

Received on Monday, 9 May 2016 20:31:25 UTC