DEV Community: Elizabeth

How to build an accessible tab

Elizabeth — Tue, 12 Aug 2025 09:30:00 +0000

When building web components, it's always a good idea to use the native HTML elements available. However, there are times when you may need to create custom components. In such cases, it's crucial to ensure that those components behave like their native counterparts, especially when it comes to accessibility.

For example, when creating a custom button, you'd need to add the role="button" ARIA attribute to mimic the native <button> element. Beyond that, you'd also want to ensure the component responds to keyboard interactions, such as the Enter or Space keys, to activate the button. This also includes setting up things like tabindex, managing focus, and handling other accessibility considerations.

This tutorial, however, isn't about building custom buttons, it's about building a tab component. As of writing, there's no native HTML element specifically for tabs, making it essential to implement ARIA roles and behavior to make the component accessible.

In this guide, I'll walk you through how to create an accessible tab component from scratch. The full code is available on Codepen

Prerequisite

To follow along with this tutorial, you'll need knowledge of:

Basic HTML, CSS, and JavaScript knowledge
ARIA

ARIA Authoring Practices (APG)

When I need to build components that aren't available as native HTML elements, I typically check the ARIA Authoring Practices Guide (APG) to review the accessibility considerations for the component. In this case, we'll be looking at the Tabs Pattern.

The APG outlines the roles we'll be using for our tab component:

Tablist: A list of tab elements that reference corresponding tabpanel elements.
Tab: A label that provides a mechanism for selecting the tab content that will be displayed.
Tabpanel: A container for the content associated with a tab, where each tab is linked to its respective tabpanel.

The APG also specifies key ARIA attributes for each role:

The tablist SHOULD include an aria-labelledby attribute if the list has a visible label, or an aria-label if it doesn't.
Each tab MUST include aria-selected (true or false), tabindex, and aria-controls attributes:
- aria-selected: to indicate the current state of the tab (whether it's active or not).
- tabindex: The active tab should have tabindex="0" and inactive tabs should have tabindex="-1", to prevent them from being focusable until activated.
- aria-controls: should point to the id of the respective tabpanel, this will link the tab to its associated tabpanel.
Each tabpanel MUST have tabindex="0" to ensure it's focusable when activated, and aria-labelledby. The aria-labelledby attribute should link to the id of the respective tab, to indicate which tab controls the panel.

Tab Behaviors

APG provides two examples of the tab behavior:

Tabs With Automatic Activation: The tabs are automatically activated as they receive focus, and the respective panel is displayed. This behavior should ideally be the default. However, this behaviour is only recommended when switching tabs does not cause content loading delays or layout shifts. If delays are present, manual activation should be used to avoid a frustrating user experience.
Tabs With Manual Activation: The tabs are activated by pressing the Space or Enter key. This behavior works well in scenarios where the user might need to carefully choose or confirm the content they wish to view, such as in a form with dynamic content that could change based on the user's choice.

Accessibility Features

Tab Indexing: The active tab has a tabindex="0", while the other tabs have tabindex="-1". This ensures that keyboard and screen reader users can move between content efficiently without having to go through all of the tabs.
Tabpanel Focus: The tabpanel has a tabindex="0" to make it easy for screen reader users to move from a tab to the beginning of the tabpanel content.
Keyboard Navigation: Keyboard users can navigate between tabs using the left and right arrow keys. The tab navigation is looped, so if the user is at the beginning of the tab list and presses the left arrow key, focus will move to the last tab.
Visible Focus State: The active tab has a visible style that doesn't rely on color alone, so users with low vision, color blindness, or high contrast settings can easily distinguish the active tab from the others.
Responsive Design: Relative units are used to specify the component's width (if provided), ensuring that the tab content remains accessible and visible when the screen is magnified.
Clear Labeling: The aria-labelledby attribute is used to associate the tabpanel with the corresponding tab, making it clear for screen reader users which content corresponds to which tab.
Focus Management: When a tab is activated (either through keyboard or mouse interaction), the focus should move to the tabpanel or the first interactive element inside the tabpanel, this ensures a smooth navigation for screen reader and keyboard users.
Consistent Order: Ensure that the tab focus follows a logical, visual order. For example, a keyboard user should not move from tab 1 to tab 6 and then to tab 3 if that isn't the visible order of the tabs. The tablist should follow the visual sequence, and each tabpanel should correspond to the active tab in that same order, to ensure a predictable navigation.
Auto-activation of Tabs: APG recommends that tabs should automatically activate when they receive focus, except when switching tabs could cause content delay, layout shifts, or page reloads. This allows for a simpler navigation experience for keyboard users.

Keyboard Interaction

Tab:
- Moves focus to the active tab element
- If a tab is focused, the focus moves to the next focusable element which should be the tabpanel, or the first focusable element in the tabpanel
In the tab list
- Left Arrow: Moves focus to the previous tab. If the first tab is focused, focus moves to the last tab in the list (looping behavior)
- Right Arrow: Moves focus to the next tab. If the last tab is focused, focus moves to the first tab
- Home: Moves focus to the first tab in the tab list.
- End: Moves focus to the last tab in the tab list.
- Space or Enter: Activates the focused tab if it wasn't activated automatically on focus
- Delete(Optionally): If deletion is allowed, deletes the current tab and its associated tabpanel. After deletion, the next or previous tab is activated, depending on availability

Implementation

In this implementation, I used Tailwind CSS for styling the elements, and I've ensured that the layout is flexible and responsive. The primary focus here is on the accessibility and functionality of the tab interaction, which I've implemented using TypeScript.

The `activateTab` Function

In the code, both the tab components use the activateTab function. The function takes three params (tabs, panels, index); however, you don't need that for your implementation. Ideally, you'll only need the index parameter.

The function does the following:

Sets the aria-selected attribute: This tells screen readers and other assistive technologies which tab is selected. The active tab gets aria-selected="true", and inactive tabs get aria-selected="false".
Manages tabindex for Focus: The active tab has a tabindex="0", which means it is focusable and navigable via keyboard. The inactive tabs get a tabindex="-1", which makes them non-focusable until they're activated.
Visibility of Content: Each tab has a .active class that is toggled to add an active style to the active tab. Each tabpanel has a corresponding .active-panel class that is toggled to show or hide the content based on the active tab. Only the tabpanel that corresponds to the selected tab is visible.
Focus Handling: Finally, after making the tab active, tabs[index].focus() ensures that focus is moved to the selected tab, so the user can immediately interact with it, whether via keyboard or screen reader.

Feel free to explore the working examples on CodePen and experiment with both versions of the tab component.

If you found this tutorial helpful, connect with me on LinkedIn and Bluesky for more accessibility tips and updates!

What is Motion Sensitivity? How to Design Accessible Web Animations

Elizabeth — Thu, 08 Feb 2024 09:16:30 +0000

As web developers, we love a good animation, right? But let's be honest, sometimes we get caught up in the wow factor and forget that our websites exist for real people with diverse needs.

One hidden hurdle for some users is motion sensitivity. It might not be something we think about every day, but it can have a big impact on how people experience the internet.

In this article, I want to shine a light on motion sensitivity. We'll explore what it's like, the conditions it's linked to, and how it can affect someone's ability to enjoy using a website.

My goals for this article are:

To get you thinking about creating web experiences that are comfortable and welcoming for everyone.
To equip you with practical tips to make that happen. Because an inclusive web is a better web for everyone.

What is Motion Sensitivity?

Motion sensitivity isn't just a technical term – it refers to how we experience the digital world, especially for those whose sensitivities go beyond what meets the eye. So, let's unravel this concept and see why it matters.

According to National Library of Medicine motion sensitivity refers to a condition where a person experiences symptoms such as dizziness, nausea, and imbalance in response to motion. This can be caused by a variety of factors, including inner ear problems, neurological disorders, and certain medications.

People with motion sensitivity may have difficulty tolerating activities that involve moving, such as riding in cars and even certain motion animations.

Maybe you've taken a long road trip and experienced motion sickness. Or you've visited the cinema to see a 3D movie and, instead of enjoying the experience, you end up with headaches, migraine, dizziness, or nausea. Then you understand how serious motion sensitivity can be.

How Motion Sensitivity Impacts People

For some people, motion effects like parallax scrolling can be annoying, but the effects of motion sensitivity go beyond a mere inconvenience. It can disrupt the digital experience and, more importantly, affect the well-being of those navigating the space.

Some people might feel dizzy, nauseous, or experience headaches or migraines when faced with certain animations or transitions. For them, accessing digital content becomes more than just a click – it's a consideration of their comfort and health.

Insights into Related Disorders

To truly understand motion sensitivity, I believe we need to explore the conditions linked to it, mainly vestibular disorders and visual motion sensitivity.

Vestibular Disorders impact the inner ear and how the brain processes spatial information. For someone with vestibular disorders, simple tasks like maintaining balance or handling motion stimuli can become challenging.

Visual Motion Sensitivity is about heightened sensitivity to visual stimuli, leading to discomfort or adverse reactions to certain types of motion. For someone with visual motion sensitivity, navigating websites with specific animations or scrolling behaviors can be a struggle.

By diving into these facets of motion sensitivity, we lay the groundwork for creating digital spaces that acknowledge and respect diverse user experiences.

So, Why Does this Matter?

Well, I think it is as simple as this: everyone deserves to enjoy the digital world without feeling unwell. Understanding motion sensitivity helps us create websites, games, and apps that are more inclusive and comfortable for everyone, not just folks with superhero vision.

Let's explore why designing with motion sensitivity in mind is not just a best practice but a step towards a more inclusive online world.

How Common is Motion Sensitivity?

Motion sensitivity is more common than you might think. According to this article from Archives of Physiotherapy, it has been reported that 28.4% of the population experience motion sensitivity. Also, according to this article:

Nearly all people are affected with sufficient motion and most people will experience motion sickness at least once in their lifetime. Susceptibility, however, is variable, with about one-third of the population being highly susceptible while most other people are affected under extreme conditions. Women are more easily affected than men.

These statistics underscore the need for web designers and developers to consider motion sensitivity in our creations. They highlight that what might be a visually engaging animation for one user could be an obstacle for another.

How to Identify Motion-Sensitive Triggers in Animations

Animation can enhance engagement and help guide users through the app. But it is vital that we scrutinize the types of animations we incorporate into our designs, particularly when aiming for motion-friendly experiences.

Let's explore these potential triggers and discuss alternatives to ensure a more inclusive design.

Rapid or Flickering Animations

Trigger Potential: Quick, flickering animations can be disorienting for users with motion sensitivity, leading to discomfort or headaches. Examples of these types of animations include rapidly blinking notifications, flickering banners, or flashing call-to-action buttons.
Alternative Approach: Opt for smoother transitions like subtle fades or slides, avoiding rapid flickering effects for a more comfortable experience.

Overly Complex Transitions

Trigger Potential: Elaborate loading animations with intricate patterns, complex slide-in effects, or overly detailed transitions between pages may overwhelm users, causing sensory overload for those with motion sensitivity.
Alternative Approach: Simplify transitions, focus on clarity and purpose. Strive for elegance in design without unnecessary visual complexity.

Bouncing or Elastic Motions

Trigger Potential: Animations with bouncing or elastic movements can induce dizziness or nausea in motion-sensitive users. Examples include buttons that bounce upon interaction or elastic-scrolling effects.
Alternative Approach: Choose more subtle easing functions for animations, providing a smoother and less physically demanding experience.

High-Speed Animations

Trigger Potential: High-speed carousels, rapid image sliders, or quick-scrolling features may challenge users with motion sensitivity, potentially leading to feelings of discomfort or disorientation.
Alternative Approach: Allow users to control animation speeds or default to slower, more deliberate transitions for a universally comfortable pace.

Continuous Auto-Scrolling

Trigger Potential: Auto-scrolling features that move content continuously without user interaction, like automatic slideshows or news tickers, can be unsettling for users with motion sensitivity.
Alternative Approach: Implement user-initiated scrolling, providing control to the user and avoiding unexpected motion.

Flashing or Intense Color Changes

Trigger Potential:
Flashing animations or sudden, intense color changes can be visually overwhelming and trigger discomfort. Examples include flashing banners, intense color changes on hover, or rapidly changing background colors.
Alternative Approach: Maintain a consistent color palette and avoid rapid, drastic color shifts. Consider softer transitions for color changes.

Rotational Movements

Trigger Potential: Rotational animations, such as spinning logos or rotating carousels, may cause dizziness or vertigo for individuals with vestibular disorders or motion sensitivity.
Alternative Approach: Minimize or eliminate rotational motions, especially in situations where they may not be essential for understanding the content.

By recognizing these potential triggers and adopting alternative approaches, we can create digital experiences that are more considerate and welcoming for users with motion sensitivity.

The goal is not to stop adding animations but to design with empathy, ensuring that motion enhances rather than detracts from the user experience.

How to Use Reduce-Motion Preferences

One significant stride towards motion-friendly web design is utilizing the reduce-motion preferences embedded in operating systems and browsers. This preference provide users with the option to minimize or eliminate unnecessary animations.

By recognizing and respecting these user preferences, we can significantly enhance the accessibility of web applications.

Incorporate Reduced Motion Features

For developers, integrating reduced motion features into web applications involves a combination of coding practices and user interface considerations.

Begin by identifying areas where animations can be toned down or replaced with static alternatives. Implementing conditional checks for reduce-motion preferences in your codebase allows your web application to adapt dynamically, providing a smoother experience for users who opt for reduced motion.

CSS prefers-reduced-motion Media Feature

.animated-element {
  animation: pulse 1s linear infinite both;
}

/* Tone down the animation */
@media (prefers-reduced-motion) {
  .animated-element {
    animation: smooth 4s linear infinite both;
  }
}

JavaScript Reduced Motion Detection

// Check if the user prefers reduced motion using JavaScript

const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

// Example of adjusting animation based on reduced motion preference

const animatedElement = document.querySelector('.animated-element');
if (prefersReducedMotion) {
  animatedElement.style.animation = 'smooth 4s linear infinite both';
} else {
  animatedElement.style.animation = 'pulse 1s linear infinite both';
}

Test Your Animation on Chrome

While basic accessibility checks are readily available, Chrome DevTools offers advanced capabilities through its hidden Rendering tool.

One of the options available in the rendering tool is the option to test your animation for when a user enables prefers-reduced-motion. Here's how to leverage it:

Click the customize (three dots) icon in the DevTools panel
Select more tools
Select Rendering option from the list of options

Once enabled, the Rendering tab appears in DevTools.
Look for the option named "Emulate CSS media feature prefers-reduced-motion."
Enable this option to preview how your website's animations appear for users who have set their device or browser to reduce motion.

When a user has prefers-reduced-motion enabled, avoid completely removing animations. Aim to provide users with a smoother experience rather than completely excluding them from the interactive experience.

Motion Sensitivity Tips and Best Practices

Let's explore tips and best practices to incorporate into our designs:

Subtle Animations: Opt for subtle animations that convey information without being overwhelming. Gentle fades, transitions, and loading effects can enhance the user experience without causing discomfort.
Adjustable Speeds: Provide users with the ability to control animation speeds. Implement settings within your application that allow users to customize the speed of transitions, ensuring a comfortable experience for everyone.
Clear Navigation Signals: Use motion to guide users intuitively. For instance, employ subtle animations to indicate a change in state or to draw attention to important elements, ensuring that users with motion sensitivity can follow the flow without feeling disoriented.
User Testing: Conduct thorough user testing, specifically with individuals who experience motion sensitivity. Gather feedback to refine your design, ensuring that it meets the needs of the diverse user base.
Document and Communicate: Clearly document your approach to motion-friendly design in your project documentation. This not only serves as a reference for your team but also communicates your commitment to accessibility to stakeholders and users.

Conclusion

Motion sensitivity isn't a rare exception – it's a shared experience for many people. Our responsibility as web developers is not merely to acknowledge this reality but to actively integrate inclusivity into the DNA of our creations.

By identifying potential triggers and implementing reduced motion features using technologies like prefers-reduced-motion in CSS and JavaScript, we create spaces that accommodate diverse needs without compromising on engagement.

Accessibility is not a trend, it's a fundamental ethos that shapes the future of the internet into one where everyone regardless of their abilities can use the internet with comfort.

Thank you so much for reading this article, if you found it helpful consider sharing. Happy coding!

You can connect with me on Linkedin or Github

References

Val Head. Designing Safer Web Animation For Motion Sensitivity (September 08, 2015) https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/
Chaudhary, S., Saywell, N., Kumar, A., & Taylor, D. (2020). Visual Fixations and Motion Sensitivity: Protocol for an Exploratory Study. JMIR Research Protocols, 9(7). https://doi.org/10.2196/16805
Albalwi, A.A., Johnson, E.G., Alharbi, A.A. et al. Effects of head motion on postural stability in healthy young adults with chronic motion sensitivity. Arch Physiother10, 6 (2020). https://doi.org/10.1186/s40945-020-00077-9
Motion sickness. (2024, January 1). In Wikipedia. https://en.wikipedia.org/wiki/Motion_sickness

How to build an accessible navigation menu

Elizabeth — Wed, 06 Dec 2023 12:02:17 +0000

Hey there! Today, we're looking into how to build an accessible menu. I decided to write this article because recently, while running an accessibility test on some websites, including some of my past projects, one common issue was that navigating submenus with just a keyboard or screen reader was trickier than it should be.

This article aims to show you what to do when building a navigation and fix any oopsies you might have made. I have also added an example of a simple menu. Ready to dive in? 😅

Semantic HTML and aria

Optimizing your code for readability is as simple as choosing the right HTML tags. Consider this transformation:



<nav>
 <ul>
   <li><a href="#">list item 1</a></li>
   <li><a href="#">list item 2</a></li>
   <li><a href="#">list item 3</a></li>
 </ul>
</nav>

which is far more legible compared to:



<div>
  <div>
    <a href="#">list item 1</a>
    <a href="#">list item 2</a>
    <a href="#">list item 3</a>
  </div>
</div>

Not only is the first example more readable, but it also ensures that a screen reader lets the user know that they're currently on the navigation.

However, sometimes using the right semantic element might not explain the role of our element properly, This is where using aria and roles shine. In the first example, we have a <ul> which is currently a list, we don't want the browser to see it as a list, the ul is supposed to act as a menubar so we can improve the code by adding a role="menubar", a menubar can have a menuitem, menuradio, or menuitemcheckbox. In our case, we only need a menuitem.



<nav>
 <ul role="menubar">
   <li role="none"><a href="#" role="menuitem">list item 1</a></li>
   <li role="none"><a href="#" role="menuitem">list item 2</a></li>
   <li role="none"><a href="#" role="menuitem">list item 3</a></li>
 </ul>
</nav>

In the updated code I added a role="none" to the li tag, this is because the li will be acting as a container for this example, the element is explicitly designated as a menuitem.

Please note that there's such a thing as using the wrong aria, if you don't use aria correctly it could break your accessibility. A rule of thumb is "No aria is better than bad aria". You can read more about this here

Code structure for focus order

While you can always move things with CSS when building an accessible platform you need to ensure your elements are structured as they appear. A Properly structured code helps in managing the focus order. When users press the Tab key to move through interactive elements, the focus should follow a logical order. Without proper structure, the focus might jump unpredictably, making navigation difficult.

This is also important when working with a submenu, for example: if a user has to tab through all the menuitems before they can get to a submenu then the navigation isn't friendly. Instead of having a code like this:



<nav>
 <ul role="menubar" id="mainmenu">
   <li role="none"><a href="#" role="menuitem">list item 1</a></li>
   <li role="none"><a href="#" role="menuitem">list item 2</a></li>
   <li role="none"><a href="#" role="menuitem">list item 3</a></li>
 </ul>
<ul id="submenuList1">
  <li role="none"><a href="#" role="menuitem">sub list item 1</a></li>
<li role="none"><a href="#" role="menuitem">sub list item 2</a></li>
</ul>
</nav>

We can do this:



<nav>
 <ul role="menubar">
   <li role="menuitem">List item 1
   <ul role="menu">
     <li role="none"><a href="#" role="menuitem">sub list item 1</a></li>
     <li role="none"><a href="#" role="menuitem">sub list item 2</a></li>
   </ul>
  </li>
   <li role="none"><a href="#" role="menuitem">list item 2</a></li>
   <li role="none"><a href="#" role="menuitem">list item 3</a></li>
 </ul>
</nav>

Remember, you can always move things with CSS, but if your HTML is not structured, the experience will be different for keyboard users and screen readers. Here's an example of me using a screen reader to access a menu with a submenu.

Here's the link to the codepen you can test it on a keyboard and screen reader.

In a future article, I'll be sharing how to test with screen readers

Conlusion

Almost every web platform has a menu, it's what gives users an idea of what to expect. If some users cannot access it then your platform is not complete. You need to ensure that the experience is easy for everyone by ensuring that:

A user can navigate the menubar without using a mouse
A user can open and close the submenu without the mouse. for example: when a user clicks on the enter/return or the space key it should toggle the submenu.
A screen reader can read to the user that they're on a menuitem or a submenu.

If you want to know how to run a full test for accessibility, I wrote an article on it. You can find it ↓

How I test a website for accessibility

Elizabeth ・ Nov 14 '23

#webdev #beginners #a11y #frontend

It is our duty to make the internet experience awesome for everyone.

Thank you for reading this article. If you liked it, feel free to give it a thumbs up and share it. Drop your thoughts in the comments—I'm curious about what you think. Got a specific accessibility topic in mind? Tell me in the comments, and I'll try my hand at it. Until next time, have an awesome week or weekend! 😁

How I test a website for accessibility

Elizabeth — Tue, 14 Nov 2023 10:00:00 +0000

In today's lesson, I'll guide you through my approach to accessibility testing. We'll explore utilizing Google Lighthouse for automated a11y testing, delve into manual testing with keyboards, and learn how to emulate various media states, and visual impairment using the Chrome browser.

For this article, we'll be testing this demo webpage on CodePen or you can clone this Github repo. I intentionally made the webpage inaccessible and included common errors. We will fix these issues together.

Automated Testing using Lighthouse

Lighthouse is an open-source tool that was created to help improve the quality of a website. We'll be using it to test for accessibility, It gives quick results in just a few steps. We'll be using Chrome to test since the lighthouse is built-in

Step 1: Fork and activate debug mode on the pen

This action will generate a temporary URL for testing purposes. Debugging in the CodePen's debug view simplifies the process, eliminating the need to inspect through an iframe.

Step 2: Open Lighthouse on Chrome devtool

Pop open your browser's DevTools and head over to the Lighthouse tab. Since we're focusing solely on accessibility testing, uncheck all the other category options except Accessibility.

Click the "Analyze page load" button, and let Lighthouse run its test.

After the wait, Lighthouse will show the calculated score and a detailed list of issues that were found. In this case, we got 68% (orange) on accessibility.

Now, if this were my math test, I might call it a win, but in the world of accessibility, we've got to do better than this, right? 👀

So let's uncover the issues and fix them one at a time.

Issue 1: NAMES AND LABELS

Image elements do not have [alt] attributes

To fix that we just add the alt attribute to the images. Image alt text should be short if they're supposed to be informative or left empty if they're purely for decoration.



<img alt="a brown building" src="https://source.unsplash.com/kn_ANxnwCQ0/400x300" class="lg:w-10/12 lg:object-cover inline-block mx-auto" />

Links do not have a discernible name

When incorporating links, it's crucial to provide users with clear information about the destination. If the link is an image, it can be fixed using an alt text. In our demo page, we have several SVG images wrapped in a link. To fix this, we'll add role="img" attributes to the SVG tag and include a <title> tag within the SVG.



<svg role="img" width="25px" height="25px" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
    <title>Contact me via email</title>
....

Issue 2: ARIA

button, link, and menuitem elements do not have accessible names.

Lighthouse conveniently highlights the specific code where it detects an issue, making it easy to pinpoint. In this particular section, the problem stems from the following code and other parts where it's repeated.



 <i role="button" tabindex="1" class="fa-solid fa-chevron-right fa-rotate-180" style="color: #9da3af;"></i>

In this instance, a role="button" is present, but the absence of a title leaves no descriptive information for screen readers to convey. To fix this issue, we can add a title attribute or an aria-label. In this case, we'll opt for the use of aria-label.



<i role="button" aria-label="Previous" class="fa-solid fa-chevron-right fa-rotate-180" style="color: #9da3af;"></i>

<i role="button" aria-label="Next" class="fa-solid fa-chevron-right" style="color: #323439;"></i>

Issue 3: CONTRAST

Background and foreground colors do not have a sufficient contrast ratio.

Web Content Accessibility Guidelines (WCAG) set rules to make sure the contrast between a background and a foreground color is good enough for everyone to read, especially for those with vision challenges. So, as a developer, it's about picking colors that play nicely together, making your content accessible to as many people as possible.

In our demo, we're using a light turquoise color on a white background.

To rectify this, We have two options: increasing the font size and making it bold, or changing the color. For this demo, we'll opt for a color change. Lucky for us, chrome DevTools can help us identify an appropriate color with the right contrast.

Let's correct the contrast:

Navigate to the Element tab in the devtool and select one of the turquoise texts on the white background. Under the styles section find the text-color and click on the turquoise square to show a color wheel popup. The popup also shows the contrast ratio which is currently 1.96. Click on the dropdown and the color wheel will now have two lines.
Head to the Element tab in the DevTools and choose one of the turquoise texts on the white background. In the Styles section, locate the text-color property, and click on the turquoise square to reveal a color wheel popup. This popup displays the current contrast ratio, currently at 1.96. Click on the dropdown, and the color wheel will now show two lines.

The colors under these lines will meet the criteria for a sufficient contrast.
...

In the CSS let's update the color



:root {
  --main-color: #016d73;
  --secondary-color: #94bbe9;
}

Issue 4: NAVIGATION

Some elements have a [tabindex] value greater than 0

Please note that you might not see this issue if you selected the desktop option before running the analysis on lighthouse; This only shows on mobile

Using a tabindex value of 0 for both elements is just fine and will work exactly as expected. Using a value greater than 0 will jump ahead of everything else in the tab order and these often create poor experiences for users who rely on assistive technologies. Now there are instances where using a value greater than 0 could be valid but not in this case.

Let's fix this:



<i role="button" tabindex="0" class="fa-solid fa-chevron-right fa-rotate-180" style="color: #9da3af;"></i>
<i role="button" tabindex="0"  class="fa-solid fa-chevron-right"></i>

After addressing all of the issues from lighthouse rerun the test.

This time we should get 100 (green) on lighthouse. Here's the updated pen after fixing the automated testing issues

However, that's not the end of testing for a11y. Automated testing is just a part of the process. Lighthouse doesn't test for all instances a11y. So the next process is to do a manual test.

Manual testing

When testing for a11y manually there are several factors to test for, e.g.: trying to navigate the website only using a keyboard, using a screen reader, trying to emulate different media types, and visual impairments.

Running a manual test on our updated demo:

Semantic tags

A glance at the code will reveal that we used divs for page structure. The code doesn't look so structured and it's the same for users accessing the website through a screen reader. Let's fix that:

In the picture above, I have replaced the page structure with their semantic elements, using the header, main, footer, and section.

Keyboard navigation test

Now let's try navigating the website using the keyboard. Using the tab key. You'll notice that there's no way to know exactly where we are on the website. This is because there's no focused state on the site.

When I was new to HTML I used to disable the default focus state of links, buttons, and inputs on the website because they don't look so good. Later on, I realized that they serve their purpose.

In the CSS file, you'll see that I have disabled the focus style.

Instead of just removing the focus style we can change it. For this example, I'll use a border style.

Now if we try navigating with the keyboard you can see the links are selected when they're focused. I think this looks better.

Great!, if we continue navigating through the keyboard you might notice a part that was skipped that shouldn't be, that's the the previous and next icons. Did you notice it? 👀.

Keyboard users should be able to access that section because it's a CTA button to move the slider. So let's fix this:
There are multiple fixes for this but the simplest fix is to warp a button around the element.

Test the site again, the keyboard navigation is fantastic.

Form test

The subscribe form at the footer looks okay and it could probably pass for accessibility since it is a form with one input.

the placeholder is acting as a label (This might pass in this case but if you have multiple inputs then a user might forget what they're supposed to fill into a particular form because there's no label)

To fix this let's add a label to the input and change the placeholder text.

We can also improve the experience of this form by adding an autocomplete to the input field.

In the image above, I have also added a form title and added (required) to the label to let the user know it is required.

Here's the updated pen for manual testing of our webpage.

We have improved the experience of this webpage and it's accessible!

Conclusion

There are several other aspects to consider when testing a website beyond the ones covered in this article. When developing a functional site, it's important to test transitions and animations. Depending on the type of animation, it may be necessary to use reduced motion and ensure it functions properly. Additionally, it's a good idea to test font sizes to ensure that users with blurred vision can still read the text on the site without difficulty.

Thank you so much for reading. I hope you found this article helpful, If you did please like and share with anyone who might also find this useful.

A beginner's guide to building an accessible website

Elizabeth — Tue, 10 Oct 2023 13:23:16 +0000

Why a11y is important to me as a developer

As someone who suffers from chronic migraines, I am particularly sensitive to bright colors, which can trigger migraines. Navigating applications without a dark mode option can sometimes pose a bit of a challenge for me, especially when I need to use them for extended periods.
As I progressed in my development career, I became acquainted with web accessibility, It dawned on me that there are individuals who face persistent challenges accessing applications not just sometimes, but every time because their unique needs have been overlooked.

This realization led me to educate myself about disabilities and it became clear to me that every day is not always straightforward for people with disabilities. As a developer, I believe it is my responsibility to make sure that I create applications that are convenient for everyone, including people living with disabilities.

Tips for building an accessible Platform

Using the appropriate semantic elements in HTML can act as a guide for visually impaired users to navigate a website. HTML provides a lot of semantic elements, and it is crucial to use them properly. Some types of semantic elements include:

List items: When used correctly, HTML lists group-related elements and helps users with screen readers better understand the information presented. Examples are:
<ul>, <ol>, <dl>, <li>, <menu>

Body structure: Instead of using divs to separate every section of your website, use the semantic element to give structure to your website or web application. Examples of the body structure include <header>, <footer>, <main>. <nav>, <section>.

Accessible attributes: HTML attributes are very important when building accessible web platforms. They can give more information about an element, especially for people using screen readers to access your platform. Some web-accessible attributes are: aria, rel, alt, role, title, and so on.

alt: The alt attribute is an important tag in HTML that provides more information about the images used on a webpage. It is used by screen readers to describe the image to users. It is recommended to keep the alt text brief and to the point. If the image is purely decorative, then the alt tag should be left blank. Avoid using phrases like "image of" or "photo of" in the alt text, as these are already interpreted by screen readers.

An example of a descriptive image: <img scr="cat.png" alt="a smiling cat" />
An example of a decorative image: <img scr="arrow.svg" alt="" />.

I created an image component in my React app using typescript to ensure that I always provide an alt text. I made it mandatory to pass the alt as a prop, so if I ever forget to add the alt attribute to my image, typescript throws an error and reminds me to add it.

interface ImageInterface extends HTMLAttributes<HTMLImageElement> {
  src: string;
  alt: string;
}

export const Image: React.FC<ImageInterface> = ({ src, alt, ...rest }) => (
  <img
    src={src}
    alt={alt}
    {...rest}
  />
);

export default Image;

role: The 'role' attribute does exactly what it says—it tells browsers and screen readers what an element does. It's like giving an element a specific job title. Always use the most fitting role possible, and avoid using generic roles like 'group' unless it's really necessary. Also, don't double up on roles; if something already has a clear description, let it be. e.g

// Here is a wrong use of role: 
`<button role="button">Click me</button>`. 
// You're already using a button you do not need to add a role.


//This is a valid example of using the role: 
`<div role="button">
This div is now acting as a button
</div>`

Keyboard Navigation.

When creating a web page or component, I prioritize smooth keyboard navigation to ensure a seamless user experience. If I encounter any challenges in navigating with a keyboard, I revisit my code and make the required adjustments. It's important to remember that some users rely solely on their keyboards to interact with your applications. Neglecting to test and optimize for keyboard navigation can create barriers for these users, hindering their experience with your platform. Therefore, it is crucial to ensure that keyboard navigation is seamless and user-friendly for all users.

Accessible Colors

I have visited some websites where it was quite difficult for me to navigate due to the color scheme. If you are not someone with a permanent color vision issue it is still important to understand how people perceive color and contrast. This will help you understand how to best support their visual needs.

For a comprehensive understanding of the color system and accessibility, refer to this article by material.io..

When working with colors it is important to understand the CSS media @prefers-color-scheme and @prefers-contrast. The linked MDN articles offer detailed insights on how to effectively utilize these features.

Animations

Web accessibility goes beyond using correct HTML codes; it also involves considering the impact of animations on users. Personally, as someone prone to migraines, certain animations can trigger dizziness for me. If you've experienced motion sickness, be it in a car or on a boat, you can relate.

To address this concern, the @prefers-reduced-motion CSS media query comes into play. It checks whether users have enabled a setting on their device to minimize the amount of motion they experience.

.animated-element {
  animation: swing 1s linear infinite alternate;
}

@media (prefers-reduced-motion) {
  .animated-element {
    animation: none;
  }
}

It is also important to avoid flashing content which can be particularly frustrating for users with photosensitivity, frequent flashes also have the potential to trigger seizures.

In cases where flashing content is unavoidable, it's imperative to include a Flash Warning alert on your platform. This proactive approach ensures users are informed and can take necessary precautions while engaging with the content.

Forms

When you're working with form elements and attributes, the default elements have very good accessibility support. But sometimes the styles are not very pretty and uniform across different browsers and we might need to create custom form styles. when building custom forms, it's essential to prioritize accessibility.

Ensuring that custom styles maintain accessibility standards is crucial. This guarantees that, despite the visual enhancements, users of all abilities can seamlessly interact with and navigate through the form.

Always add a focus style for your form so a keyboard user knows which field they're currently on, the HTML input element already has a focus style using an outline, I personally don't like that style so using tailwind I would usually replace it with something like:

<input class="focus:outline-none focus:ring-1 focus:ring-slate-400" />

Labels: They are used to inform a user about the purpose of an input field. Do not replace the labels with placeholders as they serve different purposes. If a field is required a good practice is to add that to the label.

<label>Email address: 
<span>(required)</span>
<input id="email" type="email" autocomplete="email" required />
</label>

Error handling: When a user encounters a form error, we need to make the error known to the user in the simplest way possible, and offer suggestions on how to fix the error.

More accessibility tips:

Use the appropriate semantic elements (e.g: don't replace your button with a div)
Use appropriate attributes where required (e.g alt, tabindex)
Use common fontface whenever possible.
Use relative values for your base font sizes (e.g. %, rem) to allow easy resizing.
Avoid using justified paragraph alignment text-align: justify;, It can create uneven spacing between texts.
Add captions or transcripts to videos

In my next article, we'll look at how to test your website for accessibility.

If you found this article helpful, please like and consider sharing it with others who may also benefit.

A guide to web accessibility (A11y)

Elizabeth — Wed, 24 May 2023 09:03:59 +0000

Have you ever attempted to navigate a website solely using your keyboard due to a trackpad malfunction or simply by choice, only to discover that certain functions cannot be performed without a mouse or trackpad?

Have you ever experienced a temporary physical limitation, rendering your arm unusable and making the navigation of certain applications or websites excessively complicated?

If your answer is affirmative, I sincerely apologize for any inconvenience caused, and I can empathize with the frustration you must have felt.

It is important to recognize that individuals with permanent disabilities may encounter difficulties when attempting to use certain applications and websites. In fact, a significant number of applications overlook their needs.

I must admit that I have been at fault for developing applications and websites without fully considering the accessibility requirements of all users and while that is changing I know there's still a lot to learn but I'll share what I know so far here in this article.

What is Web Accessibility?

Web accessibility, often referred to as a11y (a numeronym for "accessibility"), entails constructing a web platform that ensures seamless interaction for individuals with disabilities, granting them an equivalent user experience to that of others.

Throughout this article, I may use the terms "Web Accessibility" and "a11y" interchangeably.

Disabilities come in various forms, some of which have a greater impact on digital interactions than others. It is crucial to consider the needs of all individuals, irrespective of their disabilities, and incorporate accessibility best practices at every stage of your product's lifecycle, encompassing planning, design, and implementation.

Types of Disabilities

Disabilities can impact individuals in various ways, even if they share the same type of disability. Additionally, certain disabilities may not be immediately apparent. Here are some examples of disabilities that can affect individuals:

Visual impairments:

These include blindness, color blindness, blurred vision, low vision, and night blindness. People who are visually impaired commonly use screen readers, magnifying tools, or text-to-speech software as an assistive tool.

Hearing impairments:

This category encompasses individuals who are partially or completely deaf. Commonly used assistive tools for individuals with hearing impairments include hearing aids, video captions, and video transcripts.

Cognitive impairments:

This can manifest as developmental delays, dementia, ADHD, or autism. Individuals with cognitive impairments usually use text prediction or screen readers as an assistive tool.

Mobility impairments:

This category includes individuals with amputations, arthritis, or spinal cord injuries. Individuals with mobility impairments might use speech input, adaptive keyboards, and braille notetakers as assistive tools.

Speech impairments:

This category encompasses conditions such as stuttering or articulation errors. Some individuals with speech impairments might use speech-generating devices or electronic fluency devices as an assistive tool

You can read more about the different types of disability here

It's worth mentioning that accessibility (a11y) goes beyond benefiting people with disabilities. There are others who can also reap the rewards of an accessible platform. As an example, I personally experience migraines, and when I encounter a platform without a dark mode option, it becomes difficult for me to use.

Why is Web Accessibility Important?

Web accessibility is important as it guarantees equal access and usability of web platforms for people with disabilities. In today's world, the web serves as a vital platform for communication, information sharing, e-commerce, and accessing various services. It plays an essential role in our daily lives, and everyone must have the opportunity to fully engage in the digital world.

Here are some key reasons why web accessibility is important:

Website traffic impact:

An accessible website helps you reach a wider audience, when you make provision for everyone using your platform you encourage greater engagement from the visitors to your website, resulting in increased website traffic.

Inclusion and Equal Opportunity:

Web accessibility fosters inclusivity by eliminating obstacles and ensuring equitable access to information and services. It empowers individuals with disabilities to navigate and engage with websites efficiently, enabling their active involvement in education, employment, e-commerce, social interactions, and various facets of society, just like everyone else.

Better Website SEO:

Many SEO guidelines are in line with accessibility (a11y) guidelines, such as using alt text and employing proper headings. By making your website inclusive, SEO crawlers can easily comprehend your platform.

Legal impact:

In certain regions like the EU, Canada, Japan, and the UK, there is a legal requirement to ensure accessibility for your platform. You can learn more about these requirements here. Adhering to accessibility standards not only makes sense for your business in terms of compliance but also reduces the risk of potential lawsuits.

However, avoiding legal issues or personal benefits should not be the sole motivation for focusing on website accessibility. As developers and designers, it is our responsibility to ensure that all users have a positive experience, regardless of the means they choose to access our platform. Let's prioritize accessibility because we have to create an inclusive environment for everyone.

Accessibility Principles

The W3C (World Wide Web Consortium) has established a set of accessibility requirements for digital platforms and tools, which are recognized internationally as the standard for web accessibility. These principles ensure that your platform offers:

Perceivable information:

This principle ensures that your users can perceive all essential information displayed on the screen. It involves providing text alternatives for non-text content. You can do this by:

Adding descriptive alt text to images
Using action words for icons, such as "Next" for a next arrow icon in a carousel
Including captions or transcripts for videos
Applying labels to form inputs

Operable user interface

This principle ensures that your users can effectively operate your platform, locate content, and have sufficient time to read and interact with the content. You can make your platform operable by:

Providing a keyboard alternative for mouse events
Allowing users enough time to fill out forms or read content
Providing controls for your videos
Ensuring that keyboard focus is visibly indicated

Understandable information

This means that your users should be able to understand the information on your platform including content read by text-to-speech. examples of these include:

Using clear and concise error messages
Specifying the language of text content
Using plain and straightforward language, providing definitions for unfamiliar terms

Robust content

This principle ensures that your platform is compatible with various browsers and assistive technologies like screen readers. Examples of following this principle include:

Testing your platform using only the keyboard or a screen reader to verify accessibility
Creating a responsive platform that adapts well to different screen sizes and devices

It's important to recognize that building an accessible platform goes beyond mere compliance with rules or the fear of legal repercussions. It's about guaranteeing that your platform is accessible to all individuals who have internet access and enhancing their overall web experience.

In my next article, I'll be sharing some a11y guidelines I follow when building a website or web app.

If you liked this article kindly tap the heart icon and share it with others who might like it.

Please be aware that this article intends to provide information. If you come across any inaccuracies or misinformation in this article, please feel free to contact me or leave a comment in the section below, and I will gladly review it. Thank you.

Resources:
https://www.w3.org/WAI/tutorials/images/decision-tree/
https://www.w3.org/WAI/fundamentals/accessibility-principles/

My open-source experience via SCA Contributhon

Elizabeth — Wed, 28 Apr 2021 16:42:01 +0000

This month has been exciting for me, I got into open-source via the contributhon by She Code Africa program, which made it less difficult for me to understand what needs to be done. I will be sharing a summary of my experience and currently merged PRs in this post.

My Experience

When I got a mail from SCA (She Code Africa) that I was part of the selected participant for the program, I felt so excited and scared at the same time because I used to think open-source was for some special set of people😅

I had the opportunity to contribute to Layer5 as a frontend developer. Because it was a program from SCA we were assigned to mentors and a person of contact.

The mentors assigned to my team were Jash Patel and Chinmay Mehta and Ruth Ikegah was our person of contact for the program.

The Layer5 team has several repositories and all I just had to do is find an issue I am interested in working on and then asking for it to be assigned to me.

Making contributions

Once I found an issue I could work on (it is usually recommended to select a beginner's friendly issue), I comment on the issue asking for it to be assigned to me to work, once it has been assigned and worked on, we were required to "sign off" our commits. That was the first time I was hearing about signing off a commit and I decided to read up on what it means.
In summary - The purpose of "--sign-off" is to track who made a particular change or added a feature.

Here's an example of signing off a commit

git commit --sign-off -m "fixed a footer glitch"

here's how it'll look like in a PR

After pushing the commit and creating a pull request, two of the site maintainers will need to approve the work before it's been pushed.

Attending community meetings

Every week we attended community meetings to discuss new issues or features, welcome and onboard newcomers, and discuss recent changes. Personally, I pick issues during these meetings.

The community

The slack channel is where every other thing happens. This is actually the first time I will be among a very diverse team.

This is one of the many things I will come to like about open source

Personally, I felt welcomed in the community, I can freely ask any question when I got stuck or even share something new.

Project Report Details

Summary of work done

I currently have two pull requests merged in the layer5 meshery.io repository.

Here's a link to a document that summarizes the work done

I currently have some pull requests waiting for approval and I'll be updating them as soon as they're merged.

Challenges faced

My major challenge was when I always forget to sign off my commit. 😅

I also had issues jumping into the codebase to make changes, because I had no form of experience with Jekyll. However, the community was helpful with that. I asked questions and got valid and detailed answers. I also wasn't very familiar with gatsby but a stack overflow was really helpful.

Lessons learnt

One of my favorite lessons was realizing how easy anything can be if I put my mind to it. I used to think open-source was for professionals with over 10 years of experience in tech. It sounds so absurd thinking of it now😂

I also understand why it is important to write clean code because if Layer5's codebase was complicated it would have been very difficult for me to jump into the codebase and start editing.

Jekyll and Gatsby are now familiar to me.

Next Steps

The last few weeks in April have been amazing for me or The past month has been amazing for me and I really look forward to making more contributions to layer5 and other open-source communities later on. Open source is amazing and what's even cooler is that great feeling you get when the maintainers approve your pull requests.

Creating a custom hook in React

Elizabeth — Fri, 12 Mar 2021 22:44:13 +0000

Hello there, thank you for your feedback and comments during this series, We've covered the main hooks provided by React, in my last post we covered useReducer. We'll be looking at how to create a custom hook and some rules to follow. Let's jump right in.

Why would I need a custom hook?

There are many reasons why you'd want to create your custom hook, but the ultimate purpose of custom hooks is to reuse any hook-related logic all across your app. React is all about reusability as we all know.

Before we continue let's go back to the beginning of this series where we talked about the rules of hooks

What are the rules of using hooks

Don't call hooks inside of a loop or conditional statements, or nested functions only call them at top levels
You can only call hooks in functional components or inside of another hook

React has an eslint-plugin that enforces these rules.

I think it's best to add this last one also, this applies to when creating a custom hook.

Always prefix your custom hook name with use so that React compiler will always check if the rules of hooks were applied.

Let us create our custom hook!

We will be creating a hook that gets the size of a screen and returns it.

First, we'll create a file named useWindowSize.js

import { useEffect, useState, useMemo, useCallback } from 'react';
// We can react hooks in our custom hook

const isWindowType = typeof window === 'object';
const useWindowSize = () => {
    const [isClient] = useState(() => isWindowType)

    const getSize = useMemo(
        () => ({
            height: isClient ? window.innerHeight : null,
            width: isClient ? window.innerWidth : null,
        }), [isClient]
    );

    // useMemo because it could cause unnecessary rerender

    const [windowSize, setWindowSize] = useState(getSize);

    const handleResize = useCallback(() => {
        return setWindowSize(getSize);
    },[getSize])

    useEffect(() => {
        if (isClient) {
            window.addEventListener('resize', handleResize);
        }
        return () => window.removeEventListener('resize', handleResize);
    }, []);

    return windowSize;
};

export default useWindowSize;

You'd notice that a custom hook is just like a regular javascript function, except you can use react hooks in them.

Note: I could as well use this example in my component but I am creating it as a custom component because I would want to use this across multiple components in my project.

Using a custom hook

We use a custom hook the same way we use other hooks:

import useWindowSize from "./useWindowSize";
// import the hook

export default function App() {
  const { width } = useWindowSize();
  // Use it like you would use a react hook
  return (
    <div className="App">
      {width < 500 ? (
        <div>It's a small screen</div>
      ) : (
        <div>It's not a small screen</div>
      )}
    </div>
  );
}

Congratulations! you've just created a custom hook in react. Now that we're done with this article, how can you put what we've learned into action? Go ahead, explore and come up with something. Don't forget that you're allowed to make mistakes and it's perfectly normal to get errors.

Did this article help you in any way? If it did give a like and follow me for more content like this. If you have any questions or comments please post them in the comment section below. Thanks a lot for reading. Keep being amazing and don't forget to be safe out there.

Nevertheless, Elizabeth Damilola keeps coding

Elizabeth — Fri, 12 Mar 2021 16:51:16 +0000

I have been inspired by a lot of amazing stories I've been reading. As women, no matter how different all have similar experiences based on our gender. We've been treated like second-class citizens and when we speak up (especially in the part of the world where I am from) we aren't taken seriously.

My coding journey

I attended a coding school, here in Lagos to study Software engineering and get a diploma. We were just a few ladies in the whole school, four females in my class. And we were just two who really wanted to pursue a career in tech. However, it was automatically assumed that I would not be able to catch up. I was told by both the trainers and male classmates that I would quit because "Women aren't designed to be in tech". And some even took their time to explain what I could study if I want to be in tech. I was constantly told things like

As a lady you could study digital marketing. It's not that difficult.

Ladies don't do Java, you can do graphics design and be a UI designer.

Just learn WordPress it's what most ladies do

I can build a blog for you, and you can start blogging. A lot of ladies do that.

Because of these statements and more, I decided to prove them wrong and this led me to study harder and always want to be the best in whatever tasks was given to us in class. This worked, I was picked as my team lead for my final project in my semester because I was one of the best in my class. But that didn't stop it. No matter how hard I tried I was always treated as an afterthought.

I pressured myself to not make any mistake because if I did my male peers will make it seem like it was a gender thing.

Workplace experiences

I was employed as a developer in a company but because of my gender, I was also asked to take up the role of writing minutes in meetings.

I offered to mentor new interns at a place of work, but all the interns were male and didn't want a female to mentor them because they "women don't really know much".

Whenever I brought up the topic of equality it was quickly discarded because according to the managers "It's not a problem in Africa".

I once applied for a job and after passing all the interview process I was offered a lower salary because "Ladies don't really spend their money".

I have joined teams where I was the only female and it was automatically assumed that I am not very good. I had to always work extra hard to prove that I am good because of my gender.

Concern

In all of my time coding, I have seen women quit programming, not because coding is too hard, but because they were told that they would never be good enough.

The issue of gender equality cannot be overstressed especially in Africa. It's worrying that a lot of people still don't see it as an issue and in Africa, women still aren't taken seriously.

My advice for allies to support equality in tech is

If you know an African lady who wants to code, offer to be her cheerleader and ask her to join (She Code Africa)[https://www.shecodeafrica.org/]

Conclusion

I keep coding because I want to and I deserve every chance and opportunity, I keep coding because I am a woman who can decide whatever I want, I keep coding because I freaking can. And I will keep coding and be a cheerleader to other women who are trying to find their way in tech.

Understanding useReducer in react

Elizabeth — Fri, 05 Mar 2021 19:14:27 +0000

Hi there, in my last post we covered useCallback in react, and now, we'll be looking at one last hook provided to us by the amazing React team: useReducer

What is the useReducer hook?

Before we continue to explain what the hook is all about let's take a step back and look at what a reducer is.

What is a reducer

If you are familiar with redux then you'd know what a reducer function is.

A reducer accepts a state and an action as an argument and returns a new state as a result. Here's a common example of a reducer

const initialState = {
    loading: false,
    error: false,
    names: [],
};

const reducer = (state = initialState, action) => {
  switch(action.type) {
    case "loading":
      return { ...state, loading: true };
    case "error":
      return { ...state, error: true, loading: false };
    case "success":
      return { ...state, names: action.payload };
    default:
      return state;
  }
}

What is going on here?
The function above is checking for a type and returning a state based on the type that was passed.

Back to useReducer

The useReducer hook is very similar to the useState hook, it allows you to manage a state and rerender the component whenever your state changes, It accepts a reducer and an initial state (like the example above) and returns a new version of the state and a dispatch method based on the action performed in the reducer.

Here is an example of how it is being used:

const [state, dispatch] = useReducer(reducer, initialState);

The hook also takes a third argument that will lazily initialize the state or reset the state back to its initial state. You can read more on the lazy initialization in react documentation

const [state, dispatch] = useReducer(reducer, initialState, initFunc);

Why should I use this?

The useReducer hook is often used when you have a complex state, or where the initial state is dependent on another state.

To understand this better, we need some actions.

Examples

Let us look at a counter using useState

const [num1, setNum1] = useState(0);

  const decrement = () => {
    setNum1((prev) => prev - 1);
  };
  const increment = () => {
    setNum1((prev) => prev + 1);
  };

  return (
    <div className="App">
      Num: {num1}
      <div className="grid">
        <button className="box" onClick={increment}>
          +
        </button>
        {num1 ? (
          <button className="box" onClick={decrement}>
            -
          </button>
        ): (<div />)}
      </div>
    </div>
  );

Now let's look at the same example using useReducer

import { useReducer } from "react";
const initialState = { num: 0 };

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return { num: state.num + 1 };
    case "decrement":
      return { num: state.num - 1 };
    default:
      throw new Error();
  }
}
export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div className="App">
      <div>Num: {state.num}</div>
      <div className="grid">
        <button className="box" onClick={() => dispatch({ type: "increment" })}>
          +
        </button>
        {state.num ? (
          <button className="box" onClick={decrement}>
            -
          </button>
        ): (<div />)}
      </div>
    </div>
  );
}

In our reducer function, we're using the type to determine what action will be performed on the state.

This method is better if we're creating a calculator for example.

Conclusion

There's been a lot of arguments on whether to use the useState hook or useReducer, it actually depends on what you're doing but Kent C. Dodds gave very detailed examples on when to use either in his post.

Thank you so much for reading, In my next post we'll be looking at how to create our very own react hook.

If you have any questions or comments please drop them in the comment below. Don't forget to stay safe and keep being amazing.

Understanding useCallback in react

Elizabeth — Fri, 26 Feb 2021 19:18:07 +0000

Hello there, so we have almost covered the most used hooks in Reactjs. In my last post, we talked about the useRef hook. In this post, we'll be covering the useCallback hook. So let's start right away.

What is the useCallback hook

Use callback is a hook that returns a memoized callback function when one of the dependencies passed to it changes.

Wait! isn't that what useMemo does?

Well, the short answer is NO! Although both hooks are memoizing something they're however returning completely different things. The useMemo hook returns a memoized value while useCallback returns a memoized function

Why `useCallbacks`?

The useCallback hook is very useful when creating an application where some of the functions created are complex and re-rendering the component might make such function run which we don't want, probably because it might slow down the run time.

Let's see some actions

This hook accepts a callback function (useCallback) and a list of dependencies that makes the hook run when the value changes.

Basic usage

import { useCallback } from 'react';

const callbackVariable = useCallback(() => {
     functionCall(a, b)
 },[a, b]);

Example
You'd likely use the useCallback hook alongside the useEffect hook. Sometimes to prevent a continuous re-rendering or infinite loop. Consider the example in the sandbox below.

In the example above, I have 2 components I am working with, the App.js file and the Score.js file. The score component has a useEffect that is updating a state on props change and logging a message to the console.

import React, { useEffect, useState } from "react";

const Score = ({ score }) => {
  const [showScore, setShowScore] = useState();

  useEffect(() => {
    setShowScore(score());
    console.log("Component updating");
  }, [score]);

  return (
   <div>
      <div>Score here: {showScore}</div>
   </div>
  );
}

export default Score;

In the App.js file, we have a clacScore function that is adding 5 to any score the user enters, an input field that allows a user to enter a player name, and a button to toggle the player name. Everything seems to work fine, doesn't it?

There's a problem with our code. When we enter a player's name into our input field a message logs in the console and this also happens when we do anything at all on the page. This is a problem because we only want that message to display when we update the score.

useCallback to the rescue
Try replacing the clacScore function with the code below.

  const clacScore = useCallback(() => {
    return(scoreEntered * 5);
  }, [scoreEntered]);

Now try entering a player name into the input box or showing the player name. And notice that the message in the console only displays when we change the score. This is because we're using the useCallback hook to tell React to only render the Score component when the scoreEntered state is being updated. So the hook has actually helped us boost the performance of our little application.

When should I useCallback?

So I'm sure we can agree that useCallback is awesome. However, that doesn't mean that we should start wrapping all our functions into a useCallback, remember that saying that goes:

Too much of everything isn't cool.

Yeah, that applies for useCallback and useMemo and useAnything (wait! what?😅).

So the useCallback hook should only be used when

We want to do referential equality (because JavaScript sees a function as an object and we testing for equality between objects is quite a hassle in JavaScript)
When we have a complex function (i.e the computation of that function is costly).

Conclusion

Unrelated, but remember that one scene in justice league where they had to bring Superman back to life? they had a perfect reason to bring him back. The same logic applies here. Introducing useCallback means we're inviting some complexities already into our code, so we should have a perfect reason to useCallback in our code.

Thank you so much for reading. In the next section, we'll be covering the useReducer hook. If you have any contributions or comments please drop them in the comment below. Also please follow me for more content like this and stay safe.

Understanding useRef in react

Elizabeth — Fri, 19 Feb 2021 21:05:06 +0000

In my previous post, we talked about useMemo, when we should use it and why we shouldn't overuse it. In this post, we will be looking at the useRef hook and the common use-cases. Let get into it right away.

What is the useRef hook

According to the React documentation,

useRef returns a mutable ref object whose current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.
In short, useRef is kinda similar to the useState hook, except it returns a mutable object and doesn't cause a component to re-render.

To use the value returned from useRef you need to call the current value. i.e

const ref = useRef('Dami')
console.log(ref.current);
// Dami

useRef use cases.

One of the common useCase for useRef is to use it as a reference to a dom element. Every JavaScript DOM element has a ref attribute and you can use the useRef hook to get access to that element. eg.

import "./styles.css";
import React, { useRef, useState } from "react";

export default function App() {
  const [name, setName] = useState();
  const [message, setMessage] = useState();
  const inputRef = useRef();

  const lettersOnly = /^[A-Za-z]+$/;

  const testLetters = () => {
    if (name.match(lettersOnly)) {
      setMessage("Success");
    } else {
      inputRef.current.focus();
      setMessage("Please do not enter a number");
    }
  };
  return (
    <div className="App">
      <input
        ref={inputRef}
        placeholder="Do not enter a number"
        onChange={(e) => setName(e.target.value)}
      />
      <button onClick={testLetters}>Check</button>

      <div>
        <small>{message}</small>
      </div>
    </div>
  );
}

In the code above we're using the useRef hook to focus on the input field when a user enters a number into the box.

You'll notice that I am still using useState to hold the value of the content. You would actually want to do this, it is generally a good idea to let react handle your input value in a state instead of using javascript DOM, if not, why else are you using react anyways?

Another common use case for useRef is to know the number of times a component rerenders. Because the useRef hook actually doesn't cause the component to rerender, you can actually use it to target the number of rerenders.

import React, { useRef, useState, useEffect } from "react";
import "./styles.css";

export default function App() {
  const [number, setNumber] = useState();
  const rendered = useRef(0);

  useEffect(() => {
    rendered.current = rendered.current + 1;
  });
  return (
    <div className="App">
      <input value={number} onChange={(e) => setNumber(e.target.value)} />
      <div>I rendered {rendered.current} times</div>
    </div>
  );
}

Conclusion

The useRef hook is one of those hooks that I rarely use but there's more to using useRef.

I hope this was able to add some clarification to the useRef hook. If you have any questions, comments, or suggestions please send them in the comment below. In my next post, we'll be looking into the useCallback hook. Meanwhile, stay safe and keep doing amazing things.

DEV Community: Elizabeth

How to build an accessible tab

Prerequisite

ARIA Authoring Practices (APG)

Tab Behaviors

Accessibility Features

Keyboard Interaction

Implementation

The activateTab Function

What is Motion Sensitivity? How to Design Accessible Web Animations

What is Motion Sensitivity?

How Motion Sensitivity Impacts People

Insights into Related Disorders

So, Why Does this Matter?

How Common is Motion Sensitivity?

How to Identify Motion-Sensitive Triggers in Animations

Rapid or Flickering Animations

Overly Complex Transitions

Bouncing or Elastic Motions

High-Speed Animations

Continuous Auto-Scrolling

Flashing or Intense Color Changes

Rotational Movements

How to Use Reduce-Motion Preferences

Incorporate Reduced Motion Features

CSS prefers-reduced-motion Media Feature

JavaScript Reduced Motion Detection

Test Your Animation on Chrome

Motion Sensitivity Tips and Best Practices

Conclusion

References

How to build an accessible navigation menu

Semantic HTML and aria

Code structure for focus order

Conlusion

How I test a website for accessibility

Elizabeth ・ Nov 14 '23

How I test a website for accessibility

Automated Testing using Lighthouse

Step 1: Fork and activate debug mode on the pen

Step 2: Open Lighthouse on Chrome devtool

Issue 1: NAMES AND LABELS

Issue 2: ARIA

Issue 3: CONTRAST

Issue 4: NAVIGATION

Manual testing

Semantic tags

Keyboard navigation test

Form test

Conclusion

A beginner's guide to building an accessible website

Why a11y is important to me as a developer

Tips for building an accessible Platform

Keyboard Navigation.

Accessible Colors

Animations

Forms

More accessibility tips:

A guide to web accessibility (A11y)

What is Web Accessibility?

Types of Disabilities

Visual impairments:

Hearing impairments:

Cognitive impairments:

Mobility impairments:

Speech impairments:

Why is Web Accessibility Important?

Website traffic impact:

Inclusion and Equal Opportunity:

Better Website SEO:

Legal impact:

Accessibility Principles

Perceivable information:

Operable user interface

Understandable information

Robust content

My open-source experience via SCA Contributhon

My Experience

Making contributions

Attending community meetings

The `activateTab` Function

Why `useCallbacks`?