Textarea Markdown Component

I was very busy last week so I did not get as much time to experiment anything AI-related.

I've been tackling some feature requests for a site I maintain instead, and one of the things people wanted was the ability to format description fields, with bold text and whatnot. Makes a lot of sense, dunno why I didn't support that from the beginning!

And, because I'm obsessed with accessibility, learning, and sharing things I make, I created a shareable web component anyone can download and use!

<textarea-markdown>

Websites are created using elements. For example, <strong>hello!<strong> makes "hello!" bold.

HTML, the programming language used to structure websites, has many dozens of elements by default. However, it doesn't have an element for every possible purpose, just the most common ones.

A web component is a custom HTML element. Developers like me can author web components to enhance HTML with behaviours it does not come with by default. For example, the concept of arched text is not very common, so HTML doesn't have an element that archs text. But I'm able to make one myself!

Hello there!

<arched-text amount="0.25">Hello there!</arched-text>

Why make and use web components?

• They are universal. Websites can be build with React, Svelte, Vue, and a thousand (perhaps literally) other ways. Web components, however, will work in every single framework.
• They are fast and small compared to the same functionality in other frameworks, since they have effectively zero library overhead.
• They facilitate progressive enhancement. It's extremely hard to create the same exact experience on the web because there are too many device/browser/version combinations to think about. Progressive enhancement promises basic functionality for everyone, and optimal functionality for most.

While making the textarea-markdown component, I found myself having to implement a toolbar. The toolbar held all the formatting buttons, such as for making text bold or italic.

Sounds like just a bunch of buttons that people could click when needed, perhaps. But let's think about the user experience for someone who doesn't have a mouse.

If a toolbar has 10+ buttons, and all they have is a keyboard, then they have to use Tab and Shift+Tab a ton in order to go back and forth between the buttons they want and the text field they are editing. How inconvenient!

The Web Accessibility Initiative provides guidelines on a number of common web patterns that don't necessarily have associated HTML elements. This includes, you guessed it, toolbars!

And the guidelines for toolbars are relatively simple, but they make the experience for keyboard-only users so much better.

• A toolbar has one focusable thing in it at a time.
• Use the Left and Right arrow keys to switch between which item in the toolbar has focus.
• If the user Tabs, then they tab out of the entire toolbar.

Now, in a toolbar of 10+ items, going in and out of the toolbar requires only a single Tab or Shift+Tab. The arrow keys help choose which tool.

How did I know to use the toolbar pattern?

Essentially, through recognition, having read prior the list of ARIA Roles. These are roles that may or may not have HTML elements associated with them, and where they do not, the developer can use the roles to enrich the document with meaning that browsers, assistive technology, and AI can understand.

As such, I recommend going through the list yourself! Even if all you read is the top paragraph of every role, that will greatly enhance your overall awareness when building various widgets for the web.