RE: The use of aria-readonly on contenteditable elements

I have read several articles about how contenteditable is broken, but this inconsistency between links and buttons is staggering.

 

I think this deserves some in depth conversation with screen reader developers to better understand what is possible with current APIs. … I am putting it on my list.

 

Joanie, what do you think is feasible with current APIs? Should a screen reader be able to communicate the semantics of editable content while the screen reader and the content are both in reading modes/states?

 

Matt King

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Monday, May 9, 2016 2:39 PM
To: Matt King <a11ythinker@gmail.com>
Cc: Joanmarie Diggs <jdiggs@igalia.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: The use of aria-readonly on contenteditable elements

 

For what it's worth, the general HTML rules for interactive content within an editable element seem rather unclear.

 

I couldn't find any rules in the HTML spec, but based on browser testing a button still receives a click event, but a clicked link is not followed  (same results in Firefox, Chrome, and Edge).  Demo in JSBin: https://output.jsbin.com/rakakokako

 

However, you are certainly correct that visual users get all the other semantic hints (layout, font, size, color) of the markup, regardless of it's editable state.

 

On 9 May 2016 at 15:18, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > wrote:

 

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?