Re: The use of aria-readonly on contenteditable elements

Joanie,

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


Section 7.5 Conflicts with Host Language Semantics in ARIA 1.1 has similar
guidance.  (last line 4th paragraph)

When a host language declares a WAI-ARIA attribute to be in direct semantic
conflict with a native attribute for a given element, user agents MUST
ignore the WAI-ARIA attribute and instead use the host language attribute
with the same implicit semantic.

Also note 2nd to last line 4th paragraph - which gives AT an additional
requirement is case of conflict.

Therefore, to prevent providing conflicting states and properties to
assistive technologies, host languages MUST explicitly declare where the
use of WAI-ARIA attributes on each host language element conflicts with
native attributes for that element.



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.

AngularJS can turn an element into an input. With angular your paragraph
<p> (or div or span) could end up with a role of textbox.

To your last point (Back to the matter at hand:) would a statement - don't
do dumb things be sufficient? Or do you want us to try and list every
possible dumb thing not to do. Folks are inventive, the list could get
long.


                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From:	Joanmarie Diggs <jdiggs@igalia.com>
To:	ARIA Working Group <public-aria@w3.org>
Date:	05/08/2016 01:15 AM
Subject:	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