Angular

Make it Accessible: Better Layout with HTML

Published May 22, 2020

Updated Feb 14, 2023

5 min read

Make it Accessible - 8 Part Series

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Make it Accessible: Better layouts with HTML

In this article, I'm going to teach you how to use the HTML tags <div>, <section> and <article>, and how they can improve your web applications accessibility.

Here you can access all the resources used in the article.

The Problem

Web applications are built with HTML, and even though it isn't a programming language, it is nontheless complex. One of the first issues you may encounter is knowing which element to use, and the huge amount of elements available makes this issue even more challenging.

When it comes to your page's layout, some of the options are; <div>, <section> and <article>. Today, you're going to learn when you should use each of them.

The Solution

First, we will conceptualize each of the elements I just mentioned. You can learn more about these in the w3c wai aria practices guide, but let's discuss those concepts here:

The <div> element is often used as a container for other HTML elements to style them with CSS or to perform certain tasks with JavaScript. w3schools.com

You may be tempted to use <div> with some styles instead of learning about the available elements in HTML5. I have to tell you, if you do that, you're hurting your users. Each element has a specific purpose, and you should be using the right element. <div> is useful when you want to group some elements and give them some styling, that doesn't mean you should make everything with <div>.

The <section> tag defines sections in a document, such as chapters, headers, footers, or any other sections of the document. w3school.com

This is a very important tag as you start your accessibility journey. It gives context to your users, specially those with Screen Readers. By "context", I mean that if you wrap a group of elements with a section and give it an accessible name, once users focus one of the elements, it reads the parent container too.

The <article> tag specifies independent, self-contained content. w3school.com

Almost every application has some kind of catalogue showing several items having the same styles, and if you think it through, these items could be placed anywhere without any context. Articles are cool for those cases, even though these aren't landmarks, it's common for Screen Readers to have a mechanism to allow users to navigate through articles easily.

The Implementation

Next, we're going to do a small sample using each of the mentioned elements. Let's start with the <div>.

Using divs right

Now that you are fully aware of the purpose of a <div>, it is time to use it. For this one, I decided to take the easy road and make a very simple example. Let's say you have multiple "things" you want to group, and to which you want to apply some additional styling. That can be easily done like this:

<html>
  <head>
    <style>
      .square {
        display: inline-block;
        width: 150px;
        height: 150px;
        border: 1px solid black;
        margin: 10px;
        background-color: white;
      }

      .group {
        display: inline-block;
        margin: 0;
        background-color: #bbb;
      }
    </style>
  </head>

  <body>
    <header>
      <h1>Using divs right</h1>
    </header>

    <main>
      <div class="group">
        <div class="square"></div>
        <div class="square"></div>
      </div>
      <div class="square"></div>
      <div class="square"></div>
      <div class="square"></div>
    </main>
  </body>
</html>

To test this, create a file with the .html extension containing what I just gave you, and open it with your preferred browser. You'll notice that the first two have a light gray background. Once again, very simple and easy to follow. Let's jump to the next example.

Sections are the way to go

For this one, I was looking for a more exciting example. Let's say you are building an application for a movie theater that allows customers to order tickets online. If you buy a ticket, you want to have a page where you can see all the details about the movie and your ticket.

Let's start by thinking it through. We want to see all the information about the movie, title, synopsis, a banner image, and a genre. When it comes to the ticket, I want to see its worth, my seat number, and the time left for the show to start.

The HTML for something like this would look like this:

<html>
  <head>
    <style>
      body {
        margin: 0;
        padding: 0;
      }

      main {
        display: flex;
        align-items: flex-start;
        justify-content: center;
        flex-wrap: wrap;
        background-color: #333;
        min-height: calc(100vh - 80px);
        margin-top: 80px;
      }

      header {
        position: absolute;
        height: 80px;
        color: white;
        background-color: #444;
        padding: 2px 0;
        text-align: center;
        box-shadow: 0px 6px 3px 3px rgba(0, 0, 0, 0.1);
        width: 100%;
        top: 0px;
      }

      .card {
        box-shadow: 0px 6px 3px 3px rgba(0, 0, 0, 0.1);
        display: inline-block;
        margin: 20px;
      }

      .movie-details {
        width: 400px;
      }

      .movie-details figure {
        width: 100%;
        margin: 0;
      }

      .movie-details figure img {
        width: 100%;
        object-fit: cover;
      }

      .container {
        padding: 10px;
        border: 1px solid #333;
        background-color: #444;
        color: white;
      }

      .ticket-summary {
        width: 250px;
      }

      .ticket-summary dt {
        color: #ccc;
        font-size: 1.1rem;
        font-weight: bold;
        margin-top: 8px;
      }
    </style>
  </head>

  <body>
    <header>
      <h1>Your Ticket Details</h1>
    </header>

    <main>
      <section class="card movie-details" aria-label="movie details">
        <figure>
          <img src="./img.jpg" alt="" />
        </figure>

        <div class="container">
          <h2 style="margin: 6px 0;">Parasite</h2>
          <p style="text-align: justify;">
            Greed and class discrimination threaten the newly formed symbiotic
            relationship between the wealthy Park family and the destitute Kim
            clan.
          </p>
          <p><b>Comedy, Drama</b></p>
        </div>
      </section>

      <section
        class="card ticket-summary"
        aria-labelledby="ticket-summary-title"
        aria-describedby="ticket-summary-description"
      >
        <div class="container">
          <h2
            id="ticket-summary-title"
            style="margin: 6px 0; text-align: center;"
          >
            Ticket Summary
          </h2>
          <p id="ticket-summary-description" style="text-align: justify;">
            Remember to exchange your ticket identifier for the actual ticket as
            soon as you get to the movie theater.
          </p>
          <dl>
            <dt>Identifier</dt>
            <dd>123</dd>
            <dt>Seat</dt>
            <dd>B-12</dd>
            <dt>Price</dt>
            <dd>$ 2,00 USD</dd>
            <dt>Starts in</dt>
            <dd>2h 30m</dd>
          </dl>
        </div>
      </section>
    </main>
  </body>
</html>

For now you can ignore the styles, it's just to make it look less ugly, what I want you to pay attention to is the HTML part. Look at how I created two sections- one for the movie details, and one for the ticket summary. Another important takeaway is how I used aria-label and aria-labelledby. Both have the same results, but in the movie details, I wanted to read "Movie Details" instead of the movie title, and in the case of the Ticket Summary, it's different because we want to read the same title.

By structuring your HTML document this way, using sections with the proper accessible names, you're not only giving context to the user, but you're creating a hierachical view of the landmarks of your application. This makes it easier for Screen Readers to understand your page, and as a consequence, you get better usability for your disabled users.

Articles are useful too

I know that example may have set the bar a little high. For this example, I'm doing something simpler. Let's say that this movie theater we are "working for" wants to show all the available movies to possible customers. This is where articles shine the most, because let's face it, no matter how many movies there are, all of them will have the same styles.

Let's roll up our sleeves, and create a new html file with this content:

<html>
  <head>
    <style>
      body {
        margin: 0;
        padding: 0;
      }

      main {
        display: flex;
        align-items: flex-start;
        justify-content: center;
        flex-wrap: wrap;
        background-color: #333;
        min-height: calc(100vh - 80px);
        margin-top: 80px;
      }

      header {
        position: absolute;
        height: 80px;
        color: white;
        background-color: #444;
        padding: 2px 0;
        text-align: center;
        box-shadow: 0px 6px 3px 3px rgba(0, 0, 0, 0.1);
        top: 0px;
        width: 100%;
      }

      .card {
        box-shadow: 0px 6px 3px 3px rgba(0, 0, 0, 0.1);
        display: inline-block;
        margin: 20px;
      }

      .movies {
        display: flex;
        justify-content: center;
        flex-wrap: wrap;
        width: 800px;
      }

      .feed {
        display: flex;
        margin-top: 10px;
      }

      .movie {
        width: 200px;
        height: 420px;
      }

      .movie figure {
        width: 100%;
        height: 300px;
        margin: 0;
        overflow: hidden;
      }

      .movie figure img {
        width: 100%;
        object-fit: cover;
        height: 100%;
      }

      .container {
        padding: 10px;
        height: 100px;
        border: 1px solid #333;
        background-color: #444;
        color: white;
      }

      .movie h2 {
        margin: 8px 0;
        font-size: 1.2rem;
        font-weight: bold;
      }

      .movie p {
        margin: 8px 0;
        font-style: italic;
      }
    </style>
  </head>

  <body>
    <header>
      <h1>Movies List</h1>
    </header>

    <main>
      <section class="movies" aria-label="available movies">
        <div role="feed" class="feed">
          <article
            class="movie card"
            aria-labelledby="movie-name-1"
            aria-describedby="movie-genre-1"
            tabindex="0"
            aria-posinset="1"
            aria-setsize="3"
          >
            <figure>
              <img src="./movie-1.jpg" alt="" />
            </figure>
            <div class="container">
              <h2 id="movie-name-1">The Shawshank Redemption</h2>
              <p id="movie-genre-1">Drama</p>
            </div>
          </article>
          <article
            class="movie card"
            aria-labelledby="movie-name-2"
            aria-describedby="movie-genre-2"
            tabindex="0"
            aria-posinset="2"
            aria-setsize="3"
          >
            <figure>
              <img src="./movie-2.jpg" alt="" />
            </figure>
            <div class="container">
              <h2 id="movie-name-2">The Godfather</h2>
              <p id="movie-genre-2">Crime, Drama</p>
            </div>
          </article>
          <article
            class="movie card"
            aria-labelledby="movie-name-3"
            aria-describedby="movie-genre-3"
            tabindex="0"
            aria-posinset="3"
            aria-setsize="3"
          >
            <figure>
              <img src="./movie-3.jpg" alt="" />
            </figure>
            <div class="container">
              <h2 id="movie-name-3">The Dark Knight</h2>
              <p id="movie-genre-3">Crime, Drama</p>
            </div>
          </article>
        </div>
      </section>
    </main>
  </body>
</html>

Remember to focus on the HTML structure, not the styles. The first time I saw this kind of code, I was like, wow, what's all that aria stuff doing? Today, I'm going to make this easier for you.

First of all, I have to remind you that all of these ideas come from the WAI ARIA Authoring Practice Guide.

One thing to notice before heading to the code is that a list of movies is a feed. Also, don't reinvent the wheel. The WAI ARIA guide has a very detailed description of how a feed should be implemented while prioritizing accessibility. You have to start with <div> and role="feed", next you have to work on the articles.

Setting up the feed container is very simple. What's not so straightforward are the articles themselves. Each of the aria properties has a specific purpose:

aria-labelledby: Title of the movie.
aria-describedby: Additional information about the movie.
aria-posinset: Position of the movie in the list.
aria-setsize: Size of the list of movies.

There's also a tabindex="0" because once in a feed, screen readers provide users with additional navigation mechanisms that require us to make the articles "focusable".

NOTE: All the <img> in the samples have an empty alt like this alt="". It's because using an empty alt tells screen readers to ignore the images entirely, in a real life project for images that provide information, you always give a proper alt value.

Conclusion

Every time I write one of these series, I come up with the same conclusion: Just use HTML! I'm even thinking of changing the name to "It's Already Accessible". It's common to hear developers saying that HTML is too simple. It might be for some, but you still have to learn it. Whenever you write an application, try to build it following patterns like the ones in WAI-ARIA. Make sure to follow their specifications, and you'll make applications all of your users will love.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

Welcome to a journey of discovery where we'll explore the often-overlooked capabilities of the Next.js Image component. At first glance, this component might seem like a straightforward tool, merely enhancing performance compared to a regular img tag. However, there's more to it than meets the eye. In this blog post, we'll uncover the magic of some features of the Next.js Image component. It's easy to use, yes, but it also packs a punch with features that go beyond simple image rendering. These hidden features can significantly impact your project, and missing them could mean not fully utilizing the component's potential. Let's dive into this exploration, unraveling the subtle yet powerful aspects of the Next.js Image component that are easy to overlook. So, without further delay, let's get started! Size First up, let's chat about width and height. These are rules for how big your image shows on the screen. You gotta use them most of the time. But hey, if you're pulling in an image directly into your code (that's what we call 'static importing') or you want your image to just fill up whatever space it's in (using the 'fill' prop), then you can skip these rules. Neat, right? But that's not all there's to it. You see, when Next.js fetches the image from the server, it does something behind the scenes. It doesn’t just grab any size of the image. Instead, Next.js is smart and picks the best size that fits the spot on your webpage. This means your images load faster and look just right, whether on a big desktop screen or a small phone screen. It's like having a personal assistant for your images, making sure they are always looking their best and not slowing down your site. Here's a part that's easy to miss: Next.js uses a feature called 'srcset' to decide which image size to download from the server. By default, Next.js uses the following default: ` So, imagine you have an image that's 75 pixels wide. Next.js will look at this list and pick the closest size. In our case, with these default settings, it would download the 96-pixel version. This occurs because Next.js selects the smallest available size from the list that exceeds the original's width, ensuring the image remains clear on all devices; even if your image is a bit smaller or larger, Next.js picks the nearest size from this list. This is important to know because if you are looking to get the most performant image possible, you should be aware of these size values. By understanding how Next.js selects the image size, you can better tailor your images to match these presets. This way, you ensure that your site is not only loading the appropriate image size for different devices but also optimizing for speed and efficiency. Keeping an eye on these sizes helps you balance between image quality and fast loading times, which is key for a great user experience on your site. Quality Now, let's highlight something about image quality. It's often overlooked, but by default, Next.js sets the image quality to 75. Sure, you can tweak this with the quality prop, but here's the catch: bumping up the quality to 100 will significantly increase the image's file size. This means your images will look super sharp, but they'll also take longer to load. It's all about finding that sweet spot where your images look great without slowing down your website. Remember, a faster site often means a better experience for your visitors. My advice is to always check what is better for you in each situation. Ask yourself: Consider whether it's more beneficial to opt for larger images at a slightly reduced quality, in alignment with the “srcset” configurations we explored, or if it's preferable to enhance the image quality, even if it means working with smaller dimensions? It's a balancing act. Usually, cranking up the quality to 100 isn't the best move because it makes the image file really big, which can slow down your site. It's all about making smart choices. Go for a quality that makes your images look good without burdening your site's load time. Sometimes, a slightly lower quality image, but well optimized, can be way more effective than a perfect but sluggish, high-quality image. Loader The loader prop in Next.js is a key player. It's not just about fetching images; it’s about fetching them smartly and securely. When using images from different places, like a CMS or your server, the loader prop helps you manage them efficiently and safely. For instance, say you have images on Contentful. Next.js doesn't automatically know the best way to fetch these, but with a custom loader, you can define this process. This loader optimizes your images, selecting the right format, width, and quality. Your images not only look great but load faster, too. Remember, when fetching images from external sources, it's crucial to use remotePatterns (inside your next.config file) for security reasons. This ensures your site stays safe while handling images from outside. This approach is scalable and saves time. You set up the loader once, and it works for all your images, making your site efficient and your code neat. Here’s an example: ` ` Placeholder Prop A little-known yet impactful feature of the Next.js Image component is the placeholder prop. It's all about improving the user experience while your images are loading. Imagine visiting a website and waiting for images to load – it can be a bit dull, right? The placeholder prop can make this wait a lot more pleasant. You can use this prop to display a blur effect or a solid color before the image fully loads. This creates a smoother visual experience. The blur placeholder is particularly popular because it gives a sneak peek of the image without revealing all the details. It's like a teaser, building anticipation for what's to come. Here’s how you can use it: ` In this example, blurDataURL is a small, low-quality version of your image that loads much faster. Once the actual image is ready, it seamlessly replaces the blur. This approach significantly enhances the perceived loading speed and keeps your users engaged. Incorporating the placeholder prop can make a big difference in how professional and polished your site feels, especially on slower connections where image load times are noticeable. Conclusion The Next.js Image component is a powerful tool that goes beyond simple image rendering. By understanding its hidden features and capabilities, you can optimize your project for performance and user experience. From utilizing the 'width' and 'height' properties to ensuring the right image quality and using the 'loader' prop for efficient image fetching, there are several aspects to consider. Additionally, the 'placeholder' prop can enhance the user experience by displaying a blur effect or solid color while images load. By exploring these often-overlooked features, you can unlock the full potential of the Next.js Image component and create a more engaging and optimized website....

Feb 9, 2024

5 mins

UXJavaScriptNextJS

New Core Web Vitals and How They Work

Core Web Vitals, introduced by Google in 2020, have been around for a while now. And after four years, a significant change is coming in March 2024. In this article, I will try to tell you everything you need to know to be prepared. But first, let's briefly talk about what Core Web Vitals are. What are Core Web Vitals? Web Vitals is a Google initiative that aims to provide developers with guidance on authoring the best user experience on the web as well as tools to assess and measure it. Core Web Vitals are a subset of Web Vitals and currently consist of three main metrics: - Largest Contentful Paint (LCP): This metric measures the time it takes for the largest content element to be rendered on the screen. It should reflect the _loading_ aspect of the user experience. - First Input Delay (FID): This metric measures the time it takes for the browser to respond to the first user interaction. It should reflect the _interactivity_ aspect of the user experience. - Cumulative Layout Shift (CLS): This metric measures the amount of unexpected layout shifts of visual elements on the page. It should reflect the _visual stability_ aspect of the user experience. Part of the Core Web Vitals are also the thresholds that define what is considered a good experience. These thresholds are currently set to: | Metric | Good | Needs Improvement | Bad | | ------ | -------- | ----------------- | -------- | | LCP | ≤ 2.5 s | 2.5 - 4 s | > 4 s | | FID | ≤ 100 ms | 100 - 300 ms | > 300 ms | | CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | While the reward of providing a good user experience should be enough for you to strive for great results in these metrics, that is not the only reason you should care about them. Google is reflecting these metrics in its search ranking algorithm as it wants it to "reward content that offers good user experience". What's Changing in March 2024? The change affects how _interactivity_ is measured. The First Input Delay (FID) has been deemed no longer sufficient to measure the interactivity aspect of the user experience. It will be replaced by the Interaction to Next Paint (INP) metric on March 12, 2024. INP, unlike FID, measures the response of all interactions up to a URL change. It then picks the slowest response from all interactions. (If there are more than 50 interactions, it picks a percentile instead, most often the 98th) making it much stricter than FID. Why the Change? There are three main reasons why FID is being replaced by INP: 1. FID is not strict enough: Upwards of 90% of websites meet the good threshold for FID nowadays, making it a poor differentiator between good and bad user experiences. 2. FID is not representative of the full interaction: FID only measures the first part of the reaction delay, up to the point before the response bubbles to JavaScript, not accounting for the (often quite long) time it takes for the JavaScript to process the response and for the browser to paint the next frame. 3. FID only measures the first interaction: According to Google, 90% of interactions happen _after_ the first load, making FID not representative of the full user experience. INP aims to address these issues by measuring the full interaction and by being stricter in its thresholds (according to Google, ~70% of websites should pass the good INP threshold now) and thus capturing a more representative picture of the user experience. How Does INP Work? As I previously mentioned, INP measures all interactions on the page and picks the slowest one or a percentile, which solves one of the issues with FID not representing the whole experience of interacting with a website. This way of measuring is not dissimilar to how CLS measures the unexpected layout shifts on the page as it also captures the full scope of the stay on the page. The interactions considered by INP are: - Mouse clicks - Touchscreen taps - Keyboard presses (including virtual onscreen keyboards) If an interaction is composed of multiple events, such as a keystroke, consisting of the keydown, keypress, and keyup events; INP groups them and measures the latency as the maximum duration of all the included events. Unlike FID, it captures not only the time taken by tasks blocked by the main thread (the _input delay_) but also the _processing time_ (events and JavaScript processing) and the _presentation delay_ (the time it takes for the browser to paint the next frame), making it a much better reflection of the full user experience, but also much harder to pass. So while FID reflects the first impression, INP should capture the overall _responsiveness_ of a page. For more information about interactions with comprehensive diagrams of what actually happens in the browser, check out the web.dev article on INP. Google defined the thresholds for INP as follows: | Metric | Good | Needs Improvement | Bad | | ------ | -------- | ----------------- | -------- | | INP | ≤ 200 ms | 200 - 500 ms | > 500 ms | How to Prepare for INP? Let's start with some general steps you should take to prepare for the new Web Vital: 1. Measure Start with measuring your INP score. The easiest way to measure it is using PageSpeed Insights, but if you need to measure it locally, you can use Lighthose user flows which already support INP. If your INP scores are _good_, you're fine and you can probably stop reading further. 2. Do not panic While, according to Tim Kadlec, only 17% of React websites and 11.8% of Next.js websites in the "top 100k" pass the _good_ INP threshold, so it's very likely that you will have to do some work to pass; framework authors have been working on improving their performance and things may be as hot as Tim paints them. According to Google’s stats, ~80-90% of desktop sites pass the _good_ INP threshold depending on the framework as of June 2023: | Technology | Passing on Mobile [%] | Passing on Desktop [%] | | ----------------- | --------------------- | ---------------------- | | Angular (v2.0.0+) | 28.6 | 83.6 | | Next.js | 28.5 | 87.3 | | Nuxt.js | 32.0 | 91.2 | | Preact | 48.6 | 92.8 | | Vue (v2.0.0+) | 50.3 | 94.1 | | Lit | 50.0 | 88.3 | 3. Optimize In case your INP scores are not _good_, you should start optimizing your website. Identify the pages that perform the worst and start with them. Focus on: - Code splitting and tree shaking to make sure only the necessary JavaScript is included. - Deferring non-critical JavaScript events until the main thread is idle. Consider also offloading heavy tasks to a Web Worker. - Debouncing or throttling frequently fired events. - Breaking up long JavaScript tasks into smaller ones. - Using passive event listeners. - Reducing the presentational delay e.g. by using the will-change CSS property, and preferring transform and opacity over the display and position properties in animations. - Eliminating third-party scripts. Very often, third-party scripts, be it for analytics, cookie consent, or other purposes, have a significant impact on performance. Considering which of them are not absolutely necessary, and either removing them or replacing them with a more performant solution is highly recommended. - Upgrading your dependencies to make sure you are taking advantage of the latest performance-improving features. If you want to read more about the general INP optimization tips, you can check out this Vercel article. While a lot of these optimizations, such as code splitting and tree shaking, are already taken care of by modern frameworks, I believe that it’s worth going through this list to see what you can do to make your website faster and thus a better experience for your users. We will explore concrete performance tips for popular frameworks in the next article. Conclusion The change in Core Web Vitals is coming and it's going to be a significant one. The new metric, Interaction to Next Paint, is going to be much stricter than the current First Input Delay and it's going to be much harder to pass. However, the good news is that framework authors have already been working on making the frameworks more INP-friendly, and while it may take some effort, you should be able to improve your INP score. INP, however, should not be just another Lighthouse threshold we have to satisfy. This change should encourage us to look beyond surface-level metrics and dive deeper into the nuances of user interaction. As we adapt to these changes, our focus should remain on the end goal: creating a good and inclusive user experience for our visitors....

Feb 14, 2024

6 mins

JavaScriptWeb PerformanceUXSEO

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Understanding the Difference Between :focus and :focus-visible in CSS I have learned my fair share about the importance of keyboard accessibility, so I know that visual indication of the focused element is very important. But the well-known :focus pseudo-class is not always the best fit for this job. That's where :focus-visible comes in. Let's look at the differences between these two pseudo-classes and explore the best practices for using them effectively. What is the :focus Pseudo-Class? The :focus pseudo-class is a CSS selector that applies styles to any element that receives focus, regardless of how that focus was triggered. This includes focus events from keyboard navigation, mouse clicks, and touch interactions. Example Usage of :focus ` In this example, the button will display a blue outline whenever it is focused, whether the user clicks on it with a mouse, taps it on a touchscreen, or navigates to it using the keyboard. What is the :focus-visible Pseudo-Class? The :focus-visible pseudo-class is more specialized. It only applies styles to an element when the browser determines that the focus should be visible. This typically occurs when the user navigates via the keyboard or assistive technologies rather than through mouse or touch input. Example Usage of :focus-visible ` Here, the button will only show a blue outline when focused through keyboard navigation or another input method that usually requires visible focus indicators. Key Differences Between :focus and :focus-visible :focus - Behavior: Applies to any element that receives focus, regardless of the input method. - Use Cases: Ensures that all interactions with the element are visually indicated, whether by mouse, keyboard, or touch. :focus-visible - Behavior: Applies styles only when the focus should be visible, such as using a keyboard or assistive technology. - Use Cases: Ideal for scenarios where you want to provide focus indicators only to keyboard and assistive technology users while avoiding unnecessary outlines for mouse and touch users, typically required by design. Accessibility Implications :focus - Pros: - Guarantees that all users can see when an element is focused, which is critical for accessibility. - Cons: - Can lead to a suboptimal experience for mouse users, as focus styles may appear unnecessarily during mouse interactions. :focus-visible - Pros: - Enhances user experience by showing focus indicators only when necessary, thus keeping the interface clean for mouse and touch users. - Tailors the experience for keyboard and assistive technology users, providing them with clear visual cues. - Cons: - Additional considerations may be required to ensure that focus indicators are not accidentally omitted, especially in older browsers that do not support :focus-visible. - There may be cases where you want to show focus indicators for all users, regardless of input method. Best Practices for Using :focus and :focus-visible To achieve the best accessibility and user experience, combining both :focus and :focus-visible in your CSS is often a good idea. Combining :focus and :focus-visible ` Here is a Stackblitz example of what such styling could look like for you to try out and play with. Additional Tips - Test with Keyboard and Assistive Technology: Ensure that your web application is navigable using a keyboard (Tab, Shift + Tab, etc.) and that focus indicators are visible for those who rely on them. It's never a bad idea to include accessibility testing in your e2e testing suite. - Provide Clear Focus Indicators: Make sure that focus indicators are prominent and easy to see. A subtle or hard-to-spot focus indicator can severely impact accessibility for users who rely on keyboard navigation. Conclusion The :focus-visible pseudo-class offers a more refined way to manage focus indicators, improving accessibility and user experience, particularly for keyboard and assistive technology users. By understanding the differences between :focus and :focus-visible, and applying best practices in your CSS, you can create more accessible and user-friendly web applications. Remember, accessibility should never be an afterthought. By thoughtfully applying focus styles, you ensure that all users, regardless of how they interact with your site, can easily navigate and interact....

Nov 8, 2024

3 mins

AccessibilityCSSPlaywright

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Make it Accessible: Better Layout with HTML

Make it Accessible - 8 Part Series

Make it Accessible: Better layouts with HTML

The Problem

The Solution

The Implementation

Using divs right

Sections are the way to go

Articles are useful too

Conclusion

You might also like

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

New Core Web Vitals and How They Work

D1 SQLite: Writing queries with the D1 Client API

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Let's innovate together!

You might also like

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

New Core Web Vitals and How They Work

D1 SQLite: Writing queries with the D1 Client API

Understanding the Difference Between `:focus` and `:focus-visible` in CSS