White text is better seen on orange background, although it has lower contrast. It requires more effort.

Black text seems less readable by the majority but it is better for some users.

There is no clear distinction.

More recently, the idea to treat attribute selectors on par with classes as first-class citizens has been proposed more widely. We’re no longer talking about edge cases, but challenging the very defaultness of classes, all while not giving up that sense of structure that many of us look for in CSS naming conventions.

👍‍

And think of aria-selectors too ! This promotes an a11y-first mindset — if there is no attribute or pseudo selector available to represent the state we wish to style, should we add one?

this is the principle that class selectors violate. An element’s classes are never guaranteed to reflect their state

Using data attributes instead seems a good idea to avoid impossible states!

And there’s a reason why

looks attractive — it’s mirroring the APIs we’re used to seeing in design systems and component libraries, but bringing it to vanilla HTML and CSS.
Indeed, it’s a small step from data attribute selectors to custom pseudo selectors or prop-based selectors when using Web Components (think ).

Styling based on ARIA attributes encourages more accessible markup, and styling based on custom data attributes makes it more robust and readable — a better experience for users and developers alike.

Things to consider :

• alternative descriptions
• character sets and language codes
• documentation
• invisible content
• ask for Voluntary Product Accessibility Template (VPAT) and use it
• CLI tools are also concerned with accessibility

A font meant for readability by the Braille Institute

For a mobile app:

We examine everything page by page and log all errors into a central database.
We then convert that content to Jira tickets, complete with descriptions, screenshots, and story points.
If we work with a third party, and one of its tools is not accessible, we work with them to make it accessible.

it looks similar to the service Sentry.

WebAIM says the most common types of WCAG 2 failures comprise 96.8% of all accessibility errors.

• Low contrast text
• Missing alternative text for images
• Empty links
• Missing form input labels
• Empty buttons
• Missing document language

The % of these errors is diminishing over time though

Web Content Accessibility Guidelines Success Criterion 2.4.4: Link Purpose (In Context) instructs us to ensure that a link’s accessible name makes sense when separated from its surrounding context. It’s why “learn more about elephants” is a far more effective link name than “click here.”

Cool to know.

This is all about maintaining an equivalent experience by not over-describing something for only a certain subset of people. Here, the goal is to preserve the author’s intentional act of creating a sense of curiosity, regardless of the way someone interacts with technology.

Links are not focusable by default on Firefox... WTF ?!
Here the solution:

1. about:config
2. Change the value of accessibility.tabfocus to "Number"
3. Set the value 7 to accessibility.tabfocus

tabs are indeed more adaptable, and carry clearer semantics that a Braille reader understands

So tabs vs spaces: tab for accessibility?

I have a bad experience with carousels as the user can not control it.

Instead:

• ResidentAdvisor avoid carousels altogether, highlight three last features, and invites users to explore more with a “View more features” button.
• Australia Post uses a dynamic layout to highlight all features together in the same area.
• 168plymouth uses mini-carousels for each feature that they want to highlight. There is no rotation, no auto-advancing, and you can move only in a single direction — moving backward might not be necessary with just 4 images that every panel contains.

TL;DR refers to the language selector checklist

In my experience, when asked to change a country or language, a vast majority of users will immediately head to the header of the page first, and if they can’t find it there, they’ll jump all the way to the bottom of the page and scout the footer next.

I find this rule true in my experience:

We can’t confidently infer users’ preferences without asking them first.
While polite nudging is reasonable, automatic redirects are not.

As a rule of thumb: let the user choose between language, country and currency.

For example, if you want to purchase sneakers on Adidas from Germany but deliver them to your friend in Poland, you need to be able to make sense of the Polish language when checking out.

Moneses shows two tabs in the right upper corner of the header. Users can switch between language and country, defining preferences for each separately. [...] We can allow users to customize further parts of the UI, from currency and auto-translation to units of measurement and date formatting.

Preferred customization:

• shipping location
• preferred currency
• units of measure
• time/date formatting
• time zones preferences
• level of experience

Modal windows are often dismissed. So, In the mock-up above [with a modal on the bottom right], the important content isn’t blocked by the modal.

• display most languages/countries in their local format . It avoids the assumption that the user needs to understand English.
• breaking options down by tabs, either horizontal or vertical ones
• provide users with poignant autocomplete suggestions. But Sometimes the fine-tuning of making autocomplete work for many different languages might be an effort way too underestimated and way too time-consuming.
• Use the globe or translate flags to indicate the choice of locales

On Atlassian, if the user with a different browser language preference enters the site, it suggests changing the language at the very top of the page, with a globe icon appearing there, too.

I am already applying that, but only because I had a class about it. It is useful though to have content about it online.

The tricky part is to make sure that requests made with JavaScript work the same as with HTML.

• Implement features in HTML first
• then add javascript

Conveniently, if the HTML is done properly we can derive all the information we need.

document.querySelector('form').addEventListener('submit', (event) => {
  const form = event.target;
  const url = new URL(form.action || window.location.href);
  const formData = new FormData(form);
  const searchParameters = new URLSearchParams(formData);

  const options = {
    method: form.method,
  };

  if (options.method === 'post') {
    // Modify request body to include form data
    options.body =
      form.enctype === 'multipart/form-data' ? formData : searchParameters;
  } else {
    // Modify URL to include form data
    url.search = searchParameters;
  }

  fetch(url, options);
  event.preventDefault();
}

For POST requests, we’ll send the data in the request body.

• If the form explicitly sets the enctype to 'multipart/form-data', it’s safe to use FormData in the body.
• Otherwise, we can fall back to URLSearchParams.
  For GET requests, we’ll send the data in the request URL with the URLSearchParams object.

For the response: the header Accept: 'application/json' tells the server that json is awaited by the client else return HTML or a redirect :)
if we want to support HTML forms, we are though limited to GET and POST. But there is a nice workaround too:

• The GET and POST routes don’t change.
• The PATCH and DELETE routes become POST.
• We append the “methods” /update and /delete to their respective routes.

Also: to include extra data in your request, you can use and input with the name, value, and the type of “hidden”.

It is also important that not all progressive enhancement is a zero sum game.

A browser extension that automatically increases contrast on sites.

👍‍

This could also be implemented in the browsers :)

As a general rule, we should give the user as much control as possible, and we should never disable or block their settings from working. For this reason, it's very important to use a relative unit like rem for typography.

Then we should use rem everywhere ?

Do I actually want everything to scale with font size?
When we use rem values for horizontal padding, though we amplify the effect "larger the text is, the fewer characters can fit on each line".

So the final question is:

“Should this value scale up as the user increases their browser's default font size?”

I've come to realize, however, that we usually do want to use rems for media queries.

We're so used to thinking of media queries in terms of mobile/tablet/desktop, but I think it's more helpful to think in terms of available space. [Why in the post]

Other example is the space between paragraphs: it has a "functional" purpose so that we can quickly tell where one paragraph ends and the next one begins. For this reason, it does make sense to scale these margins with the user's chosen root font size.

Example of use of em instead of rem

• rem

h1 {
  font-size: 3rem
  margin-top: 6rem;
  margin-bottom: 1.5rem;
}
h2 {
  font-size: 2rem
  margin-top: 4rem;
  margin-bottom: 1rem;
}
h3 {
  font-size: 1.5rem;
  margin-top: 3rem;
  margin-bottom: 0.75rem;
}

• em

h1 {
  font-size: 3rem;
}
h2 {
  font-size: 2rem;
}
h3 {
  font-size: 1.5rem;
}
h1, h2, h3 {
  margin-top: 2em;
  margin-bottom: 0.5em;
}

Another example is the width of a button: we can think about it alone yet.

Finally, it is better to forge an intuition as opposed to a set of rules about using rem/px as there are always edge cases.

Why zoom is deactivated on some websites ? What is the advantage ?

You can force it though:

In Firefox find the settings, select “Accessibility” and activate “Zoom on all website”
In Chrome find the settings, select “Accessibility” and check “Force enable zoom”

Especially what I was looking for :)

Examples of accessible component and use cases

Another good font for digital displays 👍

Pick your main color and this tool generate the platette that is WCAG compliant.
It generates individual Sass variables or css variables.