For accessible emojis:

1. Use them sparingly as the screen reader will read them all.
2. Use them at the end in order to keep the sentence consistent.
3. Keep words instead of emojis: the words convey a better meaning.
4. Avoid them in bullet lists
5. Avoid emojis to convey an information
6. Context can be misleading in the use of the emoji! It emphasizes points 3. and 5.

1. Users tend to use a list of all the links or headings on the page instead of the tab key! The user could then jump directly to the heading or link that sounded like what they were looking for.
2. Navigating to the homepage from an internal page: all of our interviewees searched for a link being announced as "Home"
3. To navigate to a certain page, users opened a list of all the links on a page. it was common to type the letter on the keyboard to search for the available links starting with the first letter of what they would expect the page name to start with. A "Get in touch!" link is likely to not be found
   • idea here: we need a standard about common pages! (Contact, Pricing, etc...)
4. None of the interviewees enlarged the window to take the full screen. This means some users will experience the mobile layout and behavior of the menu navigation, rather than the desktop version we intended. So a computer does not mean a desktop layout
5. None used skip links because they are less efficient than their other methods. Moreover, the skip link is sometime broken as the keyboard focus does not shift!

Generate a palette color based on one color, and shows the colors with a proper accessibility ratio (3:1 or 4.5:1).

Can work perfectly with https://www.opensourcecolorsystem.design/ where a meaning to a color is provided!

How to build common ui patterns that are accessible 👍

Create an accessible color palette based on criteria AA

A quick accessibility checklist for programmers

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.