RE: The use of aria-readonly on contenteditable elements

In the HTML-AAM, The ARIA column is blank for contenteditable.

What if it mapped to role="textbox" aria-multiline=true? That would clear up
this issue, right? It may be somewhat nuclear in its approach, but it seems
to be how the world works today.

In current implementations, it seems that no matter what element to which
you apply contenteditable, the native semantics of that element are lost. It
doesn't matter if you put it on a div, span, paragraph, or list, it is just
"editable" and it doesn't seem to work, at least not with screen readers,
unless you add role textbox.

Matt King

-----Original Message-----
From: jdiggs [mailto:jdiggs@igalia.com] 
Sent: Monday, May 9, 2016 1:31 PM
To: Fred Esch <fesch@us.ibm.com>
Cc: ARIA Working Group <public-aria@w3.org>
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-readonl
y.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:55:50 UTC