RE: The use of aria-readonly on contenteditable elements

Currently, I am not aware of a screen reder that exposes the native semantics of an editable element and also lets the user know the element is editable. Perhaps this is just a major shortcoming in screen readers? 

 

Or, is this an accessibility API shortcoming?

 

Personally, I would love to be able to read the content that is in a editable element outside of edit mode in a way that preserves all the native semantics contained inside the editable element. That should be the default way since is seems to me that is what everyone else gets.

 

Today, the only way a screen reader is capable of exposing something as editable is by saying that that thing exists inside of a textbox. The more I think about it, this is a pretty lousy situation. 

 

When you put content in a textbox, it is harder to read because the screen reader insists on constantly reminding you that the reading cursor is inside of a textbox. Worse, if that textbox contains a heading or a link, you won’t know that if you are reading with a reading cursor. You can’t operate the link. You can’t use a reading mode key like “H” to jump to that heading.

 

If content is editable but not in edit mode, you really don’t have a textbox; you have semantic content. Screen reader users should be able to read it like any other content … everyone else can, right? They should be able to follow a link, right? Can’t everyone else do so? Or, are links inside of contenteditable broken for everyone?

 

Do we have a major gap in accessibility APIs or in screen readers?

 

Matt King

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Sunday, May 8, 2016 8:16 AM
To: Joanmarie Diggs <jdiggs@igalia.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: 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