Re: aria-readonly and plain elements

Hey Aaron.

What you describe is an interesting use case. But the solution you
describe for implementing it strikes me as a bit of a hack: If HTML had
some sort of "contentnavigable" attribute which explicitly made an
element caret navigable without making it editable, wouldn't that solve
the problem?

And yes, I realize that because HTML does not have such an attribute,
authors will go looking for ways to achieve the same result and may do
exactly as you describe. Unfortunately, even if aria-readonly="true"
were exposed in this case, there will be authors who fail to use it. As
a result, the hack for the lack of HTML attribute will result in ATs
claiming that some non-editable content is editable. That's not
something we want; I think we want an attribute added to HTML instead.

But even if, upon further discussion, we reach consensus that the only
way to address this use case is via changing ARIA and the associated
mappings, it's too late to accomplish that in the 1.1 cycle. It will
have to wait for 1.2.

Given that we cannot deal with it during the 1.1 cycle, and given that
asking is free, do you think it would be worth trying to convince the
HTML folks that a new attribute like "contentnavigable" is called for?
Worst case scenario is we're stuck dealing with it in ARIA 1.2; best
case scenario is we get an HTML attribute that eliminates the need for
an author hack with associated accessibility issues.

--joanie

On 07/27/2017 01:58 PM, Aaron Leventhal wrote:
> 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
> <mailto:jjwhite@ets.org>> wrote:
> 
>     *From:* Aaron Leventhal [mailto:aleventhal@google.com
>     <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 Wednesday, 2 August 2017 08:45:01 UTC