Re: aria-readonly and plain elements

I don't agree it's necessarily a conflict. There doesn't happen to be a way
to mark a contenteditable as readonly other than by using ARIA. This
extends the contenteditable to slightly different behavior, as opposed
conflicting with it, similar how @readonly affects input type="text" but
does not conflict with it. The contenteditable would still allow the user
to move their caret around the text and copy text from it.

It's not necessarily a use case but, as I am polishing the Chrome ARIA
implementation, I try to look for things that seem weird to me. It seems
odd to disallow this use case. What if I want to create a textfield that
someone can move around and copy the pieces they need?

Aaron

On Thu, Jul 27, 2017 at 1:00 PM White, Jason J <jjwhite@ets.org> wrote:

> *From:* Aaron Leventhal [mailto:aleventhal@google.com]
>
> *Sent:* Thursday, July 27, 2017 12:16 PM
>
> HTML-AAM currently states: "If the element has the contenteditable
> attribute and aria-readonly="true", User Agents must expose only the
> contenteditable state.".
>
> *[Jason] The rationale for this which immediately comes to mind is the
> general principle that host language features take precedence over ARIA
> features in cases of conflict. If an element is declared to be
> contenteditable and aria-readonly, this is an apparent contradiction, and
> thus the host language attribute, contenteditable, is given priority.*
>
> *Now Aaron may well wish to argue that in his special case, it makes good
> sense to supply both attributes, and then the question would be whether to
> make an exception to the general principle.*
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>

Received on Thursday, 27 July 2017 17:58:34 UTC