Re: The use of aria-readonly on contenteditable elements

Hey Matt.

I *think* the gap is in the screen readers. At least in the case of
Orca, Orca could do much better with contenteditable. I'm working on
that now, but so far I think I have everything I need to implement
better support. I simply need to make the changes in Orca.

--joanie

On 05/09/2016 05:18 PM, Matt King wrote:
> 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
> 
>  
>

Received on Monday, 9 May 2016 23:07:06 UTC