RE: aria-readonly and plain elements

There are 2 key points about aria-readonly in this thread:

 

1.       Aria-readonly=false is not the same as aria-readonly not being defined.

2.       Aria-readonly is allowed on textbox, and a common technique for implementing textbox is contenteditable.

 

WRT undefined, aria-readonly is like aria-pressed, aria-expanded, and aria-haspopup … browsers should not represent those properties as false when they are not present. Browsers and assistive technologies should not assume that a grid that does not have aria-readonly is a grid that contains gridcells that contain editable content. This point is an important aspect of the clarifications we made to the definition of the grid role in ARIA 1.1.

 

Matt

 

From: Aaron Leventhal [mailto:aleventhal@google.com] 
Sent: Thursday, July 27, 2017 10:58 AM
To: White, Jason J <jjwhite@ets.org>; Rich Schwerdtfeger <richschwer@gmail.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: 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 <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.

  _____