E-mail List Archives
Re: what ar any risks of making elements contenteditable
From: Jeff Gutsell
Date: Jul 22, 2024 6:49AM
- Next message: David Engebretson Jr.: "Re: what ar any risks of making elements contenteditable"
- Previous message: Dean.Vasile@outlook.com: "Re: what ar any risks of making elements contenteditable"
- Next message in Thread: David Engebretson Jr.: "Re: what ar any risks of making elements contenteditable"
- Previous message in Thread: Dean.Vasile@outlook.com: "Re: what ar any risks of making elements contenteditable"
- View all messages in this Thread
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 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 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
>
>
>
> > > > > > > >
- Next message: David Engebretson Jr.: "Re: what ar any risks of making elements contenteditable"
- Previous message: Dean.Vasile@outlook.com: "Re: what ar any risks of making elements contenteditable"
- Next message in Thread: David Engebretson Jr.: "Re: what ar any risks of making elements contenteditable"
- Previous message in Thread: Dean.Vasile@outlook.com: "Re: what ar any risks of making elements contenteditable"
- View all messages in this Thread