FED Mentor

Why heading order matters in HTML

2024-12-27T00:00:00Z

Heading levels are not about font size. They are all about meaning.

Think of it this way:

<h1> is the page title.
<h2> is a major section within that page.
<h3> is a subsection within that major section, and so on.

While not explicitly a WCAG failure, maintaining proper heading order (h1-h6) improves accessibility. It creates a clear document structure, aids screen reader users and helps search engines understand page content.

Why does order matter?

Screen readers are tools that help people with visual, mobility and cognitive impairments read and navigate web pages. They rely on the heading order to understand the structure and jump directly to sections of interest.

Some people using screen readers rely heavily on shortcuts in the tool to jump from heading to heading.

Search engines use headings to understand the page's topic and how information is organised. This can improve your search engine ranking.

A well-structured page with appropriate headings is also easier for all users to understand and navigate, regardless of disability.

Appropriate heading content

When you consider that headings are meant to communicate content structure like this (Chapter 1, Section 1.1, Subsection 1.1.1), it should become clear that only certain pieces of content are appropriate to be heading elements.

Numbers might be large in a design with a word underneath, like this:

But those numbers wouldn't make any sense as headings. If you saw "80k" on a contents page, you wouldn't understand what that section of content would be about. The numbers have to be read together with their accompanying word to make sense. They are not acting as headings — as titles — for any other content. So you know they shouldn't be headings.

So, in assessing what should be headings, think:

"Is this a title for some nearby content?"
If no, then it's not a heading. Maybe it's a paragraph or list item
If yes, then it's a heading.
So the next question is, "Does this heading and its content belong to the section above?" (i.e. Is the heading a subtitle?)
If yes, then it needs to be one level below it's parent heading.
i.e. If the main section has a h2, this would be a h3.

What if designs lack headings?

Consider whether headings are necessary to understand the content of the page. It might make sense visually because of how content is grouped. But would you understand this if reading the content (or having the page read to you by a screen reader)?

If headings are missing from a design, you may need to raise that with the designer, or you may need to add additional screen reader-only (visually-hidden or sr-only) headings on the page.

For example, take a look at this design for a News website:

There is a big heading visible in the design, but that is for a featured article, and not an appropriate heading for the whole page. In fact, visibly there are no obvious candidates for the page's h1 element... If you consider what we've covered about headings, this page may end up with a heading structure as follows:

<h1 class="sr-only">News Homepage</h1>
<h2 class="sr-only">Featured Post</h2>
<h3>The Bright Future of Web 3.0?</h2>
<h2>New</h2>

See if you can work out the rest! (Remember some headings may need links inside so people can reach these articles.)

Summary

Only use heading elements where it is appropriate to do so.

In essence, proper heading order:

Improves accessibility, making web pages easier to navigate.
Enhances Search Engine Optimisation (SEO) because page content and structure is easy for bots to digest.
Makes your website more intuitive to use.

Key takeaway: Always use headings in a logical order (<h1> to <h6>) to create a clear and accessible structure for your web pages.

How to ask for help (and actually get it!)

2024-12-26T00:00:00Z

1. Set up a repo and deploy early

Git version control is key to success anyway, so get into this habit now if you don't alreay do this as a first step in every project!

Having a fresh git repository set up from the start will help you to get help quickly. Committing regularly not only tracks your progress but also allows you to easily share your code with others.

As well as the code repository link, we need to see the result. Show, don't tell. Deploy your work (even a basic, unfinished version) to a live environment — like Netlify or Vercel (or even Github Pages for simple projects). This gives your mentor a clear picture of the issue and allows them to interact directly with your code in the browser.

Code is readable, but screenshots, photos and videos are usually not. Instead of sharing screenshots of your code, just provide those links to your repository and deployed version up front!

Context matters, and often we need to see more of it than you think. Being able to see how files are structured in the project, to check a completely different file to what you expect, or to inspect in browser is often essential. And for some issues — like styling problems — it is simply FAR quicker to debug in browser.

Provide both links, so we can find the information we need quickly and efficiently to be able to help you.

3. Be specific!

Saying things like: "It's not working" just isn't helpful. Clearly articulate the problem, like "My button isn't changing color on hover" or "I'm seeing a horizontal scrollbar unexpectedly".

Try to explain how you've already tried to solve the problem, what isn't working as you expected it to, or any steps you've followed along with what happened as a result.

For example, this is a great start: "The form is not submitting correctly. I'm getting an error in the console". But we need more information than that. If you're encountering errors, copy and paste the exact error messages so we can see what you see.

Similarly, if you are encountering problems deploying, list out every command you've done, in order and include what the output was in the console each time. In these cases you can take screenshots of the console, but it helps to write out specifics of any errors.

4. Visual aids can help

With some queries, some extra information or context can really help.

For example, if your question relates to design, include sketches, mockups, or links to those designs.

If we need specific images or extra information to understand your issue, don't hesitate to provide them! Just try to make sure they are clear and have relevant parts highlighted where necessary.

5. Put yourself in a mentor's shoes

Remember that locker-room scene from Jerry Maguire when he yells "Help ME help YOU" over and over again?

I think of this almost every day in the context of trying to help people with front end developmemt or accessibility queries. It's so frustrating for us when we can't help you because of simple steps you've not taken (like sharing code AND deployed links).

Bear in mind that mentors are busy. Make it easy for us to understand your problem. Think about what information someone with no prior context of the problem will need in order to understand and answer it.

The more organised and clear you are, the quicker and easier it will be for everyone.

6. Embrace ALL feedback

When experienced professionals look at your requests for help, we bring our own expertise and will look at the problems through our own lens. Often that means we will look beyond the question you've asked.

Welcome feedback that extends beyond your initial question. Mentors may identify areas for improvement you hadn't considered and that's a great thing, even if it doesn't answer the original query at all!

Also, consider that sometimes the best solution may differ from what you initially envisioned. Be open to alternative approaches and suggestions.

7. Be prepared for advice to "Step back"

Mentors may sometimes suggest revisiting earlier parts of your project, moving back to an easier challenge, or even starting all over again. This isn't meant to be discouraging and doesn't come from a desire to be overly-critical or perfectionist. It's not personal either.

If this happens to you, please understand that mentors have your best interests at heart.

When learners overstretch themselves, move onto projects they're not ready for, or are missing some foundational understandings, they're setting themselves up for frustration and failure.

We want to help you build strong base. Unfortunately, just as with phyisical building construction, sometimes that means digging up what's there and re-laying those foundations!

It feels horrible to be told you need to go back a step (or several), but it's worth it in the long run, trust me. Once those foundations are solid and those missing pieces are in place, you'll start to make much faster progress with your learning.

8. Understand the "Issue Dump"

I do this a lot. My feedback style is generally a bulleted list of problems or potential improvements I can spot in someone's front end code. It may come across as abrubt sometimes, but this is simply efficiency in action.

When a mentor lists out multiple issues, it's an effort to help you efficiently address potential problems upfront.

There isn't often time for long conversations, calls or videos, although I will always try and answer follow up queries if things are unclear.

It's also good to get used to this while you're learning... because once you're on the job you will encounter long bug lists and comments on your pull requests regularly!

9. Leverage the Frontend Mentor Discord server

The Frontend Mentor Discord server is a valuable resource for anyone learning front end development.

Just make sure you use the appropriate channels (like #🤔-help for questions or #🦄-random for random chat!) and follow the server rules.

It's a very active community. There are loads of questions already answered and feedback you can search through. And there are lots of talented people on hand to help you learn.

10. There are NO stupid questions

Don't be scared to ask!

I'll add: Don't be down on yourself, don't call yourself a "noob" and don't apologise for asking more questions. We've all been there. That's how we learn — by asking!

Everyone is on their own journey, and everyone has their own strengths. Even after decades, I still learn new things every day. I may be an expert in some areas but there are plenty of others where I am woefully ignorant.

Remember that we're all learners, even experienced senior developes. Every one of us writes bad code or builds inaccessible stuff sometimes and looks back on it horrified later on. The point is, we learn, we improve, we grow. There is nothing remotely shameful about that.

Never delete solutions after receiving feedback or feel ashamed of making mistakes, no matter how many there are. You'll want that work and that feedback to look back on later and celebrate how far you've come.

Ask. Learn. Refactor. Ask again...

Summary

My top 10 tips to be a good mentee and get help with front end are:

Set up a repo and deploy early
Share links, not screenshots
Be specific
Visual aids can help, if needed
Put yourself in a mentor's shoes:
Embrace ALL feedback
Be prepared for advice to "Step back"
Understand the "Issue Dump"
Leverage the Frontend Mentor Discord server
There are NO stupid questions

By following these tips, you'll become a more effective learner and be able to access help more quickly when you need it.

Join me for free lunch & learn sessions on digital accessibility!

2024-09-07T00:00:00Z

Although I'm still actively mentoring Front End Developers (FEDs) as much as I can, my real passion has always been inclusion and accessibility. So when some opportunities to deliver accessibility-related online talks came my way through my work at Nomensa, I jumped at the chance!

I've delivered training sessions before and done talks at tech-focused events in the past, but these sessions have rarely been open to the public... until now.

A brilliant organisation that delivers accessibility apprenticeships — Purple Beard — is hosting a series of free monthly "lunch and learn" online sessions and I'll be delivering the next two.

You are welcome to join!

Emerging trends in digital accessibility

🗓️ Tuesday, 10th September 2024 at 12.30pm-2pm (BST time)

Let's look at the GOOD, the BAD and the UGLY in recent trends! In this session we explore the current state of digital accessibility, examining both promising advancements and persistent challenges. We'll look at the role of AI in accessibility testing, design and development, and learn about some best practices and pitfalls to avoid.

Youtube video: Emerging Trends in Digital Accessibility (2024)

Let me know what you think of the session. I also sent around these links to attendees afterwards, based off the questions we had at the end:

Maturity Models & Accessibility Assessments:

W3C Accessibility Maturity Model
“Quick” scorecards: Nomensa Accessibility Assessment Tool and Hassell inclusion's maturity scorecard

How to identify issues and prioritise an accessibility backlog

🗓️ Tuesday, 8th October 2024 at 12.30pm-2pm (BST time)

Learn how to effectively tackle accessibility issues by understanding their impact and complexity. Discover practical methods to identify, categorise and assign actions to different teams. Leave with actionable tips to run a workshop exercise and create a clear roadmap for improving digital accessibility.

Youtube video: Not all issues are created equal - How to prioritise an accessibility backlog (2024)

I hope you find the session beneficial. Let me know if you need help building an accessibility backlog that's ordered by priority.

More "lunch and learns"

I am really pleased to be connecting more with Purple Beard. If you're interested in a career in accessibility where you can help break down barriers and build up inclusion, you really should check them out!

Follow Purple Beard training on LinkedIn to get notified when the Zoom registration opens for future sessions.

Speaking requests

I am always happy to consider new speaking engagements.

You can either request this via Nomensa, where we have a whole team of experienced consultants ready to share expertise as well as myself, or contact me directly to discuss.

Let's build an accessible disclosure (show/hide accordion)

2023-08-12T00:00:00Z

In this guide, we'll explore how to create an accessible pattern for expandable content.

By the end, you'll have a solid pattern in your pocket you can adapt for accordions, mobile navigation toggles (often called 'burger' menus) and any other components that reveal content following user interaction. The pattern I'm teaching should work for all users, no matter what modality they're using (keyboard, screen reader, switch control, voice control or any others).

💡 I'll do separate posts specifically looking at accordions and mobile navigation, as there is some extra 'nice to have' functionality you may want in those!

Let's get started!

It's really important to:

open disclosures with a button click (not hover or mouseover)
use aria-expanded to communicate state to assistive tech
use aria-controls to programmatically link buttons with the content they're controlling for the JAWS screen reader
give the button an accessible name (usually with child content, although it can be done with aria-label)
Test any transitions or animations with assistive technologies
Turn off or reduce animations for those who prefer reduced motion

HTML Structure

Start by setting up your HTML structure with appropriate meaningful elements. Disclosures should always be triggered by a button click, which reveals content within a sibling element, such as a div.

The button must have an accessible name, which we'll do by placing some text inside the button.

Using aria-expanded on the button is also essential. This is what will communicate 'state' to screen readers, announcing the button as something like "Button, Expandable, Collapsed" or "Button, Expandable, Expanded".

Optionally, it's good to also include aria-controls, which will point to the unique ID of the content being toggled. This isn't used by all screen readers, but is used by one called 'JAWS'.

Lastly, we will want to give the button an icon to help people understand that this will trigger some expanding content. Note, this is decorative so should be hidden from the accessibility tree.

Here's what this HTML looks like:

<div class="disclosure js-disclosure">

  <button
    aria-expanded="false"
    class="disclosure__button js-disclosure-btn"
    aria-controls="content"
  >
    <!-- Accessible name goes here-->
    Disclosure trigger
    <!-- An icon to indicate this is a disclosure -->
    <svg
      class="disclosure__icon"
      aria-hidden="true"
      focusable="false"
      xmlns="http://www.w3.org/2000/svg"
      viewBox="0 0 10 6"><polygon points="8.97 0 5.01 3.9 1 0.03 0 1.03 4.96 6 10 1.08 8.97 0"></polygon></svg>
  </button>
  <div class="disclosure__content" id="content">
    <!-- Additional content goes here -->
    <p>Revealed content!</p>
  </div>

</div>

But, there are a few issues with this HTML:

What happens when JavaScript (JS) fails to load or users turn it off? We will want to see all of the content
If we make the content open by default for no-JS users, then hidden once JS loads, it will introduce Cumulative Layout Shift (CLS), resulting in poor site performance.

Progressive Enhancement

To quote MDN:

Progressive enhancement is a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.

We can follow this approach and address those two issues with some additions to our baseline code...

Add an inline <style> at the top of the page that hides revealed content as the page first loads
Add a custom attribute data-state that updates from "no-js" to "ready" once JS successfully loads
Make the button disabled by default and give it a title explaining that JS needs to load for it to function
Add an inline <noscript> at the end of the page that reveals all content if there is no JS

We'll also update these properties in the JS file later.

These simple changes should set us up well for a performant progressively-enhanced version of the disclosure.

<style>
  /**
   * Hide the menu during the 'no-js' state
   * to solve Cumulative Layout Shift.
   */
  [data-state='no-js'] .disclosure__content {
    display: none;
  }
</style>

<div class="disclosure js-disclosure" data-state="no-js">
  <button
    aria-expanded="false"
    class="disclosure__button js-disclosure-btn"
    aria-controls="content"
    disabled
    title="This button becomes functional once JavaScript is active"
  >
    <!-- Accessible name goes here-->
    Disclosure trigger
    <!-- An icon to indicate this is a disclosure -->
    <svg
      class="disclosure__icon"
      aria-hidden="true"
      focusable="false"
      xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 6"
    >...</svg>
  </button>
  <div class="disclosure__content" id="content">
    <!-- Additional content goes here -->
    <p>Revealed content!</p>
  </div>
</div>


<noscript>
  <!-- Show all content if no JS -->
  <style>
    [data-state='no-js'] .disclosure__content {
      display: block;
    }
  </style>
</noscript>

🌟 Thanks to Gerardo Rodriguez for the noscript CLS fix applied in this demo

Write whatever styles you like to make your disclosure component look nice. The important point to note is that we're using the aria-expanded attribute as the hook to trigger content visibility changes.

I prefer this approach over toggling classes or data-attributes because it makes it much easier to spot accessibility bugs! If aria-expanded isn't toggling correctly, the UI will visibly break, as nothing will be revealed, forcing you to fix the root cause (that aria-attribute's state).

// Some basic styles for the demo
.disclosure {
  border: 1px solid #ccc;
  padding: 10px;
  max-width: 50rem;
}

.disclosure__content {
  margin-top: 10px;
}

// Size the icon proportionally to the button's font size
.disclosure__icon {
  height: 1em;
  width: 1em;
  fill: currentcolor;
  transition: transform 0.3s ease-out;
}

.disclosure__button {
  background-color: #222;
  padding: 0.25em 0.5em;
  color: #fff;
  border: 0;
  cursor: pointer;
  // align the icon correctly:
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 1ch;

  // manage keyboard focus
  &:focus-visible {
    outline: solid orange 3px;
    outline-offset: 3px;
  }

  // ! Important functionality hooks
  &[aria-expanded="false"] {
    + .disclosure__content {
      display: none;
    }
  }

  &[aria-expanded="true"] {
    + .disclosure__content {
      display: block;
    }

    .disclosure__icon {
      transform: rotate(-180deg);
    }
  }
}

The above should be fairly self-explanatory. If the button's aria-expanded state is set to "true" we want to reveal the content. If it's false, we want to hide the content.

Add the JavaScript

When adding JavaScript it's helpful to break down what you're trying to do into manageable steps. Here we need to

find all disclosure components on the page
update the custom data-state attribute now that JS has loaded
remove the disabled and title attributes from the disclosure buttons
listen for clicks on those buttons
toggle the aria-expanded boolean values on any disclosure button as it is clicked

Remember, all we are doing in JS is toggling that aria attribute's value so that the state is correctly announced to assistive technology and the styling can use that state. We shouldn't be setting inline styles or toggling anything else. Let your CSS handle the content visibility changes as a styling concern.

// disclosure.js

// get all disclosure components on the page
const disclosures = document.querySelectorAll('.js-disclosure');

// Simple toggle function
function toggleDisclosure() {
  const isExpanded = this.getAttribute('aria-expanded') === 'true';
  this.setAttribute('aria-expanded', !isExpanded);
}

function init() {
  // early return if no disclosures present on page
  if (!disclosures.length) {
    return
  }

  // update state now JS has loaded
  disclosures.forEach(component => {
    component.dataset.state = 'ready';

    const disclosureButtons = component.querySelectorAll('.js-disclosure-btn');

    disclosureButtons.forEach(btn => {
      // initialise button attributes now JS has loaded
      btn.removeAttribute('title');
      btn.removeAttribute('disabled');

      // listen for clicks
      btn.addEventListener('click', toggleDisclosure);
    });
  });
}

// export as JS module
// NOTE: Optional! Call init() instead if not using modules
export default init;

The HTML-only Disclosure

You may be thinking, "Why can't I use the details element instead" for all disclosures? You could do this, but I first recommend you read more about it and make sure it is appropriate for what you are trying to build.

You can read more about the details disclosure element on MDN. And more about its inconsistent browser and assistive technology behaviour thanks to Scott O'Hara and Adrian Roselli.

A note on accordions

If you want to build an accordion component specifically, Adrian Roselli has written a post about how you can adapt the details element for this purpose: Progressively enhanced HTML accordion.

Note, the JS in Adrian's example needs modernising, as he points out in the article. At the time of writing this, his example does not 'toggle' the accordion items either — It does not close and open one on click as I believe it should.

And actually, I disagree that an accordion must always close the others on open. That will depend on the technical requirements for which you are building. I see no problem from a usability perspective with making each accordion item open and close independently, and in fact, I prefer that as a user. It gives me explicit control, it means I can read and compare two sets of revealed content at once, and it reduces unexpected scrolling / jumping around.

See how there are many ways to approach these UI patterns?! It's fine to come to your own opinions on some of these finer details, as long as you consider the options and test thoroughly.

A note on accordions

If you want to build an accordion component specifically, Adrian Roselli has written a post about how you can adapt the details element for this purpose: Progressively enhanced HTML accordion.

See how there are many ways to approach these UI patterns?! It's fine to come to your own opinions on some of these finer details, as long as you consider the options and test thoroughly.

A note on mobile navs

⚠️ The details element should not be used for mobile navigation disclosures. On that point, accessibility professionals are agreed.

Instead, follow a standard JS-disclosure pattern using buttons. There are various options for how to handle the default no-JS versions of mobile menus, which I'm not going into here.

A note on mobile navs

⚠️ The details element should not be used for mobile navigation disclosures. On that point, accessibility professionals are agreed.

Instead, follow a standard JS-disclosure pattern using buttons. There are various options for how to handle the default no-JS versions of mobile menus, which I'm not going into here.

As with all things, I always recommend you test UI patterns as much as you can across various browsers and devices. Verify that the component functions seamlessly and is accessible to all users, including those using different user-agent and screen-reader pairings.

Other disclosures

This post has looked at a basic aria-triggered disclosure pattern that requires Javascript to function as a disclosure. We haven't covered specific requirements for common UIs like accordions and mobile navigation toggles in any detail.

For now, be aware that some disclosure components you're asked to build may have additional technical requirements, depending on the UI you're building and the desired behaviour. For example, you may need to build in arrow key functionality, may need to close other disclosures when one is opened, or may need extra JS to open and focus on one disclosure if its ID is included in the page URL.

Do some extra reading around the a11y considerations for specific components you are trying to build. Then you can identify additional relevant test criteria.

Summary and Demo

I hope this guide has helped you to better understand disclosures in general, and equipped you with a decent progressively enhanced starter pattern.

Here is how our end solution looks:

See the Pen

CodePen code example: Assistive tech quiz

As you integrate this pattern (or others like it) into your projects, keep accessibility at the forefront of your mind and rigorously test your work. Good luck!

Understanding when to use padding Vs. margin in CSS

2023-08-10T00:00:00Z

In the world of CSS, getting the spacing right is crucial for creating visually pleasing and well-structured layouts. Two fundamental properties for managing space are padding and margin.

However, determining when to use each can be a bit confusing! In this post, we'll explore the differences between padding and margin, along with real-world examples to help you make informed decisions.

The Box Model: A Quick Primer

Before we dive into the details, let's quickly revisit the box model concept.

Each HTML element is essentially a rectangular box that encompasses content, padding, border, and margin. Understanding these components is vital for controlling spacing and layout.

Content: The actual content of the element, such as text, images, or other media.
Padding: The space between the content and the inner edges of the element.
Border: The line that surrounds the padding and content, demarcating the element's boundaries.
Margin: The space around the element, pushing other elements away.

With this in mind, let's delve into the specifics of when to use padding and margin in your CSS.

Padding: Space Inside the Box

Padding is for internal spacing.

Padding is the space between the content (children) of an element and its edges. It creates an internal buffer within the element, pushing the content away from the element's boundaries. Think of it as 'the space inside a box that stops children from hitting its edges'.

It's worth noting that padding doesn't collapse. Two sibling elements each with their own padding and no border will give the illusion of double the amount of visual space because their paddings will stack up against each other (they both have 'internal' space).

Let's consider an example of a simple card component:

.card {
  /* Apply equal padding on all sides */
  padding: 20px;
}

In this case, the padding property adds 20 pixels of space within the .card element. You can also define different values for each side:

.card {
  /* Apply 10px top and bottom, 20px left and right */
  padding: 10px 20px;
}

Padding doesn't need to be defined in pixels. In fact, it's often defined in rem at a component or layout level, and occasionally in em on elements like buttons so that the button padding can scale with the button's font size.

I find it helpful to think of padding something that only belongs on boxes — on HTML elements that can have child block elements. It rarely makes sense to place padding on a paragraph, for example, because it only ever contains text and inline elements (like anchors or italics). It is not a 'box' and has no concept of 'internal spacing'.

Margin: Space Outside

Margin is for external spacing.

Margin is the space around an element, pushing other elements away. It defines the gap between the element and its neighbouring elements. Use margin to create space between different elements on the page.

Note that margin collapses by default. This means that when you have two sibling elements each with a margin between them, these margins will overlap each other and occupy the same space. Whichever margin is the largest will 'win' visually.

Suppose you have a list of items that you want to space out evenly:

.item {
  /* Add margin at the bottom of each item */
  margin-bottom: 1em;
}

This adds a 1em gap between each .item element, providing a clear visual separation.

Personally, I prefer to use margin-top in most cases.

Let's say you want to add space above all items except the first one, and you want the spacing to be relative to the font size. You can achieve this by using margin-top with em units:

.item:not(:first-child) {
  /* Add proportional margin top on all except the first item */
  margin-top: 0.5em;
}

In this example, the :not(:first-child) selector targets all .item elements except the first one, and applies a margin of 0.5em on top, creating a relative spacing that adapts to the font size.

This is a very common approach for prose parts of a website, such as a blog article, because it creates a nice vertical rhythm, with proportional spacing above headings and paragraphs.

Here is a technique colloquially known as Heydon Pickering's 'lobotomised owl' to add that vertical spacing (using margin) without having to add a class to every child element:

.article > * + * {
  /* Add margin top on all direct children except the first child */
  margin-top: 0.5em;
}

You can read more about it on Every Layout. Just be aware that using this approach significantly increases the CSS specificity of that selector, meaning it could be hard to override if you want one element to have a different margin-top later on.

Using the gap Property

For modern layout designs, you might consider using the gap property, which specifies the gap between grid and flex items.

Unlike traditional margins, the gap property creates space between elements without collapsing margins. It's especially useful when dealing with flexbox or grid layouts.

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem; /* Apply a 1.5rem (24px) gap between grid items */
}

Note, if you also added margin to one of this grid's children, it would create additional space on top of the gap that is already there.

The most common use-case for using margin on grid/flex child elements when that grid is already using gap is when you want to 'push' a child to a specific place using margin: auto. For example, if all cards in a grid need the button vertically aligned at the bottom, and content aligned to the top, you might do this:

.card-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 2rem; /* Apply a 2rem (32px) gap between grid items */
}

.card-grid__card {
  display: flex;
  flex-direction: column;
  gap: 1.5rem; /* Apply a 1.5rem (24px) gap between card children */
}

.card-grid__btn {
  margin-top: auto; /* Push all content up and button down */
}

Now, no matter if some cards have longer titles or paragraphs inside, the buttons will always be aligned at the bottom of every card.

Knowing When to Choose

Here's a simple rule of thumb:

Use Padding: When you want to control the space inside an element, such as adjusting the spacing between a box and the text or other content inside it.
Use Margin: When you want to create space between elements, ensuring proper spacing and layout separation.

Combining Padding, Margin and Gap

In some cases, you might use both properties together to achieve the desired layout.

Let's continue with the card grid example given above, and see how we can use all three properties to create a harmonious layout:

/* Example: Image Cards with Padding, Margin, and Gap in a Grid */

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(17rem,1fr));
  gap: 30px; /* Apply gap between cards */
}

.card {
  padding: 1rem; /* Add padding around the content */
  background-color: #f5f5f5;
  border-radius: 10px; /* Add rounded corners for style */
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1); /* Add subtle shadow */
}

.card img {
  margin-bottom: 15px; /* Space between image and text */
}

.card p {
  margin: 0; /* Reset margin for the paragraph */
}

In this example,

the gap on the grid creates space between each card
the padding adds space within each card so its children (the image and paragraph) can't touch its edges
the margin-bottom on the image creates space between the children.
the margin reset on the paragraph makes sure no additional unwanted space is created inside the card

Conclusion

Understanding the difference between padding and margin is essential for creating well-proportioned and visually appealing layouts.

Remember that padding affects the inner space of an element, while margin controls the space around an element.

By grasping these distinctions and using examples like those discussed above, you'll be better equipped to make informed CSS choices and achieve balanced and organised designs in your projects.

Mastering sass nesting: Benefits, drawbacks, and my top tips

2023-08-06T00:00:00Z

Understanding Nesting in Sass

Sass nesting simply means placing selectors inside each other.

It's a way of writing CSS selectors that is a little shorter, and places more emphasis on the parent-child relationships. Many people find it easier to read because it provides a clear visual hierarchy to stylesheets much like HTML, thanks to the indentation and general syntax.

You can nest selectors in all sorts of ways using Sass. It's super flexible!

Demo: Nested Selectors

Consider the following example in Sass (scss):

/*  _card.scss  */

.card {
  // card styles here

  h2 {
    // card heading styles here
  }

  .button {
    // card button styles here

    &:focus-visible {
      // card button's keyboard focus styles here
    }
  }
}

Compiled to CSS, this becomes:

/*  main.css  */

.card {
  /* card styles here */
}

.card h2 {
  /* card heading styles here */
}

.card .button {
  /* card button styles here */
}

.card .button:focus-visible {
  /* card button's keyboard focus styles here */
}

Demo: Nested BEM Class Names

Some tutorials suggest nesting partial class names according to the BEM (Block Element Modifier) naming convention (see glossary). Here's an example:

/*  _card.scss  */

.card {
  // card styles here...

  &__heading {
    // card heading styles here
  }

  &__button {
    // card button styles here...

    &:focus-visible {
      // card button's keyboard focus styles here
    }
  }
}

Compiled to CSS, this becomes:

/*  main.css  */

.card {
  /* card styles here */
}

.card__heading {
  /* card heading styles here */
}

.card__button {
  /* card button styles here */
}

.card__button:focus-visible {
  /* card button's keyboard focus styles here */
}

However, this Sass example can be harder to read and maintain over time. I recommend you avoid nesting partial class names like this.

Benefits of Nesting

Nesting with Sass offers several advantages:

Readability: Structuring styles according to HTML hierarchy enhances understanding.
Reduced Repetition: Nested selectors eliminate the need for repeating parent selectors.
Modularity: Nesting encourages modular styling by isolating styles within their components.
Easier Targeting: Nested selectors allow targeting specific elements within parent contexts easily.
Efficient Compilation: Sass compiles nested styles into optimised CSS output, merging nested selectors when applicable.
Selector Flexibility: Nested selectors in Sass can help you construct more complex and expressive selectors if you want to.
Time Savings: By reducing repetition, nesting can save a little time spent typing.

Drawbacks of Nesting

However, there are potential downsides to excessive nesting:

Specificity Issues: When beginners first delve into Sass, they often encounter the issue of specificity. Overusing nesting can result in selectors that are overly specific, creating significant hurdles when trying to override styles later and obscuring understanding of how styles have been applied.
Selector Repetition: Intensive nesting might necessitate repeating selectors within a single SCSS file. For instance, this might be done to alter an element's appearance based on its parentage or to circumvent specificity conflicts in the CSS cascade. Such repetition can lead to considerable confusion.
Bloated CSS: Deep nesting can generate large, complex CSS output, impacting performance.
Complicated Selectors: Excessive nesting can result in complex and hard-to-maintain selectors.
Maintenance Challenges: Deeply nested styles may be difficult to adjust or refactor as projects evolve.
Limited Modularity: Over-nesting can hinder modularity by tightly coupling styles to a specific HTML structure.
Overrides and Conflicts: Deeply nested selectors can lead to conflicts during overrides.

My Best Practice Advice

To mitigate these issues, consider the following practices:

Limit nesting depth: Keep nesting levels shallow for readability and simplicity.
Use single class selectors: Maintain low CSS specificity by using single class selectors as much as possible and avoiding excessive nesting.
Selective Nesting: Reserve nesting for pseudo states (like :hover), pseudo elements (like :before), media queries, and ARIA attributes.
Check CSS Output: Your compiled CSS should look exactly the same as if you'd written it without any preprocessor at all. If there are any unexpected or long selector chains in there, refactor the Sass.
Regular Review and Refactoring: Periodically review and refactor styles to maintain clarity and organization.

Taken all together, this should result in highly readable, easy to maintain CSS with low specificity.

By embracing these practices, you can harness the benefits of Sass nesting while minimizing its potential drawbacks. This will result in more readable, maintainable, and efficient code.

Conclusion

Experiment with these strategies, particularly selective nesting, and observe how they impact the legibility and maintainability of your code. I hope that taking these approaches to heart helps your Sass workflow.

Recommended Frontend Mentor challenge order for junior devs (2023)

2023-07-31T00:00:00Z

My list for Beginners

Although I'm suggesting an order here, please remember it's not an exact science.

I'll try to explain why I suggest each challenge in this (rough) order. And hopefully, you'll see that I'm trying to help you build skills progressively.

As a self-taught developer, I have first-hand experience of feeling overwhelmed by challenges I couldn't do (this still happens regularly by the way!). I hope this list helps you avoid feeling overwhelmed, even if you choose to skip challenges or take them in a different order.

A good rule of thumb is to attempt challenges where you think you can comfortably do about 80% but will need to look up the last 20%. That's what this list intends to do.

1. QR Code Card

It looks super simple, but gives you a chance to practice:

how to use the style guide
landmarks and semantic HTML
how to link Google fonts
using a modern CSS reset
how to centre a component in the viewport with flex/grid
writing good image alt descriptions

2. Product preview card or Order summary component

These will build on the above but with an extra focus on:

image sizing with object-fit
buttons vs anchors
flexbox (and possibly CSS grid)
heading order
mobile-first styling
responsive images using the picture element
(in the product preview card)
how to add extra info for screen reader users
(in the product preview card)

💡 You may like to look at my post about planning out your HTML at this point!

3. Stats preview card

Now you'll practice more:

CSS grid and Flexbox
list styling (and how to keep them accessible)
blend modes on images

4. The 3-column preview card

This builds on the previous skills:

CSS Grid and/or Flexbox
headings and semantic HTML
decorative images
hover and focus-visible styles
more practice with mobile-first responsiveness

5. Single price grid or Huddle landing page

Whether or not you've used it before, this is time to use CSS grid!

You'll also practice:

landmarks and semantic HTML structure
SVG hover styles
(in the Huddle landing page)
Heading order
(in the Single price grid component)

⚠️ Note, the single price grid component design has particularly poor colour contrast, making it inaccessible. Feel free to adjust the colours if you wish!

These are more complex CSS grid challenges.

I recommend trying out grid-template areas if you've not done so already, and plan out your grid on paper if it helps.

You'll also gain more experience with:

using alignment methods like directional auto or negative margins, text alignment, transforms, flex properties or CSS grid properties
max-width in ch or rem
pseudo-elements or borders
visually hidden headings
(in the social proof section)

Honestly, doing both of these challenges is likely very beneficial!

7. Ping single column or Base Apparel coming soon page

It's JavaScript time! If you haven't studied any JS at all yet, pause here and try to learn some basics.

It's also worth reading MDN's excellent docs or tutorials on HTML form validation, as that's what these challenges focus on.

You'll also have the opportunity to learn:

more flex/grid
accessible form HTML markup
how to programmatically link errors and inputs
aria-live attributes

You will need lots of form validation practice. This is a huge part of a front end developer's job, so get familiar with forms as much as you can!

Again, this isn't the most accessible design because (a) it's missing visible form labels and (b) has poor colour contrast. Feel free to adjust it to make it properly accessible, or ignore those two issues and focus all your energy on emulating the design and validating that form in an accessible way.

You'll also be able to stretch skills like:

semantically meaningful HTML (as always)
lean JavaScript (it should be as minimal as possible)
separation of styling and script concerns
accessible error announcement
aria-describedby attributes
positioning and styling based on dynamic errors
background images
more complex CSS selectors

9. Results Summary Component

A lovely little challenge that introduces a separate data file, like those you'll work with day-to-day in front end work.

This challenge adds opportunities to learn:

how to power HTML content from data
custom properties and/or colour modifiers in CSS
some challenging pre-planning to get the HTML structure right

10. Interactive rating card

I love this challenge but it's amazing how few people plan their HTML correctly on this one.

Hint: It's a form! Look up which form elements would be most appropriate for those circles. Another hint: They're not buttons! 😉

Here you'll learn:

more about working with form data
submit events
announcing content changes to the accessibility API
accessibly styling previously unused form elements (This can be a bit tricky! ModernCSS.dev has some great posts that should help)

11. NFT preview card

This will be a real test of what you've learnt so far, especially in terms of meaningful HTML.

It also is a great opportunity to learn more about:

pseudo-elements
fun hover styles
accessible naming practices for interactive elements

12. Workit landing page, Equalizer landing page, or Pod request access landing page

If you have PRO membership and want to practice more CSS and HTML in a bigger project, have a go at one or more of these landing pages.

These are great portfolio pieces and will help weave everything you've learned together. Think of it as a chance to stretch yourself on a bigger challenge, testing and embedding those skills!

13. News homepage

This is another great one for CSS grid and testing out your awareness of meaningful HTML structure. It needs careful planning (mobile first), should include visually hidden headings, and has the bonus of a mobile menu toggle.

⚠️ Make sure you get confident with how to code a 'disclosure pattern' (like a mobile menu toggle) — It's something you will need to build countless times in your career and it is easy to make accessible if you look up how!

14. Advice generator app

As well as building on existing skills, this lets you practice fetching data from an API. That's super important in front end development!

You'll also need to use:

the aria-live attribute
well-structured HTML
accessible naming

This one brings together some form validation and data use, styling challenges and content change announcements for assistive tech. A lovely little challenge!

Next Steps (months later)

In case you haven't noticed, the list has moved on to junior-level challenges! These are more complex, in terms of layout, interactivity or accessibility. Choose any junior challenge that looks like it will stretch you in the specific area you want to practice most. Hopefully, you'll be able to identify a good one for yourself from now.

If I could recommend any next step, beyond even these, it would be to attempt something with a theme toggle (or even add one to a challenge you've already done!)

Good luck, and have fun!

Product Preview Card

2023-05-05T00:00:00Z

Series Intro

I have been mentoring junior developers for years. In that time, one issue comes up again and again. Courses for aspiring developers teach almost nothing about the importance of HTML structure!

So it's not your fault if you struggle with this! Bootcamps and tutorials skip over HTML like it's unimportant. But this process of translating designs into appropriate and meaningful HTML is the most important skill of all for developers who want to build accessibly.

HTML is like the foundations of a building. If you get that wrong, issues are inevitable.

That's why I'm starting this series of posts. Each post will go step-by-step through the content of a Frontend Mentor design and write the HTML. I'm not saying my way is the only way to do a challenge. The goal is to help you build up your own 'semantic senses'. We'll learn the thinking process behind choosing elements together. Over time I hope you'll find it easier to write appropriate HTML, even if it differs a bit from mine.

I hope you find this helpful!

The design

This post is going to look at a common design pattern: The Product Preview Card Component Challenge.

Small screen design

Large screen design

It's rare we should ever need to duplicate HTML, meaning it will be the same for all screen sizes.For the rest of this post, I'll be annotating the mobile/small screen design in images. Just be aware that the notes apply everywhere, because there would only be ONE set of HTML.

Also note that in card examples, I'll be adding BEM-style classes (Read 'BEM 101' on CSS Tricks if you're curious). You don't have to do this and I don't always do this. But it should make it easier for you to see at a glance which bit of content each element relates to.

Landmarks

Landmarks are elements are: header, main, aside and footer. All page content should sit within landmarks.

What about Article and Section?

You may also be aware of article and section, which are often referred to as "landmarks". But they are a bit different, and not page-level landmarks in my opinion.

These almost always sit inside the main landmark
For the accessibility API to recognise them as landmarks, they need to have an accessible name. That means having a heading and using aria-labelledby or using aria-label. Without that, they are treated just like divs.

Section in particular, is often misunderstood! I'll post about these elements another time. For now, I prefer to exclude them when thinking about the 'top level' landmarks on a page.

What about Article and Section?

You may also be aware of article and section, which are often referred to as "landmarks". But they are a bit different, and not page-level landmarks in my opinion.

These almost always sit inside the main landmark
For the accessibility API to recognise them as landmarks, they need to have an accessible name. That means having a heading and using aria-labelledby or using aria-label. Without that, they are treated just like divs.

Section in particular, is often misunderstood! I'll post about these elements another time. For now, I prefer to exclude them when thinking about the 'top level' landmarks on a page.

This is a single component challenge, so we only need a main landmark to wrap the design. You may also need a footer landmark below this for attribution back to the FrontEnd Mentor site. (Attribution is not shown on the design above, but the content is provided when you download the starter files.)

👉🏼 General rule: Every webpage should at least have a main.

The Card

This is a chunk of related content. As such, it would be completely valid to make the card a section or article if you wanted to. But, I think that's unnecessary / optional for this specific card component.

Let's think about how this component would be used on a real site... I envisage a scenario where there would be loads of these cards on one page. In fact, that's very likely for this kind of content.

Cards like this are often displayed in a grid or row of several. The HTML for that is usually a list, so that screen readers can announce how many product cards there are. For example:

<ul class="product-card-grid">
  <li class="product-card-grid__item">
    <!-- Product Card goes here -->
  </li>
  <li class="product-card-grid__item">
    <!-- Product Card goes here -->
  </li>
  <li class="product-card-grid__item">
    <!-- Product Card goes here -->
  </li>
  <li class="product-card-grid__item">
    <!-- Product Card goes here -->
  </li>
</ul>

Personally, I think that using a labelled article (or section) inside each of these list items creates a load of extra 'semantic noise' and seems unnecessary. The headings inside each card already give the content plenty of meaningful structure.

Hence, I'll make the component a plain old div!

<div class="c-product-card">
  <!-- Content here -->
</div>

When is a section or article better?

This needs it's own blog post really, but in short: Only use a labelled section or article for a card like this if it has multiple controls within it, and the card may repeat multiple times on a page.

For example, if this product card had

When is a section or article better?

For example, if this product card had

If you'd still rather use article or section, the HTML would need to look like this, with an accessible name for that section to be recognised in the accessibility tree.

<section class="c-product-card"
  aria-labelledby="cardTitle-087633-282652-2267757862-67262">
  <!-- Content here -->
</section>

Inside the card we need to set up two containers, one for the image part and one for the text part. Here's where my HTML markup ends up so far:

<main>
  <!-- Card could be a labelled article/section if you prefer -->
  <div class="c-product-card">
    <div class="c-product-card__img-half"></div>
    <div class="c-product-card__text-half"></div>
  </div>
</main>

Product Image

You can see in the design and starter files, this component has different images for small and large screens.

Small screen product image

Larger sceen product image

🤔 You may be tempted to use background images here, but that's a bad idea because:

This is a meaningful image. Product images should always have a proper description in the alt attribute.
Background images are usually less performant. They involve a call to the server for the CSS, then another call to fetch the image.
Background images create a worse user experience, because the user's device will download all of them, even if some are hidden (i.e. irrelevant for their screen size).
You'll have to write extra CSS to show/hide each image.

🤔 Or, you may consider using two image elements, with classes on each to show/hide them in a CSS media query. That's a bad idea too.

It's bad for performance. Much like background images, the browser will download both images no matter what size screen you are using to view the site.
You'll have to write extra CSS to show/hide each image.

🤔 So what is the solution...?

This is the perfect time to use the <picture> element!

Check out the picture element on MDN if you're not already familiar with it. It is one of my favourite elements and is great for performance. (Yes, I have favourite elements!) Only the image you need for your screen size/resolution gets downloaded. And this happens all through pure HTML. So simple.

Notes on the picture element

Just as we should style mobile first, I recommend using the picture element 'mobile first' too.

In other words, put the image for the smallest screen the src in the img element. Then put images for larger screens in the srcset of the source element(s).

Also note, if you ever need more than one source element inside a picture, they will need to be in the correct order. For example:

<picture>
    <!-- largest image -->
    <source srcset="/media/images/decorative-image-3.jpg"
      media="(min-width: 60rem)">
    <!-- medium image -->
    <source srcset="/media/images/decorative-image-2.jpg"
      media="(min-width: 40rem)">
    <!-- smallest image (default) -->
    <img src="/media/images/decorative-image-1.jpg" alt="">
</picture>

Notes on the picture element

Just as we should style mobile first, I recommend using the picture element 'mobile first' too.

In other words, put the image for the smallest screen the src in the img element. Then put images for larger screens in the srcset of the source element(s).

Also note, if you ever need more than one source element inside a picture, they will need to be in the correct order. For example:

<picture>
    <!-- largest image -->
    <source srcset="/media/images/decorative-image-3.jpg"
      media="(min-width: 60rem)">
    <!-- medium image -->
    <source srcset="/media/images/decorative-image-2.jpg"
      media="(min-width: 40rem)">
    <!-- smallest image (default) -->
    <img src="/media/images/decorative-image-1.jpg" alt="">
</picture>

So now our HTML should look like something like this (... denotes where content needs adding):

<main>
  <div class="c-product-card">
    <div class="c-product-card__img-half">
      <picture>
        <source srcset="..." media="...">
        <img
          src="..."
          alt="..."
          class="c-product-card__img" />
      </picture>
    </div>
    <div class="c-product-card__text-half"></div>
  </div>
</main>

Card Title

Which do you think is the main title of the card?

The word "Perfume" is in a small, pale font with uppercase text and increased letter-spacing. This is usually called "Ribbon text" in the design world.

This doesn't make sense as a heading. Headings should always go in a sequential order (I'll write more about that separately). That means this little category would need to have a higher (i.e. more important) heading level than the product name below it.

Also, imagine a load of these product cards on a page. It wouldn't make sense to have repeating categories for content structure:

h2: "Perfume"
h2: "Perfume"
h2: "Perfume"...

The product name is bigger, bolder, darker and makes much more sense as a unique heading!

Some may argue that in this case it would be better to keep them both as headings. Or place them together in one heading, using spans to style each line. Or change the DOM order so screen readers announce "Perfume" after the heading.

None of that is necessary. The ribbon text is fine as a paragraph and the product name a heading.

What heading level to choose?

If this was a real project, we would have more context for this design. We would know the surrounding page content and have a better idea of where this component sits within the content hierarchy. That would guide what heading level we choose.

But we don't have that in this case. All we have is a basic design. My default is to opt for the highest heading level you think this component could have.

There's always going to be a h1 on the page. So I'd give this card a h2 for now. I can always change it to a h3 later if needed.

See related post: Why heading order matters in HTML.

What heading level to choose?

But we don't have that in this case. All we have is a basic design. My default is to opt for the highest heading level you think this component could have.

There's always going to be a h1 on the page. So I'd give this card a h2 for now. I can always change it to a h3 later if needed.

See related post: Why heading order matters in HTML.

Here's where the markup is so far:

<main>
  <div class="c-product-card">
    <div class="c-product-card__img-half">
      <picture>...</picture>
    </div>
    <div class="c-product-card__text-half">
      <p class="c-product-card__ribbon ribbon-text">Perfume</p>
      <h2 class="c-product-card__title">Gabrielle Essencce Eau De Parfum</h2>
    </div>
  </div>
</main>

Capitalisation

Note how I have not capitalised the ribbon text in the HTML.

When you need to do this, always use CSS to transform the text to uppercase: text-transform: uppercase. This is because

The design may change later. You don't want to have to manually change this text at the content layer!
Capitals are harder to read. If users change their font settings, or even block the CSS you want to make sure the content remains readable.
In all likelihood in real sites, you won't be hard-coding content anyway. Content is often stored elsewhere.
I've heard that some screen readers will read out capitalised HTML letter-by-letter, as if it is an acronym. I've not experienced this myself on VoiceOver and cannot find the source of that information! But I figure it's better to follow the advice, just in case.

It may bother you that this ribbon text — which does look sort of 'titley' — is only a paragraph. There is one more thing you could do to make it stand out when looking at the code... add a hgroup wrapper:

<div class="c-product-card__text-half">
  <hgroup class="c-product-card__title-group">
    <p class="c-product-card__ribbon ribbon-text">Perfume</p>
    <h2 class="c-product-card__title">Gabrielle Essencce Eau De Parfum</h2>
  </hgroup>
</div>

⚠️ However, having a hgroup in the HTML doesn't improve the accessibility of this in any way. This is the perfect use case for the element. It's what it exists to do, and it does group the titles together nicely when reading the code.

BUT, it makes the styling more difficult. If you wanted to add consistent vertical spacing between the card's direct children with margin-top (or gap with CSS grid or flexbox), adding in that extra wrapper means you have to re-apply or repeat that styling within it.

So, it may make the code nicer to read, but it brings no benefit to end users and could make the styling more complex. With all that in mind, it's up to you if you want to use it.

Product description

This is a paragraph. No discussion needed!

Try to avoid ever placing text in divs or spans alone, as they are meaningless elements only intended for layout / styling purposes. Use a paragraph and it means screen reader users can easily read paragraph-by-paragraph if they want to (instead of line-by-line or heading-by-heading etc).

Prices

There's another little accessibility challenge in this, because the design includes two prices. One is large and bold. The other is small and has a line through it, like it's crossed out.

Think about what happens if you can't see that though... Screen reader software would read out both prices! Pretty confusing, don't you think?

The good news is there is some HTML designed for this situation. The bad news is we still have to do some extra work to make sure screen reader users know which is the old price.

Here's my initial HTML for the price:

<p class="c-product-card__prices">
  <span>$149.99</span>
  <!-- The <del> element could also be a good choice instead of <s> -->
  <s>$169.99</s>
</p>

As you can see, I've opted for the <s> element to wrap the old price. That means "strike-through", which describes the style in the design. You could use the <del> element instead, which means "deletion". That makes sense too as the old price has kind of been 'deleted'.

To make sure that screen reader users know which is the old price, you can tackle it in two ways:

In the HTML via span with a class (commonly known as sr-only or visually-hidden) to accessibly hide some label text .
In the CSS with a a pseudo element and the same CSS snippet to accessibly hide the label

Number 1 (the HTML-only approach) is simpler for a one-off component, but may not be so reusable. By that, I just mean you'd have to remember to add screen reader-only text in a span anywhere else you may include strike-through text. It looks like this:

<s><span class="visually-hidden">Old price: </span>$169.99</s>

That's fine to use! In fact, it's my recommended approach for this component.

However, I want to let you know about an alternative technique (number 2) which can be used for all strike-through text on a site or in isolation for one component. This "CSS pseudo content technique" can be a useful tool to know about even if we don't end up using it for this component. It means that any time you use strike-through text ~~like this~~ the beginning and end of the strike-through will be announced by most screen readers. You can do the same for deletion (del) or highlighted (mark) text.

To implement, you'd use CSS (scss) like this:

mark,
del,
s {
  position: relative;

  &::before,
  &::after {
    // Includes the accessible visually-hidden CSS snippet:
    @extend .visually-hidden;
  }
}

s::before {
  content: ' strike-through start ';
}
s::after {
  content: ' strike-through end ';
}

For more detail on this pseudo-content technique, take a look at Adrian Roselli's 2017 article on tweaking text level styles.

Update 2: Jan. 2025

I am torn about whether to mention this second technique any more to be honest. It's good to know that content inside a pseudo element will usually be announced by screen readers. But assistive technologies and browsers (user agents) have released a lot of improvements in recent years. That's great, I love to see updates! But it means that, as of January 2025 when I last checked, support seems patchy or inconsistent.

VoiceOver and Talkback still don't announce strike-through text, so adding some pseudo content could be useful. However, NVDA and JAWS (on Windows) both announce this style by default now, so adding the pseudo content can lead to confusing over-announcements for people using those screen readers.

This is a classic trade-off where a technique helps some and harms others.

For this pricing card component I now recommend you leave this out and use the HTML-only approach instead as it's clearer for everyone.

With all that done, my HTML will now look like this:

<main>
  <div class="c-product-card">
    <div class="c-product-card__img-half">
      <picture>...</picture>
    </div>
    <div class="c-product-card__text-half">
      <p class="c-product-card__ribbon ribbon-text">...</p>
      <h2 class="c-product-card__title">...</h2>
      <p class="c-product-card__desc">...</p>
      <p class="c-product-card__prices">
        <span class="c-product-card__price">$149.99</span>
        <s><span class="visually-hidden">Old price: </span>$169.99</s>
      </p>
    </div>
  </div>
</main>

Note I'm using a span to wrap the current price purely for positioning and styling reasons. I would set the pricing paragraph to display flex and include flex-wrap: wrap just in case it ever needs to flow over two lines, like on a small screen with enlarged text sizing.

Call-to-action (CTA)

A common question in front end developmemt is when to use an anchor link (a href=) and when to use a button.

Clicking 'Add to cart' performs an action. It is unlikely to navigate the user anywhere, so it makes sense to use a button here.

Inside the button there is a little icon as well as the text. That text label in this button already says what clicking it will do. That means we know the icon is decorative and won't need an alt description. For decorative images, you must leave the alt intentionally blank. (It's counterintuitive, I know!)

Here's what we end up with:

<button type="button" class="c-product-card__btn btn btn--primary">
  <img src="..." alt="">
  <span>Add to cart</span>
</button>

Why wrap words in a span?

The only reason I've wrapped that text in a span is because I know it will help me position it using flexbox!

.c-product-card__btn {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 1ch; // 1ch = the width of an 0 character
}

When you're first starting out, you may leave out elements like this until you come to do the styling. That's often when I'll add extra spans or divs, as they are meaningless elements. They only exist to assist with layout/styling, and don't add any semantic meaning.

Why wrap words in a span?

The only reason I've wrapped that text in a span is because I know it will help me position it using flexbox!

.c-product-card__btn {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 1ch; // 1ch = the width of an 0 character
}

Repeating CTAs can be a problem!

If there was a page full of these product cards, you'd have a situation where there are multiple "add to cart" buttons on the page. Imagine being confronted with a button menu like this:

Add to cart
Add to cart
Add to cart
Add to cart

That could get pretty confusing to screen reader users. (And to those using screen magnification or zoom etc).

The best solution is to avoid repeating CTA labels in designs altogether! Designers and content editors are becoming more disability-aware and hopefully will stop repeating links like this in future. But we can help a bit via our code right now...

Including some screen-reader only text with the product name in the button is an easy fix for this:

<button type="button" class="c-product-card__btn btn btn--primary">
  <img src="..." alt="">
  <span>Add to cart</span>
  <span class="visually-hidden">- Gabrielle Essence Eau De Parfum</span>
</button>

Alternatively, using aria-describedby or aria-labelledby on CTAs with repeating labels can help screen reader users! This can make "Add to cart" become something like: "Add to cart - Gabrielle Essencce Eau De Parfum". Note, aria-describedby wouldn't change the accessible name for screen readers when viewing the list of all links on a page though, descriptions are only announced on focus.

I'll do a deeper dive on this technique another time. But feel free to do your own research and start using it now!

Repeating CTAs can be a problem!

If there was a page full of these product cards, you'd have a situation where there are multiple "add to cart" buttons on the page. Imagine being confronted with a button menu like this:

Add to cart
Add to cart
Add to cart
Add to cart

That could get pretty confusing to screen reader users. (And to those using screen magnification or zoom etc).

Including some screen-reader only text with the product name in the button is an easy fix for this:

<button type="button" class="c-product-card__btn btn btn--primary">
  <img src="..." alt="">
  <span>Add to cart</span>
  <span class="visually-hidden">- Gabrielle Essence Eau De Parfum</span>
</button>

I'll do a deeper dive on this technique another time. But feel free to do your own research and start using it now!

Summing up

I hope this has helped you understand my process for working out the right semantics for a design.

As we've learnt, there are occasional little 'accessibility extras' we need to add in to our HTML. But these are pretty rare! It's OK if you don't understand all of them yet. As long as you are trying to choose appropriate elements and building your accessibility awareness you are on the right track!

My end HTML looks like this (most class names and content removed):

<main>

  <!-- Product Card -->
  <div class="c-product-card">

    <!-- Image half of the card-->
    <div class="c-product-card__image-half">
      <!-- images -->
      <picture>
        <source ...>
        <img src="..." alt="...">
      </picture>
    </div>

    <!-- Text half of the card-->
    <div class="c-product-card__text-half">
      <!-- Optionally include hgroup to wrap ribbon text & heading -->
      <!-- Ribbon Text -->
      <p>...</p>
      <!-- Product name -->
      <h2>...</h2>

      <!-- Product Description -->
      <p>
        ...
      </p>

      <!-- Prices -->
      <p>
        <!-- Current Price -->
        <span>...</span>
        <!-- Old Price -->
        <s><span class="visually-hidden">Old price: </span>...</s>
      </p>

      <!-- CTA -->
      <button type="button">
        <img src="..." alt="">
        <span>...</span>
        <span class="visually-hidden">- [product name]</s>
      </button>
    </div>

  </div>
</main>

It's fine if yours looks a little different! As long as it's properly thought through.

Check it with no styles!

The true test of whether you've chosen appropriate HTML is to view your content without any styling at all. It should be super clear and understandable.

This is how my style-free HTML gets rendered:

My final HTML

And the final tests for whether it is accessible involve screen reader, keyboard and even voice testing if you want to. (Including testing these once this component is placed in its real context on a site!)

Why you shouldn't use pixels for font-size

2023-05-02T00:00:00Z

Which properties are affected?

All of these properties should never ever be declared in pixels.

font-size
line-height
letter-spacing

Even if your style guide or design file gives you these sizes in pixels (or pts), we must translate those values into more appropriate units when implementing in code.

Why does it matter?

A lot more people than you may think change their base text size, usually making it larger. This can be done at an operating system level or at a browser level.

Text-only zoom is actually the default on my iPhone. Safari has a plus and minus control right there in the browser address bar to make it easy for people to change their text size.

As browsers and devices make settings searchable and more user-friendly, the number of people tweaking font settings will only increase. (I once walked in on my mum holding a magnifying glass up to her computer screen because she didn't know she could change the text size! 🤭 Thankfully, those days are long behind her...)

If you've used pixels to define any of the above style properties, they will not fully respect the user's text size preferences!

At best this means text content becomes too small for some people to read comfortably (bring out that magnifying glass or pinch and zoom!). At worst, it means letters or lines will overlap each other, making the text totally unreadable! 😱

Font-size in rem, line-height in px

The good news is, if we DO use appropriate units, everything will scale beautifully for ALL users, no matter what changes they make in their settings. And these are easy changes to make!

See text size changes in action

It's worth familiarising yourself with how to change font settings in the browser so you can test your solutions more thoroughly.

Firefox font settings

Firefox font size settings

Firefox advanced font settings

Chrome font settings

Chrome font size settings

Chrome advanced font settings

iPhone

Use the 'plus' or 'minus' controls in the Safari browser bar. If you're using Chrome, open up the settings next to the browser bar and choose 'adjust text size'. Then use the 'plus' and 'minus' controls that appear at the top of the screen.

Other user agents

There will definitely be similar settings to change text size within your operating system and on mobile devices. But I'll leave you to figure out those settings on your own. Go explore!

What units should I use?

Font-size

Generally, you won't go wrong using rem!

If your style guide of design file (e.g. Figma / Sketch / Photoshop) provides font size in pixels, you'll need to convert it to rem. Usually the first place to apply this is on the body element (try to avoid setting any direct styles on html or :root).

There are loads of ways to make this easier, and I've already outlined these methods in another post: Should I change the default HTML font-size to 62.5%?. Essentially you will need to divide whatever pixel value you want by 16 to get the rem equivalent for use in your CSS.

I would never recommend setting font size in em unless you have some specific use case where you need an element's font size to scale with it's parent. The only case I can think of where this may be useful is when using an icon font for symbols.

I'll also add that it's a bad idea to mess with font size on the html or :root selectors. Leave that for the browser to apply the user's text size. The only exception might be when you're targeting really large screens, setting a font size in percentage can make everything in your layout scale up. E.g. html { font-size: 125%; } inside a media query targeting very large screens.

Line-height

Usually line-height is written as a unitless value, like 1.5. You may also see it written as a percentage, like 150%.

Which you choose is down to personal preference. I usually use the unitless approach, because I find it easier to read and because it's shorter, making the teeniest tiniest difference to performance.

If your design file gives you a line height value in pixels, you can calculate the unitless or percentage value simply by dividing that value by the font-size. For example, if line-height in Figma/Sketch is 24px, and font-size is 16px: 24 / 16 = 1.5. That's your line-height! (Or 150%).

Letter-spacing

I recommend using em for letter spacing so it always scales with the text where it is used. You could also use rem or %.

These are all valid, but in this case, the em unit definitely makes the most sense to me. Letter spacing is one of those properties that you always want to scale with the font where it's used, and that is exactly what em does!

Summing up...

NEVER use pixels or viewport units for text properties. (Please, I beg you!)
Get familar with the text-size settings in various browsers, operating systems or devices. Play with the settings and see how it break some sites. Hopefully this will help you appreciate the importance of choosing responsive units!
Test your solutions like this, resizing the viewport and using browser emulation with an enlarged default text size. Refactor where necessary!
Font-size? Use rem
Line-height? Keep it unitless (or use %)
Letter-spacing? Use em (or use rem or %)

How to "make a site responsive" and use media queries well

2023-04-30T00:00:00Z

Defining "responsive"

All websites need to be responsive. (So do all Frontend Mentor challenges, even the single component ones!)

Put simply, a responsive site or component is one that looks OK and functions well on all screen sizes from 320px wide and above without requiring horizontal (inline axis) scroll.

"Making a site responsive" does not mean that every site / component needs a media query (MQ). Nor does it mean that building the 'mobile' version of a design.

I hear a lot of junior developers say things like "I need to make it more responsive" or "I've not done the responsiveness yet". Usually this means "It only works on my laptop screen so far, but I'll fix that next".

That's not what responsiveness means!

Responsiveness means a site responds (adapts) when viewed on different devices, zoomed in or when a user changes settings like default text size.

important!

Why 320px wide and above?

320px wide emulates iPhone 12 mini, iPhone 5, Xperia Compact etc and is an accessibility requirement for all sites under WCAG Success Criterion 1.4.10 (level AA).

The criterion states that "content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions". This is all about Reflow and making sure content is Perceivable to all users, no matter what their device, text size or zoom level may be.

In other words, our solutions need to allow users to zoom in or change their text size without suddenly having to scroll in two directions to see the content. _(It therefore closely relates to WCAG Success Criterion 1.4.4 Resize Text too!)

This is super important. As this person with low-vision states:

“It's nearly impossible to read text if I have to scroll right and left to read each line. It's disorienting and I lose my place. It makes it hard to understand what I'm reading.”

If you read the WCAG criteria and still don't understand what it's talking about (don't worry, these things are hard to understand!), I recommend checking out:

Understanding SC 1.4.10 for lots of detail
or Deque's Reflow Explainer for a light-touch summary

⚠️ All you really need to remember though is to test your sites and components on small screens and with enlarged text!

Of course you can make adjustments for even smaller screens if you wish! You can even specifically target screens like smart watches. But that is not a beginner topic and not necessary for most cases.

When to add a media query

As I've previously said, you won't always need a media query for every component, or even every website. HTML is naturally responsive, and some designs will work on (pretty much) all screens.

No media query is needed on the first Frontend Mentor challenge — QR Code Card — for example:

The QR Code challenge design

In this specific challenge there are no changes to the design on any screen sizes, so no need for any media query. Hooray!

Nor is a media query needed on simple blog sites, like this Eleventy Base Blog demo.

Eleventy Base Blog home page

That's a boring example I know, but the important thing is it WORKS! It is functionally sound and has a simple design focused on content. We don't need to complicate the build with unnecessary media queries.

Even sites like Andy Bell's personal site or his super interesting Set Studio site design don't have many media queries at all!

Set.Studio on iPhone 12

Set.Studio on a large screen

A lovely media-query free example

If you've never watched Andy's excellent talk "Be the browser’s mentor, not its micromanager" and had a look at the accompanying website Build Excellent Websites bookmark those links right now and be sure to watch after reading this post.

Mobile view

Desktop view

This talk and demo site is absolute gold. You don't need to master all of the techniques he covers straight away, I'm simply sharing here to demonstrate what's possible without media queries.

Isn't it beautiful?

Media queries are a good thing

Wait, aren't I contradicting myself now?! Didn't I just show you a load of examples without (or with hardly any) media queries?

Yes. I did. Sorry if that's confused you.

Let me be clear: I am not advocating against media queries or saying you should avoid them. Media queries are not obsolete!

It's GREAT to become aware of all the modern fluid layout techniques at our disposal in modern CSS, try out intrinsic sizing approaches and learn from CSS wizards like Andy Bell, Steph Eckles, and Kevin Powell (or many more!).

Media queries are one of many valuable tools at our disposal, but you need to know how to use them well, and they are not all you need to know when it comes to responsive styling.

How to best approach responsive styling

As a more general answer to your questions around when and how to add breakpoints:

Do all html before anything. Make sure the right meaningful elements are chosen for the content
Style the mobile design first. Shrink your viewport down, zoom and/or use device emulation view. I like to keep devtools open on the side of my screen to make this easier.
For FrontEnd mentor challenges — where the mobile static design that's provided is 375px wide — get everything looking right at that width first.
Then shrink the viewport width to 320px wide and check there's still no horizontal (inline) overflow and everything works.
A top tip is to prefer max-width over width for your components! Also try to avoid fixed units when using flex or grid layouts, opting for % or fr units instead.
Only once you are happy with the mobile view should you start to enlarge the viewport. Depending on design, and what layout changes are needed, add a breakpoint (min-width media query) at the point where there is room for the layout to change. Make sure you note down the media query essentials below!

Media query essentials

Media queries should be written in rem/em, not px
Prefer min-width media queries, so you work mobile first
You will rarely if ever need to set min and max bounds on a media query. Min-width media queries say "from this size and up, change these properties" - That should be all you ever need.
Tables are the one exception where I'd lean towards making the desktop design the default styles. That's because data tables are generally designed to work on larger screens and their default styles will often work well on desktop. You'll need a lot more overrides for mobile in this case, so it makes sense to switch tactic and use a max-width media query there. Kevin Powell has a good video teaching how to build a responsive table, if that interests you.
Media query breakpoints would be set up as variables at the start of a project on a real site, so you would select the one closest for your needs: e.g. "medium", which may have already been set up to equate to 48rem. On personal projects, or FrontEnd Mentor challenges though, you can set up your media queries to be at whatever point you need them to be. You can still set them up as variables if you want, but only add media queries when the layout needs to change because there is enough space to do so.

Assistive tech familiarisation: Vision impairments

2023-02-03T00:00:00Z

What are 'vision impairments'?

Disabilities or impairments that affect sight are extremely common.

Think beyond 'blind' — All of us are likely to encounter vision issues as we age, and there are a huge variety of conditions that may affect sight and cause someone to lean on assistive technology.

Near/Far-sightedness
Peripheral vision loss / Tunnel vision
Strain from looking at screens
Blurred vision (sometimes known as 'refractive errors')
Age-related degeneration
Cataract
Diabetic Retinopathy
Glaucoma
Amblyopia (also called “lazy eye”)
Strabismus (known as cross- or turned-out eyes)
Blindness (a spectrum)
Color blindness (in various types)
Temporary conditions like eye infections

Plus many more!

No two impairments are the same

Remember, even blindness is not an absolute. It is a spectrum. Blind people can usually see something, and which assistive technologies (if any) they choose to use, and in what combination, will vary from person to person.

With vision issues in particular, those who need them will often be hybrid users of several technologies and approaches. One is rarely used exclusively over another.

No two people with disabilitis are the same, even if they have the same diagnosis. Humans are complex. We're a combination of genes, upbringing, experiences, abilities, and circumstances... Just as people cannot be seen in neat simplistic terms, nor can disability.

Let's also remember that assistive technology is exactly that. Assistive. You don't have to have a disability to use or benefit from it, but some people are reliant on these technologies because they are the difference between impairment and complete exclusion.

It's not physical or cognitive impairments that make someone "disabled". People become "disabled" by poorly designed environments that lack the adaptations needed.

It's up to us FEDs to improve our awareness and understanding so we don't create barriers that block people with our code.

You are not your users

Although it's highly valuable for developers to gain experience using assistive technologies — nothing can replace real testing by those who genuinely rely on assistive technology every day.

That's hard to organise, I know.

But an important step is welcoming feedback in the first place and being willing to fix issues that are pointed out to you.

Assistive tech time!

Now let’s look at a few tools available to us.

Familiarity with assistive tech should be empowering to us all, but especially developers, as it will help us test our solutions properly and be more aware of what we’re looking for!

In-browser Zoom

Ctrl + Plus/Minus is a quick shortcut for this in the browser.

This is also a good way to test the responsiveness of your site as it should adjust into a mobile layout on desktop as you zoom.

Screen magnification

Note, this is different to the zooming you do in the browser!

I think this one is important to go into some detail on, as so few developers seem to be aware of it. Screen magnification is heavily used by blind or partially sighted people in particular, so it's important we know about it.

Magnification on a Mac

To turn on screen magnification shortcuts on a Mac
System Preferences → Accessibility → Zoom

Then change the settings as you wish (e.g. I have "Use keyboard shortcuts to zoom toggled ON)

Zoom settings on a Mac

Advanced zoom settings on a Mac

I actually use this all the time day-to-day! I only use the main screen magnification when testing, but use 'Hover text' regularly because I find it helpful to enlarge text as needed.

Hover text on Mac OS

My active shortcut is holding down ⌘ while hovering over the text I want to enlarge.

Windows - Screen Magnification instructions

Windows: Magnification

There are slightly different steps to follow on Windows 10 vs. 11.

To turn on screen magnification on Windows 11:
Start (windows icon) → Settings → Accessibility → Magnifier

There's also a shortcut: Press the Windows logo key + [+]. Conversely, to turn off the Magnifier, press the Windows logo key + [Esc].

Windows - Screen Magnification instructions

Windows: Magnification

There are slightly different steps to follow on Windows 10 vs. 11.

To turn on screen magnification on Windows 11:
Start (windows icon) → Settings → Accessibility → Magnifier

There's also a shortcut: Press the Windows logo key + [+]. Conversely, to turn off the Magnifier, press the Windows logo key + [Esc].

Changing browser text size

This effectively changes what 1rem equates to in the browser. So if responsive units and layout approaches have been used correctly, the site should respond well.

⚠️ This is what breaks if you set your font-size, letter-spacing, or line-height in pixels! It's an essential requirement for accessibility compliance:

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

WCAG 2.1 Success Criteria 1.4.4 (level AA)

It is OK if this leads to horizontal scroll, as long as everything is readable and functionality maintained.

Browser text resize instructions

Chrome: Browser text size

Open Settings → Search for customise font → Change font size using the controls

Firefox: Browser text size

Open Settings → Search for font → Change the size

It's worth trying this out in combination with screen magnifigation and/or zoom.

Browser text resize instructions

Chrome: Browser text size

Open Settings → Search for customise font → Change font size using the controls

Firefox: Browser text size

Open Settings → Search for font → Change the size

It's worth trying this out in combination with screen magnifigation and/or zoom.

Change OS text size

It's very common to change OS text size on mobile devices. It's even more common how many apps then stop working because they've not been tested properly!

OS text resize instructions

iOS: Device text size

Settings → Display & Brightness → Text Size

Move the slider to one of the 7 available steps

You can also go back to step 3 and adjust Display Zoom to 'Larger Text'.

Android: Device text size

Settings → Display → Font Size

Move the slider to one of 4 available steps

There's also a setting called 'Display size' which zooms everything on the screen.

OS text resize instructions

iOS: Device text size

Settings → Display & Brightness → Text Size

Move the slider to one of the 7 available steps

You can also go back to step 3 and adjust Display Zoom to 'Larger Text'.

Android: Device text size

Settings → Display → Font Size

Move the slider to one of 4 available steps

There's also a setting called 'Display size' which zooms everything on the screen.

Color modes: Themes

It's increasingly common for sites and apps to offer dark and light modes. Some also change this automatically based on the time of day.

Theme change instructions

Mac: Themes

System settings → Appearance → Choose a theme

iOS: Themes

Settings → Display & Brightness → Appearance → Choose a theme

Windows: Themes

Start → Settings → Personalization → Themes → "Change theme"

Android: Themes

Settings → Display Options → Themes → Choose a theme

Chrome: Themes

Chrome follows your system settings, but you can override it specifically for the browser:

on Android
On desktop: chrome://flags/#enable-force-dark

Firefox: Themes

Settings → Search for 'theme' → Choose a theme under 'Website Appearance'

Theme change instructions

Mac: Themes

System settings → Appearance → Choose a theme

iOS: Themes

Settings → Display & Brightness → Appearance → Choose a theme

Windows: Themes

Start → Settings → Personalization → Themes → "Change theme"

Android: Themes

Settings → Display Options → Themes → Choose a theme

Chrome: Themes

Chrome follows your system settings, but you can override it specifically for the browser:

on Android
On desktop: chrome://flags/#enable-force-dark

Firefox: Themes

Settings → Search for 'theme' → Choose a theme under 'Website Appearance'

High contrast and colors

The contrast and display settings are super useful! There are a lot of them though, so I encourage you to browse around your machine or device to see what each one does.

Devices like iPhones are particularly good at including descriptions with each control.

A few examples to try:

'Increase Contrast' or 'High Contrast Mode'
Invert colors
Filter colors

(Apple includes options for specific types of color blindness too, I'm not sure about Windows)

Keyboard

It is essential that a site works for keyboard users, and this affects many more people than those with visual impairments.

Always check your site functions as expected with keyboard.

You will also need to become aware what keystrokes are expected for different UI patterns. E.g. You would use arrow keys to move between radio inputs, but tab to move between text inputs. This takes time, but is very easy to learn!

I encourage you to start practicing using sites with your keyboard ASAP.

Screen readers, Braille and Voice Control

I'm not going to cover these properly now, as this post is already long enough! I'm planning some upcoming posts about these anyway.

In the meantime, here are some useful resources to get you started:

How to activate voice control

How to activate voice control

Screen reader guides

[Deque screen reader user guides and key commands](https://dequeuniversity.com/screen readers/)
Using NVDA (windows)

Screen reader guides

[Deque screen reader user guides and key commands](https://dequeuniversity.com/screen readers/)
Using NVDA (windows)

Videos on how to use Screen readers

Videos on how to use Screen readers

NVDA - For Windows:

Youtube video: NVDA - For Windows

TalkBack - For Android

Youtube video: TalkBack - For Android

Voiceover - For IOS

Youtube video: Voiceover - For IOS

VoiceOver - For Mac

Youtube video: VoiceOver - For Mac

Hardware

As well as all the device and system settings I've listed, there is physical equipment that can help with vision impairments too. For example:

Large screens
Curved monitors
Coloured overlay screens
Glasses
Magnifying glass

And probably loads more I've not mentioned!

What to do with this information

I’m not suggesting you use all of these settings, tools and techniques daily (unless you have to). But dip in to them!

At a minimum, you should be testing zoom to 200%, and ensuring color contrast ratios meet WCAG AA minimum requirements (including focus outlines).

⭐️ Please see the glossary page if you've not heard of WCAG before!

My a11y testing process

I do this for everything I build to try and ensure that relevant WCAG success criteria are met:

Zoom in/out in the browser to 200%
Resize the viewport and do the same
Ensure everything interactive functions as expected with keyboard
Run an automated accessibility scan (e.g. Axe DevTools, Purple Ally, Accessibility Insights or ARC Toolkit)
Do a "reflow test" using the Arc Toolkit browser extension
Open the page on at least one mobile.
I will usually change the font size in my mobile browser and check both portrait and landscape orientations.

Depending on time, complexity and testing support I'll test in other ways too, but not all the time.

Again, you don't have to do all of this! Find your own process.

Just make sure everything is readable and functions when things like font size settings or colors are changed. Learning good foundational code practices, especially in HTML and CSS, will help massively with accessibility!

My a11y testing process

I do this for everything I build to try and ensure that relevant WCAG success criteria are met:

Zoom in/out in the browser to 200%
Resize the viewport and do the same
Ensure everything interactive functions as expected with keyboard
Run an automated accessibility scan (e.g. Axe DevTools, Purple Ally, Accessibility Insights or ARC Toolkit)
Do a "reflow test" using the Arc Toolkit browser extension
Open the page on at least one mobile.
I will usually change the font size in my mobile browser and check both portrait and landscape orientations.

Depending on time, complexity and testing support I'll test in other ways too, but not all the time.

Again, you don't have to do all of this! Find your own process.

Links to learn more

How blind people use the web
WCAG 1.4.4 Resize Text
WCAG 1.4.3 Contrast Minimum
Checklist to meet text Resize, Reflow and Zoom requirements
Accessibility Requirements for People with Low Vision
(Note: This links to the Editor's draft 2021)

Should I change the default HTML font-size to 62.5%?

2023-02-02T00:00:00Z

Background: What and why?

By default, browsers set the HTML font size to 16px. That means 1rem (root element font-size) equates to 16px in browsers by default.

Users can change this default in their browser or OS settings, so this isn't strictly true all the time, but we'll come back to that later. For now, lets focus on 1rem === 16px.

Historically, the rem unit didn't exist. Its introduction unlocked a whole new world for accessibility (a11y) and for responsive design, because suddenly font-size could SCALE — It could grow and shrink depending on all sorts like zoom and personal preferences. Hallelujah!

But developers then encountered a problem. They (we) want to build everything to be responsive, right? So we want to use rem units, right? But designs always show everything in pixels 🤔…

Were you taught the 16-times table in maths class at school?! Me neither. You can understand why we FEDs did not particularly relish translating pixel-based designs into rem values.

I wish 1rem could equal a round number! Like 10. If 1rem was 10px, all my problems would be solved!

That's when lots of people started recommending this:

html {
  font-size: 62.5%;
}

Thanks to that small CSS snippet — hereafter referred to as the rem-font-hack — 1rem can now equal 10px. The maths is easy again! A design says 16px? I know that would be 1.6rem.

Developers are happy again, having made their own lives easier and unleashing a whole new accessibility nightmare for users (and possibly their future selves and colleagues) in the process.

Quit thinking in pixels!

Before going any further, let's just pause and think - do you really need to work with a "pixel mindset" at all? In the modern web, proportions and fluidity are much more important than fixed values.

The most common layouts I build hardly use any pixel values at all. CSS functions like min(), max() and clamp(), or display properties like flex and grid open up more opportunities to build responsively. Even the humble % unit can be powerful when used well.

My point is — often the people who most want to change the HTML root font size are the same people who aren't fully utilising everything modern CSS has to offer.

Not always true, of course. Even after this post, you may still want to use the rem-font-hack and that's fine. My hope is simply that you'll be more aware of the a11y 'gotchas' if/when you do.

Benefits (pros)

When 1rem equals 10px, converting pixel units from design files into rems becomes (pretty) easy to do in your head.

That's it, the only benefit. And it's 100% a benefit for you, not for site users.

You could argue this means it helps you write CSS a teeny bit faster, but as you progress you'll almost certainly have better options like Scss (Once using tooling that can do the maths for you anyway, then the rem-font-hack may actually SLOW you down!)

Negatives (cons)

The negatives affect site users AND developers.

Potentially huge accessibility problems for anyone who changes their default font size
Changing defaults is unexpected, so can confuse other developers (or even yourself in the future)
Hard to maintain and even harder to remove later on
Conflicts with third-party code
Many engineering teams will look negatively on job applicants who use this in their code, because they are aware of the issues it can cause.

⚠️ Some sites go beyond the 62.5% rem-font-hack and resize the root font size to different values at different screen sizes. Some developers probably thought it was a nice easy way to build in responsiveness. I plead with you to please never do this!. You'll create a nightmare for every developer who works on that site in future, as well as for users.

Changing the default font size on a site can make that site unusable for those with a vision impairment.

How to change font size

In Chrome: Open Settings. Search for customise font and change font-size.

In Firefox: Open Settings. Search for font and change the size.

Note, those with vision impairments have other techniques available to them such as screen magnification and zoom. It's worth learning about these too and incorporating them into your testing!

How to change font size

In Chrome: Open Settings. Search for customise font and change font-size.

In Firefox: Open Settings. Search for font and change the size.

Note, those with vision impairments have other techniques available to them such as screen magnification and zoom. It's worth learning about these too and incorporating them into your testing!

Allow me to show you what happens by changing the default font size on this site and then adding in the rem-font-hack...

Default font size changed to 72px

Default font size changed to 72px,
and HTML font-size set to 62.5%

Can you see the glaring difference there? You may not think that's a big deal (I've used the biggest font size increase to make it super obvious), but for some people, that's the difference between inclusion and exclusion.

Beware the body resize "fix"

You may think you can fix everything by 'upscaling' the body font size back to 1.6rem.

That definitely helps. It mitigates a lot of the problems... but not all of them!

Not all font-sizes inherit. Think of form elements, for example.
You still keep all of problems 2-5 listed above

Alternative ways to work with REM

Of course there is manual math! Do you need an alternative? You can set up variables once at the start of a project and then leave the values alone.
As I mentioned earlier, modern methods like clamp() min() and max() functions mean everything is less static than it once was. Plus we even have new units now like container units! So you may not need to use rem as much.
Check out Utopia to generate fluid variables for you
The surprisingly powerful calc function can do all you need. For example: calc((32 / 16) * 1rem)
My favourite approach — Use a scss function! (Just like the one I use on this site)

@use 'sass:math';

/// Converts PX to REM
/// @access public
/// @param {string} $size - Value to be converted in PX.
/// @returns {string} - Returns REM string.
/// @example font-size: rem(24px);
/// @returns font-size: 1.5rem;
@function rem($size) {
  $remSize: math.div($size, 16px);
  @return #{$remSize}rem;
}

Using something like this Sass function makes it extremely easy to work with rem when you need to.

In conclusion

It doesn't matter what tutorials have taught you, or if you see others using the rem-font-hack. My years of experience have taught me that we should work with system defaults, not fight against them.

I hope you agree of course and break the habit ASAP if you're using the rem-font-hack in your sites.

But if I've not convinced you, that's OK too. It's your choice. Just be aware of all those negatives, and make sure you combat them wherever possible.

My goal here is simply to make sure you fully consider the implications of every engineering choice you make.

Improve the format of your JavaScript selectors

2023-02-01T00:00:00Z

There are loads of ways to select elements with JavaScript...

querySelector()
querySelectorAll()
getElementByID()
getElementsByClassName()
getElementsByName()
getElementsByTagName()
getElementsByTagNameNS()

There's probably even more than that!

Inside those methods you pass in parameters to select the element(s) you want (check the docs for each method if you want to know what params they can take).

Personally, I like to use querySelector() and querySelectorAll pretty much exclusively. Their params are just like CSS selectors we all know and love.

// selector examples:
const myElement = document.querySelector('.class-name');
const myElement2 = document.querySelector('#unique-ID');
const myElement3 = document.querySelector('[name="rating"]');
const myNodeList = document.querySelectorAll('button');
//...you get the idea!

A quick note about querySelector()

Remember, you don't always have to use document with querySelector().

An alternative can be to query other elements you've already selected, making DOM traversal faster.

const form = document.querySelector('.js-form');
const toggleButton = form.querySelector('.js-toggle');

This slightly improves performance when you can use it.

A quick note about querySelector()

Remember, you don't always have to use document with querySelector().

An alternative can be to query other elements you've already selected, making DOM traversal faster.

const form = document.querySelector('.js-form');
const toggleButton = form.querySelector('.js-toggle');

This slightly improves performance when you can use it.

Do you see how messy and inconsistent it can become, using whatever old JS selector you like? That inconsistency becomes even more evident once you work with others in a team.

⚠️ It's really good to have code standards for these things!

If you start implementing selectors consistently now, I promise your future self (and any devs who have to work on your code in future) will thank you for it!

The problem

Inconsistency, mixed selectors, and (even worse) nested element selectors are the enemy of clean code.

The biggest issue of all when you use (or a team uses) inconsistent approaches to element selection is it makes your code vulnerable to bugs being caused by code in other files. You lose all visibility in HTML of what JavaScript is doing.

Another issue with inconsistent selectors is it simply slows a team down. You have to think afresh every time, "what shall I use to get my element here?" Exhausting.

The solution

Use a consistent method of element selection that's reserved only for JavaScript.

1. Prefixed classes

💡 I recommend using js- prefixed class selectors on every element you need to select in JavaScript, along with querySelector() or querySelectorAll, like this:

<!--HTML-->
<button class="js-toggle">...

/* JS */
const toggleButton = document.querySelector('.js-toggle');

This approach removes all ambiguity. It can be consistently applied across a team and is immediately clear when looking at the HTML what is being affected by JavaScript. That is a huge bonus!

2. Custom data attribute

A very similar alternative that's just as good is using a specific data attribute for every element you want to select with JavaScript, like this:

<!--HTML-->
<button data-js="toggle">...

/* JS */
const toggleButton = document.querySelector('[data-js="toggle"]');

Try one of these approaches out and see how you get on...

Summary

Using a specific and consistent method for JS selectors
- removes ambiguity
- bakes in that consistency
- removes some cognitive burden on developers
- and provides clear visibility of what JavaScript is doing in the HTML, leading to fewer unexpected bugs.
Establishing code standards — such as "This is how we always select elements in JavaScript" — can only improve your code and your team's efficiency.

It's never too early to start building good habits! 😉

What is the ID attribute in HTML really for?

2023-01-31T00:00:00Z

When we talk of IDs, really we're looking at the attribute value, as demonstrated here with "uniqueHeadingId" in this example:

<h2 id="uniqueHeadingId">
  This heading has an ID attribute.
</h2>

That uniqueHeadingId can be referenced and used in a variety of ways throughout Front End code. You'll see IDs in HTML, CSS and JavaScript, but that doesn't mean every code example is using them well!

Important points to note

A few quick caveats about this super-important little attribute...

You don't need IDs on everything! Only add them when you need to (see uses below).
IDs must not contain spaces or special characters. That's invalid HTML.
Every ID value on a page must be unique. If you remember nothing else from this post, please remember that!

This last point sounds easy to achieve but can be very tricky in practice. For example, consider component-based systems, (especially on CMS-powered sites) where you may not know exactly where or how frequently a component might be used on a page.

Or course if you know an element will only ever occur once on a page, it's fine to hard-code an ID. For example, a menu or theme toggle located in the site header is likely to be static, so can have a hard-coded ID value.

Just be warned — In other scenarios, you may need to work harder for those unique IDs!

📖 Further reading on unique IDs: look up 'GUIDs'

What can IDs be used for?

Think of an ID an anchor point in the HTML. That's it's primary job! But there are a number of ways it can be used:

As a CSS selector
As a JS selector
As an anchor for navigation
As an anchor for other HTML attributes (to programmatically link elements to each other)

Let's look at each one in turn with some practical examples.

ID as a CSS selector

Just because you can use ID attributes as style selectors, it doesn't mean you should. Example:

<!-- HTML -->
<p id="cool-id">...

/* CSS */
#cool-id {
  ...
}

⚠️ This is not recommended!

ID selectors have a higher specificity in CSS than classes. Generally, you want to keep CSS specificity as small/low/flat as possible. Anything that increases specificity is therefore undesirable.

You may think, "It's fine! I know this element will only ever be used this once and will never need its styles changing." But that brings up a new negative... Would other developers think the same? (including your future self!)

I've seen IDs change a LOT while working on various code bases over the years. Either the ID names weren't clear enough, or a new system gets introduced to make sure they're always unique, or they get changed for some other reason. If (when) that happens, the styles suddenly break. And no one ever expects changing IDs to have an impact on styling because it's well-established that styling hooks should be on classes, not IDs.

IDs as a JS selector

This isn't as bad and is certainly a more common practice you'll encounter. For example:

<!--HTML-->
<button id="super-cool-id">...
<button id="cool-id">...

/* JS */
const myButton = document.querySelector('#super-cool-id');

// or... (a marginally less performant version)
const myOtherButton = document.getElementByID('cool-id');

⚠️ In my opinion, using IDs as JS selectors is still not a great idea!

It's sort of OK if your team has this as an established pattern because if IDs change, you and your team will know to go and check that any JavaScript functionality still works.

The problems come

When IDs have to be programmatically generated to be unique. Suddenly your nice code standard can't be used any more and you'll have to lean on a class or element selector instead.
When there is a lack of clarity (How would a dev looking at the HTML know that an ID is important for JS functionality?)
With lack of consistency. Usually, when people use IDs in JS, it's not an exclusive pattern. I often see a mixture of ID and element and class selectors, which can only lead to confusion and breakage as a team grows.

A bonus of not using IDs as JS selectors is that they're left alone for their real purpose... anchoring.

HTML is pretty beautiful. Any time you use an ID attribute, you get navigation anchors for free with no extra work. That means you can add #your-id to the end of any URL and jump straight to that ID's location on page load. Incredibly useful!

That's how this post's table of content works, for example. Go on — go back to the table of contents and click on "IDs as an anchor for navigation". You'll come right back here 😊. I'll wait...

IDs as element anchors

Finally, the good stuff!

This is where IDs shine (and why it's so important that they are unique)! Take this example from the Frontend Mentor 'Intro component with sign-up form' challenge:

Laying aside some of the accessibility issues like color contrast and the DOM order in this design (and laying aside the fact that this design would probably break EU law, which requires an explicit terms and conditions opt-in), I would write the mark up as follows:

<button type="button" aria-describedby="terms">
  Claim your free trial
</button>
<p id="terms">
  By clicking the button, you are agreeing to our <a href="/">Terms and Services</a>
</p>

✅ This is the perfect use case for an ID attribute!

Thanks to this little ID, aria-describedby can now programmatically link the terms to the form submit button. That means, on focus of the button, a screen reader will now announce button, submit, by clicking the button you are agreeing...

Check out the HTML in this CodePen for more good use cases:

See the Pen

CodePen code example: Good use-cases for the ID attribute

Summing up

I hope this has helped you gain a deeper understanding of how powerful and important IDs can be in HTML.

Take this as both

A challenge - to only use IDs for navigation and programmatically linking elements
And an opportunity - to learn a little sprinkling of aria 😉

Just remember - no aria is often better than the wrong aria! So test, test, test! And ask for help and feedback from others while you practice.

FED Mentor

Why heading order matters in HTML

How to ask for help (and actually get it!)

Join me for free lunch & learn sessions on digital accessibility!

Let's build an accessible disclosure (show/hide accordion)

A note on accordions

A note on mobile navs

Understanding when to use padding Vs. margin in CSS

Mastering sass nesting: Benefits, drawbacks, and my top tips

Recommended Frontend Mentor challenge order for junior devs (2023)

2. Product preview card or Order summary component

5. Single price grid or Huddle landing page

6. The 4 card feature and Social Proof section

7. Ping single column or Base Apparel coming soon page

12. Workit landing page, Equalizer landing page, or Pod request access landing page

Product Preview Card

What about Article and Section?

When is a section or article better?

Notes on the picture element

What heading level to choose?

Why wrap words in a span?

Repeating CTAs can be a problem!

Why you shouldn't use pixels for font-size

How to "make a site responsive" and use media queries well

A lovely media-query free example

Summary

Assistive tech familiarisation: Vision impairments

Magnification on a Mac

Windows: Magnification

Windows - Screen Magnification instructions

Windows: Magnification

Chrome: Browser text size

Firefox: Browser text size

Browser text resize instructions

Chrome: Browser text size

Firefox: Browser text size

iOS: Device text size

Android: Device text size

OS text resize instructions

iOS: Device text size

Android: Device text size

Mac: Themes

iOS: Themes

Windows: Themes

Android: Themes

Chrome: Themes

Firefox: Themes

Theme change instructions

Mac: Themes

iOS: Themes

Windows: Themes

Android: Themes

Chrome: Themes

Firefox: Themes

How to activate voice control

Screen reader guides

NVDA - For Windows: