Most of the time, your job with JavaScript to enhance components’ keyboard accessibility will be done with just a handful of tools, including the use of event listeners and certain JavaScript methods of a couple of Web APIs that can help us in this task.

• keydown event: Instead, the utility of the keydown event comes when you need to add functionality to other keys [than enter or space].
• blur event: most of the time, you’ll use it to reverse the possible changes you have made with the keydown event listener.
• focus event (rare), but instead the focus method!
• button.inert works and avoid a setAttribute.

#idea #project #vue: create a directive to handle keydown and blur event into one action that is reversible.

So now we can have a look at component patterns:

• toggletips
• tabs
• modals

A guide to primary navigation on the related HTML tags. About HTML, inert and tabindex are explained.

For CSS, an optimal focus indicator is explained. There are also :focus-within and :focus-visible.

Finally some patterns such as Accordion, Tooltips and skip links are explained.

A perfect extension to audit web pages about RGAA/WCAG 2.0

Why permanent accessibility plugins are problematic?

Here are some reasons.

OpenDyslexic, Arial et Times New Roman. Les résultats ne montrent aucune amélioration sur la vitesse ni sur la précision de lecture des élèves dyslexiques avec la police OpenDyslexic. Aucun d’entre eux n’a annoncé avoir pour préférence la police OpenDyslexic.

How to make this better with little css.
Inherit font-size, line-height, word-spacing, border and padding.

There are also

• Under-Engineered Select Menus
• Under-Engineered Custom Radio Buttons and Checkboxen

Depending on the vessel (ship):
Stern (back), port (left), bow (forward), starboard (right). These directions are based on the vessel "cap".

Depending on the skiers:
"skier's Left" is based on a skier facing down the mountain.

Depending on the reader:

• inline is how a sentence is read
• block is the perpendicular of inline
• start is where the flow... starts
• end is where the flow ... ends

I find it still hard to explain and I got it with examples. Read more on mdn

block/inline and start/end can be mixed up to target a specific location. From our Latin reader perspective, it applies as follows: https://i0.wp.com/css-tricks.com/wp-content/uploads/2022/03/block-dir.png?w=720&ssl=1

It's user-centric because its language direction is respective. [...] We can embrace diversity, complexity, and unpredictability and rely on the browser engines to properly lay it out.

Why all of these? Because right, left, top, and bottom can be interpreted differently between the explainer's and the public points of view.

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.