DEV Community: Abdulqudus Abubakre

Using aria-labelledby for accessible names

Abdulqudus Abubakre — Wed, 12 Nov 2025 10:14:58 +0000

When building UI, we often rely on icons or visual cues that don’t include visible text. While that might look clean, it can leave screen reader users guessing.

aria-labelledby is one of the techniques we can use to give clear context to assistive technologies.

What is `aria-labelledby`?

aria-labelledby lets you reference visible text elsewhere in the DOM to create an accessible name for an element.

It basically tells assistive technology: “Use this other element’s text to label me.”

It’s commonly used when the text that explains an element is located outside the element itself.

<h2 id="dialog-title">Edit Profile</h2>

<button aria-labelledby="dialog-title">
  ✏️
</button>

Here, the button doesn’t have its own text label, but because it references dialog-title, assistive tech will announce “Edit Profile.”

Why use it?

Sometimes we have elements, especially icon-only controls, that need textual context.

There are several techniques:

aria-label="Edit profile"
<button>Edit Profile</button> (preferred)
title="Edit profile"
aria-labelledby="id"

However, aria-labelledby has the highest priority, and if used, its referenced text will always take precedence over any other naming source.

How it works

1) Create an element with descriptive text:

<h2 id="dialog-title">Edit profile</h2>

2) Reference its ID using aria-labelledby on the target element:

<button aria-labelledby="dialog-title">✏️</button>

And that’s it.

⚠️ Important things to note

aria-labelledby has the highest priority among naming sources → It will override aria-label, title, and even visible text

It depends on other elements. If the referenced element is hidden or removed, the accessible name becomes invalid

<button aria-labelledby="label"></button>
<span id="label" hidden>Example</span>

In the example above, if the span is hidden, the accessible name of the button is lost❌.

✅ As a rule of thumb, use aria-labelledby when:

A descriptive text already exists on the page
The label needs to be more than just a plain string
You want to use multiple elements as a label

✅ Learn more

✅ Final Thoughts

aria-labelledby is a powerful tool for providing context, especially when UI patterns scatter text visually.

Just remember:

It takes top priority
It relies on another element
If that reference breaks → the name breaks

When used well, it helps assistive tech users understand your UI as clearly as everyone else.

Automated Testing with jest-axe

Abdulqudus Abubakre — Sun, 22 Dec 2024 19:45:21 +0000

When building web applications, ensuring accessibility should be as important as delivering features or fixing bugs. Automated testing tools like jest-axe make it easy to catch common accessibility issues early in development.

What is jest-axe?

jest-axe is a Jest matcher built on top of the axe-core accessibility engine. It allows you to test your rendered components for accessibility violations, integrating seamlessly with your existing Jest test suite.

Why Catch Accessibility Issues Early?

Addressing accessibility errors early in the development process is crucial for several reasons:

Cost Efficiency: Fixing issues during development is significantly cheaper and faster than addressing them after deployment.
Promotes Awareness: Regularly testing with tools like jest-axe helps developers become more mindful of accessibility considerations, influencing their decisions when writing HTML and designing components.
Preventing Technical Debt: Early fixes prevent accessibility issues from snowballing into larger, harder-to-solve problems.

Setting Up jest-axe

First, install the package:

npm install --save-dev jest-axe

Next, add it to your test file:

import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

Writing a Basic Test

Here’s an example of how you can test a simple component for accessibility:

import React from 'react';
import { render } from '@testing-library/react';
import { axe } from 'jest-axe';

function Button() {
  return <button>Click me</button>;
}

describe('Button component', () => {
  it('should have no accessibility violations', async () => {
    const { container } = render(<Button />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });
});

Testing a Vue Component

If you’re working with Vue, jest-axe integrates just as easily. Here’s an example:

import { mount } from '@vue/test-utils';
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

const Button = {
  template: '<button>Click me</button>'
};

describe('Button component (Vue)', () => {
  it('should have no accessibility violations', async () => {
    const wrapper = mount(Button);
    const results = await axe(wrapper.element);
    expect(results).toHaveNoViolations();
  });
});

Benefits

Catch Issues Early: jest-axe helps you identify and fix accessibility problems during development.
Easy Integration: Works with Jest, no steep learning curve.
Actionable Feedback: Provides detailed insights into violations.

Limitations

Automated tests can’t catch everything—manual audits are still necessary for nuanced issues like keyboard navigation or color contrast.
Studies show that automated tools can detect only about 30-50% of accessibility issues. For instance, they excel at identifying missing alt attributes but might miss issues with context or usability.

Wrapping Up

By adding jest-axe to your test suite, you’re taking a solid step towards building accessible web applications. However, remember that no tool can guarantee full accessibility. Combine automated testing with manual checks and user testing for the best results.

Happy testing!

Understanding Accessible Names in HTML

Abdulqudus Abubakre — Tue, 03 Dec 2024 18:13:27 +0000

Accessible names are a key part of ensuring that your web content is accessible to screen reader users. They provide the text that screen readers announce to describe an element, helping users navigate and interact with your content effectively.

This post will explain how accessible names are determined, the order of precedence when multiple naming methods are used, and test your knowledge with real-world examples.

What is an Accessible Name?

An accessible name is a text or label that assistive technologies, like screen readers, announce to describe an element on a webpage. It is a critical part of digital accessibility, enabling users who rely on assistive technologies to understand and interact with web content effectively.

For example:

A button might have an accessible name like "Submit form."
A link might be named "Learn more about our services."

It is best to use visible text as the accessible name. Many elements, including <a>, and <button>, can get their accessible name from their content. For example, given <a href="services.html">Learn more about our services</a> , the accessible name of this link is "Learn more about our services"

Without an accessible name, screen readers may announce generic or unhelpful labels like "button" or "link," leaving users confused.

How Accessible Names are Computed

The accessible name of an element is determined using a specific algorithm called the Accessible Name and Description Computation. This algorithm evaluates different text sources in a defined order of precedence to compute the name.

For elements like buttons and links, the accessible name is computed as follows:

aria-labelledby: References one or more elements whose text content provides the name.
aria-label: Directly defines the accessible name inline.
Element Content: The visible text inside the element itself.
title Attribute: Acts as a fallback when no other naming methods are provided.

For form inputs (e.g., <input>, <textarea>, <select>), the accessible name can also be determined by the associated <label>Elements: Text within a <label> linked to the input is the primary source for the name.

Examples of Accessible Names in Action

A Button with Visible Text:
```
<button>Submit</button>
```
The accessible name is "Submit"
A Button with an Icon and aria-label:
```
<button aria-label="Settings">
  <svg>...</svg>
</button>
```
The accessible name is "Settings"

An Input Field with an Associated <label>:

<label for="search-box">Search</label>
<input id="search-box" type="text">

The accessible name is "Search"

Precedence of Accessible Names

The computation differs slightly for various element types when it comes to determining an element's accessible name, but the general order of precedence is as follows:

aria-labelledby
- References one or more elements whose text content provides the name. This takes the highest precedence across all element types.
aria-label
- Provides an inline label directly on the element.
Associated <label> Element (for form inputs):
- Text content within a <label> associated with a form control (e.g., <input> or <textarea>) is used as the accessible name.
Element Content:
- The visible text inside the element, such as the content of a <button> or <a> tag.
alt Attribute (for <img> Elements):
- Describes the content or purpose of an image.
title Attribute:
- Acts as a fallback and is used only if none of the higher-priority naming methods are provided.

Test Your Knowledge: Accessible Names

Below are examples of HTML elements. For each, try to determine what the accessible name (announced by a screen reader) would be. Then, check your answer!

Element with Text Content and aria-label
```
<button aria-label="Submit form">Submit</button>
```
What do you think the accessible name is?

Answer:
"Submit form"
The aria-label takes precedence over the visible text content.
Element with aria-labelledby and title attribute
```
<span id="tac">I agree to the Terms and Conditions.</span>
<span aria-labelledby="tac" title="Agree"></span>
```
What do you think the accessible name is?

Answer:
"I agree to the Terms and Conditions."
The aria-labelledby attribute takes precedence, so the title attribute is ignored.
Button with aria-labelledby and aria-label
```
<div id="label2">Profile Settings</div>
<button aria-labelledby="label2" aria-label="Settings"></button>
```
What do you think the accessible name is?

Answer
"Profile Settings"
The aria-labelledby takes precedence over the aria-label.

How did you do?

Understanding how accessible names are determined is essential for creating web content that is usable for everyone. By following the rules of accessible naming and testing your work, you can ensure a better experience for assistive technology users.

Key Takeaways

Accessible names are essential for improving usability for screen reader users.
All controls elements (e.g buttons, links) should have an accessible name
Use attributes like aria-labelledby sparingly as it has the highest order of precedence and calculating the name of an element with aria-labelledby can be complex and reference hidden content as well
Make sure to test with screen readers to be sure what gets announced to the user.

Hiding Elements in CSS: The Accessible Way

Abdulqudus Abubakre — Sun, 17 Nov 2024 18:27:00 +0000

Hiding elements in your UI is common, but doing so in an accessible manner ensures you don’t unintentionally exclude some users. In this article, we’ll cover three scenarios:

Hiding elements from screen readers.
Showing elements to only screen readers.
Hiding elements from all users, including screen readers.

Each section includes code examples and practical use case

Hiding elements from screen readers

If you want an element to be visible to sighted users but hidden from screen readers, you can use the aria-hidden="true" attribute or CSS.

<div aria-hidden="true">This content is hidden from screen readers.</div>

Use cases

Hiding background images
Decorative icons or visual elements that don’t convey meaningful information.

<button>
  <span aria-hidden="true">+</span>
  Add Item
</button>

Showing elements to only screen readers

To make an element visible to screen readers but invisible to sighted users, you can use the "visually hidden" technique. Tailwind CSS provides a prebuilt utility class, sr-only, for this purpose.

<div class="sr-only">
  This content is only visible to screen readers.
</div>

Writing the sr-only class in CSS would look like this

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Use cases

For labeling interactive elements like inputs without visually displaying the text:

<label for="username" class="sr-only">Username</label>
<input type="text" id="username" name="username">

Providing additional information for screen reader users using aria-describedby

<div class="sr-only" id="instructions">
  Password must include 8 characters, one number, and one special 
  symbol.
</div>
<input type="password" aria-describedby="instructions">

Hiding Input Elements for Custom Radio Buttons
When creating custom radio buttons (or checkboxes), you often hide the native input element and replace it with a visually styled element. To do this accessibly, the hidden input must remain visible to screen readers.

Hiding Elements from All Users

To completely hide an element from both sighted users and screen readers, you can use display: none or visibility: hidden.

.hidden {
  display: none;
  /* or visibility: hidden; */
}

Apply the class:

<div class="hidden">This content is hidden from all users.</div>

TL;DR

Here’s a table summarizing how various CSS attributes affect visibility for different types of users:

CSS Attribute	Hides for All Users	Hides for Sighted Users	Hides for Screen Readers	Notes
`display: none`	✅	✅	✅	Completely removes the element from the visual and accessibility tree.
`visibility: hidden`	✅	✅	✅	Hides the element visually but keeps it in the layout and accessibility tree.
`opacity: 0`	❌	✅	❌	Makes the element fully transparent but still visible to screen readers and interactive.
`clip: rect(0, 0, 0, 0)`	✅	✅	❌	Commonly used in the "visually hidden" technique; removes visual rendering but accessible.
`position: absolute; width: 1px; height: 1px;`	✅	✅	❌	Used with the "visually hidden" technique; keeps elements accessible to screen readers.
`aria-hidden="true"`	❌	❌	✅	Removes the element from the accessibility tree but leaves it visually present.
`overflow: hidden`	❌	✅ (if out of bounds)	❌	Hides content visually if it overflows the container but does not affect screen readers.
`height: 0; width: 0;`	✅	✅	❌	Hides content visually while keeping it accessible to screen readers.
`z-index: -1`	❌	✅	❌	Moves the element behind others, making it invisible to sighted users but screen reader-accessible.
`opacity: 0; pointer-events: none;`	✅	✅	❌	Makes an element fully transparent and non-interactive, but accessible to screen readers.

Pausing, Stopping, and Hiding Animations with animation-play-state

Abdulqudus Abubakre — Sun, 20 Oct 2024 18:44:52 +0000

When working with animations, it’s essential to ensure they are accessible to everyone. According to WCAG SC 2.2.2: Pause, Stop, Hide, users must be able to pause, stop, or hide animations that last more than 5 seconds. Let's break down how you can use CSS and JavaScript to create an animation that users can control.

A simple animation

We'll start by creating a simple animation using CSS keyframes. This animation moves a box horizontally across the screen.

<div class="animated-box"></div>

<style>
  .animated-box {
    width: 100px;
    height: 100px;
    background-color: #3498db;
    animation: move 4s infinite;
  }

  @keyframes move {
    0% { transform: translateX(0); }
    50% { transform: translateX(200px); }
    100% { transform: translateX(0); }
  }
</style>

Adding play state

Next, we introduce the animation-play-state property. This property allows us to control whether the animation is running or paused. We use a CSS variable, --play-state, to set the default state of the animation.

:root {
  --play-state: running;
}

.animated-box {
  animation-play-state: var(--play-state);
}

Here, we define a --play-state variable at the root level and set its initial value to running. The animation will run initially, but this variable gives us a way to control it later.

Adding control with javascript

We add a button that allows users to pause/play the animation by updating the --play-state variable

<button id="toggle-btn">Pause Animation</button>

<script>
  const toggleButton = document.getElementById('toggle-btn');
  const root = document.documentElement;

  toggleButton.addEventListener('click', () => {
    const currentPlayState = getComputedStyle(root).getPropertyValue('--play-state').trim();

    if (currentPlayState === 'running') {
      root.style.setProperty('--play-state', 'paused');
      toggleButton.textContent = 'Resume Animation';
    } else {
      root.style.setProperty('--play-state', 'running');
      toggleButton.textContent = 'Pause Animation';
    }
  });
</script>

We use getComputedStyle to get the current value of the --play-state variable. Depending on whether the animation is running or paused, we toggle the value and also update the text of the button accordingly.

You can find the complete working example on codepen

By implementing simple solutions like animation-play-state and providing controls for animations, you help create a more inclusive digital experience.

Building Accessible Animations with prefers-reduced-motion

Abdulqudus Abubakre — Sun, 26 Nov 2023 20:17:09 +0000

Animations can be beautiful, but some animations can also be triggering for some users, and that's why electronic devices provide ways to turn off animations, e.g:

Android => Settings > Accessibility > Remove Animations
iOS => Settings > Accessibility > Motion
Windows 10 => Settings > Ease of Access > Display > Show animations in Windows
Windows 11 => Settings > Accessibility > Visual Effects > Animation Effects
MacOS => System Preferences > Accessibility > Display > Reduce motion

To ensure the animations in our web application respect these settings, we need to make use of the prefers-reduced-motion CSS feature to detect the user settings and carry out appropriate actions. In the example below, we have a simple button that by default has a pulse animation;

<button class="btn btn--animated">Fancy Animation</button>

@keyframes pulse {
  50% {
    transform: scale(1.2);  
  }

  to {
    transform: scale(1);
  }
}

.btn {
  background: #577FAE;
  color: #FFF;
  padding: 10px 20px;
  margin: 30px;
  border: none;
}

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

To disable any animation if the user has it turned off using the prefers-reduced-motion feature, we can add the following block to our CSS;

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

And that's it, with just a few lines of code, we're able to make our animated button accessible, which is sufficient to pass the WCAG Criterion 2.3.3

Writing meaningful alt texts

Abdulqudus Abubakre — Fri, 13 Oct 2023 14:04:05 +0000

When talking about techniques to improve accessibility, one topic that comes up quite often is alt (alternative) texts.

What is alt text?

Alt text, sometimes called alt descriptions or alt tags, is a short description in the form of an HTML attribute that we use to give context to an image when it cannot be viewed for some reason. The code below shows how you would add an alt attribute to an image tag in HTML:

<img alt="sample alt text">

Why is it important?

Having an alt text for your media files is important for so many reasons, some of them being:

Accessibility: users with some form of impairment who are not able to see an image would rely on tools like screen readers to describe what that image is.
User experience: when a user has a poor internet connection and is not able to load up an image, having an alt text that shows up, describing the image to the user massively improves the experience.
Search Engine Optimization: having an alt text is good for SEO because your image could easily come up in an image search, hence increasing traffic to your website.

How to write meaningful alt text

Be descriptive but concise: according to web accessibility initiative tips, your alt text should be the most concise description possible of the image’s purpose.
Try to keep the description to no more than a sentence or two. For images that need to have a longer description, consider using the long description technique for complex images.
Avoid using phrases like "image of" or "picture of" because tools like screen readers already announce the presence of an image.
Don't include copyright and photo credit information as part of the alt text.
Provide context: context in an alt text is very important. The same image can have a different description depending on the content of the page. For example, an image of a person at a football field can have an alt text of "Man waiting at the football field for his teammates to arrive" or "Man wearing the new bike boots for his first training session" depending on the content of the web page.
Not all images need an alt text. Some images are meant to be for decorative purposes only and, as such, do not need to have alt texts. To mark an image as decorative so it's not read out by the screen reader, you need to pass an empty alt text like this:

<img alt="">

For images used as links or buttons (functional images), the alt text should be what the link does rather than describing the image. An image of a printer should have the alt text "Print this page" which indicates the function of the image rather than what the image looks like.

In summary, crafting meaningful alt text is a simple yet powerful way to enhance accessibility when executed correctly, but it can also lead to accessibility issues if not approached thoughtfully. The process of composing alt text isn't one-size-fits-all, as it hinges on various factors, including the image's nature, the website's content, and its functionality. Incorporating well-crafted alt text into your application significantly enhances the overall user experience.

Improving UX of your forms

Abdulqudus Abubakre — Wed, 01 Sep 2021 20:09:25 +0000

Forms, without a doubt play an important role in our day to day activities. Whether you're trying to apply for a visa, or you're trying to sign up on an e-commerce platform to purchase an item.

As a developer, making sure these forms are usable should be a top priority. There are a lot of things to worry about already, no one wants to worry so much about filling a form.

In this article, I'd be listing some points I feel can improve the overall experience of filling forms.

Keep Validations Simple

While it can be tempting to add a lot of validations to your form fields, try to keep them as simple as possible. Don't make assumptions based on what you already know. For example, it's very common to find name fields that are restricted to only alphabets when there are names that have hyphen and apostrophe in them.

Another example is validating phone numbers to make sure it matches a certain format (xxx-xxxx-xxxx). Instead, give the users some level of freedom and allow formats like:

01234567892
012 3456 7892

You can then format the phone number in the background before sending it to the backend.

Show Error on Blur

A painful part about filling a form field is when you keep seeing errors as you type ("let me finish typing for God's sake"). Instead of showing errors immediately a user begins typing in an input field, consider waiting until the user is done typing and is about moving to the next field. Another option is to add a delay, say about 500ms after user has stopped typing before showing the error message.

Break Forms Into Steps

Seeing a very long form can be intimidating so it's usually better to split them into steps with some sort of progress indicator. This way, users are more likely complete the form.

Don't Just Disable The Submit Button

A very popular practice is to disable the submit button whenever all validations have not been met. This works, but can be made better but allowing the users click the submit button, then if there are any invalid fields, scroll to that field and show the corresponding error message. This has a better user experience and is also more secure. Just adding the disabled attribute means the user and toggle the attribute from the devtools and be able to submit the button regardless

Use Either Confirm Password Or Toggle Password Visibility

If you have a password field with the options to toggle visibility, then there's no much need to have a confirm password field. Why do I have to confirm password when I can already see the password I entered?
One way to implement this is to check if the password is visible, if yes, then hide the confirm password field, otherwise, show it.

Avoid Clear or Reset Button

While this might seem like a handy feature, it can become painful when a user has filled a long form and is about to click submit, but mistakenly clicked the clear button

Use Appropriate Input Type

This allows the device to show the corresponding keyboard for a particular input. Like showing an @ for en email type, or a number pad for a type tel

Why your z-index isn't working

Abdulqudus Abubakre — Mon, 10 May 2021 09:16:14 +0000

I was building a sidebar recently, and I encountered a bug where the content of the page was always on top of the mobile navbar no matter how high I raised the z-index of the sidebar. This took me a while to figure out and I'm writing this article hoping that someone out there won't waste a lot of time like I did trying to solve the bug.

What is z-index

z-index is a CSS property that allows you to set the stacking order of positioned elements in the DOM. Here's how to specify the z-index from your CSS:

.element {
  z-index: 1;
}

When no z-index is set, the stacking order follows the appearance
of the elements in the DOM.

I set the z-index correctly, so why doesn't it work?

The z-index of an element depends on a number of things, and usually, when these conditions aren't met, the z-index of your element would most likely not take effect.

Here are some of the reasons why your z-index doesn't work;

You set z-index on a static element

By default, every element has a position of static. z-index only works on positioned elements (relative, absolute, fixed, sticky) so if you set a z-index on an element with a static position, it won't work.

A ridiculously large z-index was previously set

You might be working on an existing codebase that had the z-index of an element set to 999 (for example). This would affect the stacking order as only an element with a higher z-index can show on top. So you would need to set the z-index of at least 1000 for the z-index to work. Also, it's good practice to avoid setting large z-index values, that way you can avoid issues such as this.

The parent element has a lower z-index

The z-index of an element can only go as far as the maximum z-index of its parent (it cannot appear in a higher stacking context than its parent). Take for example;

.child {
  z-index: 3;
}

.element-to-cover {
  z-index: 2;
}

.parent {
  z-index: 1;
}

In this case, you want to display the child element over the element-to-cover element so you set the z-index to 3. This should work since it has a z-index higher than the element-to-cover, but because the parent element has a z-index of 1, the child element would not appear above the element-to-cover

Summary

You have to set the position of an element for the z-index to work
Check to see if the element has a lower z-index value than the element you want it to appear over
The z-index won't work if the parent element has a z-index lower than the z-index of your element

This article was originally post on my blog

Font loading strategies: FOIT and FOUT

Abdulqudus Abubakre — Wed, 21 Apr 2021 22:37:02 +0000

Flash Of Invisible Text and Flash Of Unstyled Text are two font loading strategies used in major browsers. This post looks at what they are and how they affect your website.

Custom web fonts have been around for a while now but sadly web browsers still don't have an optimal way of loading them. Web fonts are usually large files and they take quite some time to load on your web page. Different browsers have different ways of handling this delay. While some browsers would show a system font pending when the custom font gets loaded (Flash Of Unstyled Text), some browsers would show blank text until the font has been loaded (Flash Of Invisible Text).

Flash Of Invisible Text (FOIT)

When a custom font is not ready to be loaded, some browsers would hide the text completely while others would only hide it for a few seconds. Browsers like Chrome and Firefox would hide the text for 3 seconds and if the font doesn't get loaded by then, a system font would be loaded. Other browsers like Safari completely hides the text until the font is ready to be loaded. The image below is a screenshot of a lighthouse audit that shows what happens when you don't account for FOIT in your application

Flash Of Unstyled Text (FOUT)

In this case, before the custom font is loaded, a system font is loaded by default and swapped out as soon as the custom font is ready. This is the preferred behavior because showing a flash of invisible text has a significant effect on your websites overall performance.

In this article, we will look at two ways to avoid showing the invisible text. The first option, which is quite simple and straightforward is to add the font-display: swap rule to our CSS. Such that when you want to setup your custom font, we tell the browser to load a system font and swap it out when our font is done loading. Here's how that would look like:

@font-face {
  font-family: Poppins;
  font-display: swap;
}

This method is quite straightforward but sadly, not supported by all browsers, So, if you're looking to account for all browsers, this might not work for you.

Another method, though involves more code but can work across all browsers involve the use of an external library called FontFaceObserver. To make this work, you have to;

Make sure you don't use the custom font in your CSS on initial page load.
Use the FontFaceObserver library to detect when the font is loaded.
Update the page styling to use the custom font.

Here's a codelab by google that helps understand how to use the FontFaceObserver library.

TL;DR

FOIT and FOUT are font loading strategies used by browsers to load custom fonts.
FOIT shows an invisible text while FOUT uses a system font until the font is loaded.
FOUT should be preferred over FOIT.

Browser	Default behavior
Edge;	Uses system font until the custom font is ready (FOUT)
Safari;	Hides text until the custom font is ready (FOIT)
Firefox;	Initially hides text for 3 seconds. Uses system font after that until the custom font is ready (FOIT & FOUT)
Chrome;	Initially hides text for 3 seconds. Uses system font after that until the custom font is ready (FOIT & FOUT)

Styling file inputs like a boss

Abdulqudus Abubakre — Fri, 21 Aug 2020 15:24:38 +0000

HTML elements have default styles applied to them by individual browsers. These styles could vary depending on the browser, and applying your own custom styles could range from being very easy to unnecessarily complicated (sometimes impossible).

In this article we would be going through how to style file inputs, which happens to be one of those difficult elements to style using CSS.

If you've worked with file inputs in your application, you'd know that the default style doesn't look so nice. Here's an example of how it looks in chrome and firefox in case you're wondering.

The good news is, we can fix this...the bad news is we won't be able to use the "conventional" method.

Styling File Inputs

Let's create a simple file input in our HTML.

<div class="file-input">
  <input type="file" id="file" class="file">
  <label for="file">Select file</label>
</div>

To style a file input, the first thing we would need to do is get rid of the default file input.

Hiding the input

.file {
  opacity: 0;
  width: 0.1px;
  height: 0.1px;
  position: absolute;
}

You might be thinking, why not use display: none to hide the input. Well the problem with that is the input field would be removed from the layout and then become inaccessible to people using screen readers which would be very bad.

Another important thing to note is the label. With file inputs, clicking on the label also opens up the file picker, so we can use that to our advantage and style the label anyway we want.

Styling the label

Now that we've hidden the default input, we can decide to style the label however we want. For simplicity sake, let's just make it look like a button.

.file-input label {
  display: block;
  position: relative;
  width: 200px;
  height: 50px;
  border-radius: 25px;
  background: linear-gradient(40deg, #ff6ec4, #7873f5);
  box-shadow: 0 4px 7px rgba(0, 0, 0, 0.4);
  display: flex;
  align-items: center;
  justify-content: center;
  color: #fff;
  font-weight: bold;
  cursor: pointer;
  transition: transform .2s ease-out;
}

Accessibility

So we've been able to style the label to look like a button, but that's not all. We need to add some sort of indications to the label for when people hover on the field, or try to focus on the file field using the keyboard. I'm just going to do something simple here and increase the size of the label when that happens.

input:hover + label,
input:focus + label {
  transform: scale(1.02);
}

We can also decide to add an outline to the label on focus

input:focus + label {
  outline: 1px solid #000;
  outline: -webkit-focus-ring-color auto 2px;
}

The -webkit-focus-ring-color is used to get the default outline look on webkit browsers like chrome or safari. For non webkit browsers, a black outline would be applied to the element.

Javascript Enhancements

We can use JavaScript to display the name and size of the file selected. This would create a slightly more natural feel to the custom field. So let's modify our HTML and CSS a bit.

<div class="file-input">
  <input type="file" id="file" class="file">
  <label for="file">
    Select file
    <p class="file-name"></p>
  </label>
</div>

.file-name {
  position: absolute;
  bottom: -35px;
  left: 10px;
  font-size: 0.85rem;
  color: #555;
}

Finally, we would add an event listener to the file input and reflect the name and size of the file below the label.

const file = document.querySelector('#file');
file.addEventListener('change', (e) => {
  // Get the selected file
  const [file] = e.target.files;
  // Get the file name and size
  const { name: fileName, size } = file;
  // Convert size in bytes to kilo bytes
  const fileSize = (size / 1000).toFixed(2);
  // Set the text content
  const fileNameAndSize = `${fileName} - ${fileSize}KB`;
  document.querySelector('.file-name').textContent = fileNameAndSize;
});

Here's how everything looks.

And that's it for the file input. You could decide to style this however you want to get the behavior you want, it's up to you. Happy styling!😁😁

Don't Just Say Hi....

Abdulqudus Abubakre — Sat, 01 Aug 2020 05:14:16 +0000

As tech enthusiasts, we would at some point, for one reason or another need to reach out to someone. It could be that you need help with a bug in your code, career advice, or mentorship....whichever case, just go straight to the point.

You're most likely going to get a response if you go straight to the point rather than just saying hi or hello.
You'll save yourself a lot of time, especially if you have a bug you need help with. Rather than going through the whole process of exchanging pleasantries, just go straight to the point.

Imagine I have a bug in my code I've been trying to fix, and I need help from someone. Rather than just saying hi and waiting for a response, here's how I would reach out to them

Hi, I have issues trying to setup docker on my computer, I keep getting xxxx error message. Here's a screenshot of the error

Or I could go further to introduce myself
Hi, I'm xyz and I got your number from abc. I get this error in my console, it says xxxx and it happens whenever I click on xxxx button. Here's the function called whenever the button is clicked

It's that simple. You don't have to go through the whole hello, how are you, how's your day going..... Like I said, it saves you a lot of time, and you're most probably going to get a response.

Note: This is just my opinion. If you have contrary opinions and you would like to discuss them with me, my DMs are open on twitter, feel free to reach out...and don't just say hi 😉

DEV Community: Abdulqudus Abubakre

Using aria-labelledby for accessible names

What is aria-labelledby?

Why use it?

How it works

⚠️ Important things to note

✅ Learn more

✅ Final Thoughts

Automated Testing with jest-axe

What is jest-axe?

Why Catch Accessibility Issues Early?

Setting Up jest-axe

Writing a Basic Test

Testing a Vue Component

Benefits

Limitations

Wrapping Up

Understanding Accessible Names in HTML

What is an Accessible Name?

How Accessible Names are Computed

Examples of Accessible Names in Action

Precedence of Accessible Names

Test Your Knowledge: Accessible Names

How did you do?

Key Takeaways

Hiding Elements in CSS: The Accessible Way

Hiding elements from screen readers

Use cases

Showing elements to only screen readers

Use cases

Hiding Elements from All Users

TL;DR

Pausing, Stopping, and Hiding Animations with animation-play-state

A simple animation

Adding play state

Adding control with javascript

Building Accessible Animations with prefers-reduced-motion

Writing meaningful alt texts

What is alt text?

Why is it important?

How to write meaningful alt text

Improving UX of your forms

Keep Validations Simple

Show Error on Blur

Break Forms Into Steps

Don't Just Disable The Submit Button

Use Either Confirm Password Or Toggle Password Visibility

Avoid Clear or Reset Button

Use Appropriate Input Type

Why your z-index isn't working

What is z-index

I set the z-index correctly, so why doesn't it work?

You set z-index on a static element

A ridiculously large z-index was previously set

The parent element has a lower z-index

Summary

Font loading strategies: FOIT and FOUT

Flash Of Invisible Text (FOIT)

Flash Of Unstyled Text (FOUT)

Styling file inputs like a boss

Styling File Inputs

Hiding the input

Styling the label

Accessibility

Javascript Enhancements

Don't Just Say Hi....

What is `aria-labelledby`?