The use of aria-readonly on contenteditable elements

Hey all.

As I understand it, aria-readonly should not be used on inputs. And if
authors do so, the native host language readonly attribute wins out.
Right? Reference: https://www.w3.org/TR/html-aria/#attr-readonly

Assuming my understanding is correct, I've not yet found anything which
addresses the use of aria-readonly on contenteditable elements, other
than what is stated at reference above, namely:

    Only use the aria-readonly attribute for elements that
    are not allowed to have a readonly attribute in HTML5

Thus given this example:

    <p contenteditable aria-readonly="true">Edit me!</p>

The 'p' element is not allowed to have a readonly attribute in HTML5.
Are user agents really supposed to expose that as read only??

Related aside #1: There is a finite set of roles which support
aria-readonly, according to the ARIA spec. And I didn't find any
implicit mappings that turn contenteditable elements into one of those
supporting roles.

Related aside #2: ATK and AT-SPI2 got STATE_READ_ONLY awhile back. So
when the Core AAM is updated to reflect that, if aria-readonly is true,
then STATE_READ_ONLY should be exposed.

ATK and AT-SPI2 have forever had STATE_EDITABLE for text widgets. If
contenteditable is true, then STATE_EDITABLE should be exposed, as is
stated in the HTML AAM.

These two states and mappings are similar to the existing states and
mappings for IA2.

Back to the matter at hand: Regardless of the answer to my "really?"
question above, should the Core AAM and/or HTML AAM have some guidance
for user agents regarding not putting two states which express
completely opposite meaning in the state set of an object?

--joanie

Received on Sunday, 8 May 2016 05:14:21 UTC