Re: The use of aria-readonly on contenteditable elements

Joanie,

I tried your example in Chrome and aira-readonly does not prevent you from
editing.  I am unfamiliar with data-expectedwritable used in your example -
is the behavior changed if the data-expectedwritable is removed?

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From:	jdiggs <jdiggs@igalia.com>
To:	Fred Esch/Arlington/IBM@IBMUS
Cc:	ARIA Working Group <public-aria@w3.org>
Date:	05/09/2016 04:31 PM
Subject:	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.