Get people to start their own websites as easily as possible.

At the time of writing, it is a great work in progress.

As UI evolves, I think we will come one day with a UI library that can be customized entirely (hello white label design system).

Being able to test features on it should also be possible. It don't understand how all accessibility criteria can be tested though.

Le guide d'Orange contenant un certain nombre de ressources

It was already, is and becomes an issue of the web.

Here the thoughts of Brisray.

One of my favorite things to do when stumbling upon a web page that uses an accessibility overlay is to use the overlay to increase the font size. I'm giving a 99.9% guarantee that this will cause the formatting on the page to break at some point. Couple that with increasing the line height and the letter spacing and you get a 100% return on your investment. Probably need to install a second overlay to fix this problem.

What happens on web pages when these three values are changed?

The summary/details pattern is the best way to hide and show content.

Why is there the first rule of ARIA? Because ->

I didn't push the thought to this point! The distinction between the focus indication area and the contrasting area is also pertinent.

A set of resources to use fluid typography instead of media queries

Fresh from Setptember 2023

1. Check if the image really needs a description. Maybe it is decorative. The W3C alt decision tree(opens in a new tab) is an excellent resource to help you categorize your photos.
2. Avoid writing "Image of", "Icon of", or "Picture of". Screen readers announce the presence of an image. Adding these words inside your alt is unnecessary.
3. Keep it as short as possible. Be specific but not overly descriptive.
4. Try to put the most essential information at the beginning of your description.

Use accessibility APIs of OSes that contains building blocks. These building blocks have 3 kinds of information about a UI element.

The first is a role: What kind of element is this?
The second is a name: a label or an identifier for this element.
The third is state and other properties: Other functional aspects of an element that would be relevant for a user or an assistive technology to be aware of. Is a checkbox checked or unchecked, etc...

It looks like ARIA, oh wait!

The web browsers now expose this accessibility tree.

A Jupyter notebook demo style for JS.

blog-cells can turn any web page into an interactive code notebook, similar to Jupyter notebooks, but powered by JavaScript and running entirely in the browser.

There's no server-side component, so you can share your notebooks on static site hosts like GitHub pages. Check out the source for this page here.

Check it out https://github.com/rameshvarun/blog-cells

aria-label, aria-labelledby, and aria-describedby can all be used to bring extra clarity to a given element when it's exposed to assistive technology.

• aria-label overrides an element's name with contents you specify.
• aria-labelledby replaces an element's name with contents from another node on the page. You'd use this when you'd already have a visible label anyways.
• aria-describedby sets your element's description to the contents of another node on the page. This is great for noncritical, supplemental information.
• aria-description… is coming.

As always, avoid ARIA whenever possible.

An argument against React, because all its features are already built-in.

Web frameworks extend the native web features but the ecosystem catches up. It is slow and take times though.

The debate around SPA, MPA and so on is also a way to ask if whether sites should abandon core built-in features to rebuild one (in frameworks).