Re: aria-readonly and plain elements

I don't think there is currently a way to differentiate readonly as false
vs undefined in current platform accessibility APIs.

Core-AAM suggests the EDITABLE state, but I believe that tends to mean that
the editable interface is exposed. In fact because of that it is actually
exposed on a readonly field. Also, I'm not sure what would happen if we
started exposing the EDITABLE state when something wasn't actually editable.

We could introduce an object attribute or something, but I just want to
point out that no one currently does this and no one has really talked
about support it in screen readers, afaik. I could be completely wrong --
someone correct me if so.

Aarn

On Tue, Aug 1, 2017 at 6:07 PM Matt King <a11ythinker@gmail.com> wrote:

> 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> 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.
> ------------------------------
>
>