search

web-platform-tests / interop

web-platform-tests Interop project
https://wpt.fyi/interop
318 stars 27 forks source link

pseudo-textNode support to stop keyboard caret bugs for Rich Text Editing Accessibility #776

Open jabcreations opened 1 month ago

jabcreations commented 1 month ago

Description

I'm the developer of the JAB Creations web platform which has a rich text editor called the Rich Editor. Over the years I have had to make wildly excessive efforts to ensure reasonable levels of accessibility. One of the greatest issues I've faced is the proper placement of the keyboard caret (not the mouse cursor).

I spend an inordinate amount of time fixing issues specifically in Gecko based browsers. While the HTML element that contains the content has the contenteditable="true" attribute/value every single time I move the keyboard caret using my rich_caret_move() function I have to explicitly add the contenteditable="true" attribute/value to that element containing the targeted textNode. Additionally it's clear that there are many issues with not being able to move the caret to an empty paragraph if the textNode does not exist because it must contain at least one character. This leads to all sorts of problems requiring many work-around. My editor adds a non-common Latin character and the paragraph or other valid text element and makes the text color set to transparent while explicitly setting the caret-color. However in Gecko browsers after the timeout the caret will get "stuck on" though at least it's still visible.

I propose that any child element of a contenteditable="true" attribute/value ancestor should be able to receive caret support in spite of having no textNode yet assigned to it because it is obvious that the user in most cases intends to type text. I suppose a "pseudo-textNode" of sorts. Just as long as I can place the caret in an element on behalf of the user.

Specification

Unknown

Additional Signals

bkardell commented 1 month ago

Thanks for the submission. Interop is very specifically focused on things which are agreed standards but lack interoperability in implementations. However, if I understand correctly, I believe this is a proposal for changing or creating a standard related to editing. If so, this suggestion should probably be given to the very nice folks in the w3c editing groups. If I've misunderstand, please let us know.