Re: The use of aria-readonly on contenteditable elements

Hi Fred.

data-expectedwritable is for the layout test expectations only. It is
completely irrelevant to the user experience or to the engine code. The
only reason I included it was because I was quoting the layout test
contents.

And of course aria-readonly doesn't prevent one from editing. That is
the point. My read of the specs, including the sections you quoted
yesterday, seem to suggest that even though one CAN edit, user agents
should tell ATs that one CANNOT edit. I find that problematic.

The sections you quoted yesterday, along with another I quoted from that
same part of the spec, seem to suggest that IF the HTML AAM does not
explicitly declare contenteditable as conflicting with
aria-readonly="true", THEN telling ATs that the editable element is
readonly is required. I find that problematic too.

This is not a problem for input elements because the HTML AAM has made
such a declaration.

--joanie


On 05/10/2016 01:04 PM, Fred Esch wrote:
> 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
> 
> 
> 
> Inactive hide details for jdiggs ---05/09/2016 04:31:12 PM---Hey Fred.
> On 05/09/2016 03:17 PM, Fred Esch wrote:jdiggs ---05/09/2016 04:31:12
> PM---Hey Fred. On 05/09/2016 03:17 PM, Fred Esch wrote:
> 
> 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.
> 
> 
> 
>

Received on Tuesday, 10 May 2016 17:31:02 UTC