Re: The use of aria-readonly on contenteditable elements

In most cases, I think this should be a key guiding principle:

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

aria-readonly only has meaning in the context of widget roles that are
normally editable.  If someone uses contentEditable AND a widget role to
create a custom text field, it makes sense that they can mark that custom
field as read-only.

If aria-readonly is used without a role, the guiding principle would be
point 6 from section 5.5.1 of the Core-AAM: "Some WAI-ARIA properties are
not global, and are only supported on certain roles. If a non-global
WAI-ARIA state or property is used where it is not supported, user
agents should
not map the given WAI-ARIA property to the platform accessibility API. "

Which means that only area with a potential conflict is if an element has a
widget role, contentEditable attribute, and aria-readonly="true". One would
*hope* the author would remove the contentEditable attribute to enforce the
read-only state, but it is theoretically possible that someone would allow
edits and then revert them with JavaScript.

Three options that I see:


   1. Treat editable and read-only as different interfaces to the same
   underlying state, and insist that the contentEditable attribute be treated
   as a strong native semantic that over-rides aria-readonly when it is
   present.  (The absence of contentEditable wouldn't be significant, since
   older sites may use JS and keyboard events to create an editable field.)
    Add a rule to ARIA 1.1 that aria-readonly="true" MUST NOT be used on an
   element that is editable according to host native semantics.

   2. Treat this as a matter of bad authoring practice rather than an
   unrecoverable error.  So long as the two attributes are being exposed by
   different state properties, we don't need to explicitly state which one
   takes precedence.  Of course, this fails if any API only has a single
   property for expressing editable versus read-only state.  Currently, the
   HTML-AAM mapping table for contentEditable is incomplete, so I'm not sure
   if that is the case.[1]

   3. Treat this as an authoring error for validation purposes (by adding a
   rule to ARIA 1.1 that authors MUST NOT or SHOULD NOT use
   aria-readonly="true" on an element that is editable according to host
   native semantics), but require user agents to continue to expose both
   conflicting states, instead of saying one over-rides the other.  Again,
   this assumes that the two states are exposed using independent mechanisms.

Which approach makes sense depends on whether it is actually possible to
expose both states (read-only and editable) in most APIs, and whether
assistive technologies treat them as independent states or as two sides to
a boolean property.

[1]:
https://rawgit.com/w3c/aria/master/html-aam/html-aam.html#att-contenteditable


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