A Tip To Improve Buttons Accessibility In Your Websites

Jean — Wed, 19 Feb 2025 22:53:46 +0000

Introduction

Have you ever created a button in HTML and styled it with CSS? Well, if you are a Front-End developer, I guess you have done it a lot. But, what about your buttons accessibility? Have you ever tried to use your own website with a keyboard only? In this article my goal is to show you a tip to improve accessibility in the buttons that you create for allowing as many users as possible to interact with your website in a good manner.

The Problem

Firstly, let's start with the most common button that you would see. (I'll be using an anchor to keep HTML semantic in the example, but what I'll show you applies to buttons, links, or anything that is clickable.)

HTML

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="style.css" />
    <title>Simple website</title>
  </head>
  <body>
    <header class="header">
      <nav>
        <ul class="header-ul">
          <li><a class="header-link" href="/">Home</a></li>
          <li><a class="header-link" href="/info">Info</a></li>
          <li><a class="header-link" href="/contact">Contact</a></li>
        </ul>
      </nav>
    </header>
  </body>
</html>

CSS

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

:root {
  --header-bg: #0a0a0a;
  --header-font: #fff;
}

.header {
  padding: 10px;
  background: var(--header-bg);
}

.header-ul {
  display: flex;
  justify-content: flex-end;
  column-gap: 10px;
  list-style-type: none;
}

.header-link {
  color: var(--header-font);
  text-decoration: none;
  padding: 10px;
  display: block;
  position: relative;
  outline: 0; /**Most CSS resets out there apply this rule in some form.*/
}

.header-link::before {
  content: "";
  position: absolute;
  bottom: 0;
  left: 0;
  width: 0;
  height: 5px;
  background-color: var(--header-font);
  transition: all 0.4s ease;
}

.header-link:hover::before {
  width: 100%;
}

The functioning

You can see in the GIF above that the styling is working properly, but, there is one problem, if someone with a disability that could only use the keyboard to navigate inside the website tried to use it they would not be able to see the style on the hover effect, because the hover pseudo-class activate only when your cursor enters the element.

Using Only Keyboard

Applying Focus Style

To fix this problem, we could use the pseudo-class focus. This pseudo-class is activated for the current element that has received focus, such as a click or tab navigation in our example.

.header-link:hover::before,
.header-link:focus::before {
  width: 100%;
}

We can still reuse the style from the hover effect; we just need to apply it too when the element is being focused with the syntax (class, element tag or element id):focus

After Applying The Focus Pseudo-Class

In the GIF above is being demonstrated the example with the focus, now the user know which link is been current seen when using the keyboard instead of seeing nothing, this is a little change in our code but can benefit tons of users out there who use only the keyboard to navigate on the website.

React - A Technique To Improve Performance If You Are Reading Data From Context

Jean — Mon, 27 Jan 2025 23:16:18 +0000

Introduction

If you are dealing with state update logic, using Context-API is an initially good way to go and inject a state into a nested tree of components. However, there are cases when managing state based on Context can lead to unwanted re-renders in your components. This article has the intention to show you an approach to avoid unnecessary re-renders in your React components if you are managing a piece of UI state based on Context.

An Initial Example

Imagine you are reading data from a Todos context, that would look something like:

import { createContext, Dispatch, PropsWithChildren, useReducer } from "react";

export type TodoDTO = {
  description: string;
};

export type TodosState = Array<TodoDTO>;

export type TodosStatePayloadAction = { type: "add_todo"; payload: string }; // | other payloads format here ...;

export type TodosContextValue = {
  todos: TodoDTO[];
  dispatch: Dispatch<TodosStatePayloadAction>;
};

export const TodosContext = createContext<TodosContextValue>({
  todos: [],
  dispatch: () => null,
});

export function TodosProvider({ children }: PropsWithChildren) {
  const [state, dispatch] = useReducer(todosReducer, []);
  return (
    <TodosContext.Provider value={{ todos: state, dispatch }}>
      {children}
    </TodosContext.Provider>
  );
}

function todosReducer(
  state: TodosState,
  action: TodosStatePayloadAction
): TodosState {
  switch (action.type) {
    case "add_todo": {
      return [...state, { description: action.payload }];
    }
    //other operations below ...
    default: {
      return [...state];
    }
  }
}

The Problematic

However, the code above is totally fine if you have just a small tree of components, in the scenario where you have tons of components reading from the same Context, whenever the value state in to-dos reducer change, all the components reading from it will also re-render, even though those components who do not necessarily read the value in todos but only the dispatch function.
Take a look in the example:

export function SearchBar() {
  const { dispatch } = useContext(TodosContext);
  const textValue = useRef<HTMLInputElement | null>(null);

  function handleSubmit(e: ChangeEvent<HTMLFormElement>) {
    e.preventDefault();
    if (!textValue.current?.value) return;

    dispatch({ type: "add_todo", payload: textValue.current.value });
    textValue.current.value = "";
  }
  return (
    <form onSubmit={handleSubmit}>
      <input ref={textValue} />
    </form>
  );
}

In the example above, even though SearchBar is only reading the dispatch function from TodosContext, because the state todos and dispatch are attached together in the same Context, SearchBar will re-render again when a new to-do is added.
Now imagine this scenario where instead of a simple todo state and dispatch, you have some more complex logic to deal with, and many components are reading from it. It would cause many components to re-render again, even if they are not necessarily dependent on the state value from Context.

Removing The Unintended Behavior

To fix this behavior, we can take an approach where we split the TodosContext into two. One Context for state injection into the component tree and another Context for the dispatch/handlers.
Let's see an example:

export const TodosContextState = createContext<TodosState>([]);
export const TodosContextDispatch = createContext<
  Dispatch<TodosStatePayloadAction>
>(() => null);

export function TodosProvider({ children }: PropsWithChildren) {
  const [state, dispatch] = useReducer(todosReducer, []);
  return (
    <TodosContextState.Provider value={state}>
      <TodosContextDispatch.Provider value={dispatch}>
        {children}
      </TodosContextDispatch.Provider>
    </TodosContextState.Provider>
  );
}

In our new implementation, we split the previous Context in two, so we are injecting to-dos state via TodosContextState and the dispatch function via TodosContextDispatch, in the new implementation, when our SearchBar component submit a new to-do, only the components that are reading from TodosContextState will re-render and not all the components that are reading just a piece of data from it like SearchBar that only read the dispatch function.
We only need to do a final adjustment and update the Context in our SearchBar component from TodosContext to TodosContextDispatch and update our components that are only reading the state value from TodosContext to TodosContextState, so it would be:

export function SearchBar() {
  const dispatch = useContext(TodosContextDispatch);
  const textValue = useRef<HTMLInputElement | null>(null);

  function handleSubmit(e: ChangeEvent<HTMLFormElement>) {
    e.preventDefault();
    if (!textValue.current?.value) return;

    dispatch({ type: "add_todo", payload: textValue.current.value });
    textValue.current.value = "";
  }
  return (
    <form onSubmit={handleSubmit}>
      <input ref={textValue} />
    </form>
  );
}

Conclusion

The example is this article was trivial just for the sake of understanding, but the main lesson that you should leave with is that:

Splitting a single Context into a state/dispatch version is a good way to prevent unintended re-renders if you have components that only read a single piece of it and are not concerned about the whole state structure.

DEV Community: Jean

A Tip To Improve Buttons Accessibility In Your Websites

Introduction

The Problem

HTML

CSS

The functioning

Using Only Keyboard

Applying Focus Style

After Applying The Focus Pseudo-Class

React - A Technique To Improve Performance If You Are Reading Data From Context

Introduction

An Initial Example

The Problematic

Removing The Unintended Behavior

Conclusion