E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: jeffgutsell
Date: Sun, Jul 21 2024 2:01PM
Subject: what ar any risks of making elements contenteditable
No previous message | Next message →

Hi All,

I am starting to experiment with something I have never tried before. I am
thinking of using the "contenteditable" attribute on some elements where the
user could write some text then use <select> elements to apply colors, fonts
and sizes. The only goal of this would be to create a small document that
the user would print.

Is it even possible to make something like this accessible? Perhaps there is
a role or two that would tell screen readers when to go into forms mode on
the elements that have the "contentedibable" attribute.



I guess I should disclose a bit more. Years ago, when I could use MS Word
more effectively, I created my own greeting cards. The content for the
inside page had to be flipped upside down . When the printout is folded ,
the inside is right-side up. I cannot use Word that well anymore and would
like to see if I can regain the ability to create my own cards with a web
page.

I doubt that I can achieve this with standard <input> and <textarea>
elements. Hence, the experiments with putting "contenteditable" on headings
and paragraphs.



Jeff Gutsell

From: Dean.Vasile
Date: Sun, Jul 21 2024 3:52PM
Subject: Re: what ar any risks of making elements contenteditable
← Previous message | Next message →

Jeff,

Gemini says:

Yes, it is possible to make elements with the contenteditable attribute accessible, but it requires careful consideration and implementation. Here's a breakdown of the key points:

Accessibility Challenges with contenteditable

* Screen Reader Confusion: By default, screen readers don't always recognize that a contenteditable element is editable. This can lead to users missing out on the ability to interact with the content.
* Focus Management: It's crucial to manage focus properly within contenteditable elements. Users need to know where they are in the content and be able to navigate effectively.
* Role Confusion: The default role of a contenteditable element is often not suitable for its purpose. For example, a paragraph might be editable, but it should still be announced as a paragraph by a screen reader.

Solutions

1. ARIA Roles and Attributes:
* Use the role="textbox" attribute to inform screen readers that the element is editable.
* Combine this with aria-multiline="true" to indicate that it allows multiple lines of text (if applicable).
* Consider using additional ARIA attributes like aria-label, aria-labelledby, or aria-describedby to provide labels and instructions for the editable area.
2. Focus Management:
* Ensure that the contenteditable element receives focus when a user interacts with it.
* Use JavaScript to programmatically set the focus to the contenteditable element when it becomes active.
* Provide keyboard navigation options for users who prefer not to use a mouse.
3. Semantic HTML:
* Use semantic HTML elements (like <p>, <h1>, etc.) within the contenteditable area to preserve the structure of the content. This will help screen reader users understand the content's organization.
4. Styling:
* Use CSS to clearly distinguish the editable area from the surrounding content. This will help users visually identify where they can input text.

Example Code Snippet

HTML

<div contenteditable="true" role="textbox" aria-multiline="true" aria-label="Greeting card message">

<p>Write your greeting card message here.</p>

</div>

Use code with caution.<file:////faq#coding>

Alternative Approaches

Consider whether contenteditable is the best tool for your specific use case. You mentioned using <select> elements for formatting. Here are alternatives:

* Rich Text Editors: Explore accessible rich text editors (like TinyMCE or CKEditor) that provide built-in formatting options and better accessibility support.
* Custom UI: Build a custom UI with buttons or other controls for formatting options. This gives you more flexibility but requires careful implementation to ensure accessibility.

Additional Tips

* Test Thoroughly: Test your implementation with different screen readers and assistive technologies to ensure it works as expected.
* Provide Instructions: Give clear instructions to users on how to interact with the editable area.

Feel free to ask if you have more specific questions or want further guidance on implementing accessibility features.



Dean Vasile


617-799-1162

On Jul 21, 2024, at 4:02 PM, = EMAIL ADDRESS REMOVED = wrote:

Hi All,

I am starting to experiment with something I have never tried before. I am
thinking of using the "contenteditable" attribute on some elements where the
user could write some text then use <select> elements to apply colors, fonts
and sizes. The only goal of this would be to create a small document that
the user would print.

Is it even possible to make something like this accessible? Perhaps there is
a role or two that would tell screen readers when to go into forms mode on
the elements that have the "contentedibable" attribute.



I guess I should disclose a bit more. Years ago, when I could use MS Word
more effectively, I created my own greeting cards. The content for the
inside page had to be flipped upside down . When the printout is folded ,
the inside is right-side up. I cannot use Word that well anymore and would
like to see if I can regain the ability to create my own cards with a web
page.

I doubt that I can achieve this with standard <input> and <textarea>
elements. Hence, the experiments with putting "contenteditable" on headings
and paragraphs.



Jeff Gutsell

From: Jeff Gutsell
Date: Mon, Jul 22 2024 6:49AM
Subject: Re: what ar any risks of making elements contenteditable
← Previous message | Next message →

Dean, thanks for the detailed response!
I will start experimenting with this later today.
Jeff

Sent from my iPhone

> On Jul 21, 2024, at 5:52 PM, = EMAIL ADDRESS REMOVED = wrote:
>
> Jeff,
>
> Gemini says:
>
> Yes, it is possible to make elements with the contenteditable attribute accessible, but it requires careful consideration and implementation. Here's a breakdown of the key points:
>
> Accessibility Challenges with contenteditable
>
> * Screen Reader Confusion: By default, screen readers don't always recognize that a contenteditable element is editable. This can lead to users missing out on the ability to interact with the content.
> * Focus Management: It's crucial to manage focus properly within contenteditable elements. Users need to know where they are in the content and be able to navigate effectively.
> * Role Confusion: The default role of a contenteditable element is often not suitable for its purpose. For example, a paragraph might be editable, but it should still be announced as a paragraph by a screen reader.
>
> Solutions
>
> 1. ARIA Roles and Attributes:
> * Use the role="textbox" attribute to inform screen readers that the element is editable.
> * Combine this with aria-multiline="true" to indicate that it allows multiple lines of text (if applicable).
> * Consider using additional ARIA attributes like aria-label, aria-labelledby, or aria-describedby to provide labels and instructions for the editable area.
> 2. Focus Management:
> * Ensure that the contenteditable element receives focus when a user interacts with it.
> * Use JavaScript to programmatically set the focus to the contenteditable element when it becomes active.
> * Provide keyboard navigation options for users who prefer not to use a mouse.
> 3. Semantic HTML:
> * Use semantic HTML elements (like <p>, <h1>, etc.) within the contenteditable area to preserve the structure of the content. This will help screen reader users understand the content's organization.
> 4. Styling:
> * Use CSS to clearly distinguish the editable area from the surrounding content. This will help users visually identify where they can input text.
>
> Example Code Snippet
>
> HTML
>
> <div contenteditable="true" role="textbox" aria-multiline="true" aria-label="Greeting card message">
>
> <p>Write your greeting card message here.</p>
>
> </div>
>
> Use code with caution.<file:////faq#coding>
>
> Alternative Approaches
>
> Consider whether contenteditable is the best tool for your specific use case. You mentioned using <select> elements for formatting. Here are alternatives:
>
> * Rich Text Editors: Explore accessible rich text editors (like TinyMCE or CKEditor) that provide built-in formatting options and better accessibility support.
> * Custom UI: Build a custom UI with buttons or other controls for formatting options. This gives you more flexibility but requires careful implementation to ensure accessibility.
>
> Additional Tips
>
> * Test Thoroughly: Test your implementation with different screen readers and assistive technologies to ensure it works as expected.
> * Provide Instructions: Give clear instructions to users on how to interact with the editable area.
>
> Feel free to ask if you have more specific questions or want further guidance on implementing accessibility features.
>
>
>
> Dean Vasile
>
>
> 617-799-1162
>
> On Jul 21, 2024, at 4:02 PM, = EMAIL ADDRESS REMOVED = wrote:
>
> Hi All,
>
> I am starting to experiment with something I have never tried before. I am
> thinking of using the "contenteditable" attribute on some elements where the
> user could write some text then use <select> elements to apply colors, fonts
> and sizes. The only goal of this would be to create a small document that
> the user would print.
>
> Is it even possible to make something like this accessible? Perhaps there is
> a role or two that would tell screen readers when to go into forms mode on
> the elements that have the "contentedibable" attribute.
>
>
>
> I guess I should disclose a bit more. Years ago, when I could use MS Word
> more effectively, I created my own greeting cards. The content for the
> inside page had to be flipped upside down . When the printout is folded ,
> the inside is right-side up. I cannot use Word that well anymore and would
> like to see if I can regain the ability to create my own cards with a web
> page.
>
> I doubt that I can achieve this with standard <input> and <textarea>
> elements. Hence, the experiments with putting "contenteditable" on headings
> and paragraphs.
>
>
>
> Jeff Gutsell
>
>
>
> > > > > > > >

From: David Engebretson Jr.
Date: Mon, Jul 22 2024 8:28AM
Subject: Re: what ar any risks of making elements contenteditable
← Previous message | No next message

Please do let us know if you'll be experimenting with this on GitHub. I've been thinking about this same kind of project for years. GitHub would be a great way to get a community of like minded programmers together on an open source project.

Maybe the repository could even have a couple of examples of how to do content editable correctly. Vendor design choices can often be difficult to dive into but, if they had a good reference for how to most efficiently use content editable, then we as assistive technology users may have more consistent and equitable results.

Thanks for bringing this up,
David