DEV Community: Amber

Nevertheless, Amber Kept Coding!

Amber — Sat, 06 Mar 2021 11:39:55 +0000

When I'm asked to describe my journey into tech, I always start with codebar. This is the weekly workshop that helped give me the skills and confidence to seek out my first job as a web developer.

I got my first job in mid-2017 and the company seemed excited to take me on, even though they didn't necessarily have an intern position open. Before starting, I had built a personal website and done some coding challenges.

The internship was overall ok but there were moments that made me feel down such as being asked if I really enjoy JavaScript and if not, did I want to choose a different career? Or being jokingly asked by a colleague "what, they really pay you?!". Or being told indirectly by the lead developer that I should go away and take a bootcamp first.

Maybe they were out of line, but maybe they also had a point. Who knows? I know for sure that I still had an enormous amount to learn. But were the confidence knocks really going to help me get there? In hindsight they didn't help at all.

Luckily at the same time I had wonderful and supportive people around me. It's a shame I wasn't working with or for them instead.

My second job in tech wasn't much better on the support front. I was hired as a trainee but didn't get one-to-one meetings or help with measuring my progress. After 10 months I was told that I didn't even have the skills to become a junior developer, because a junior should "be able to take a simple project from start to finish alone". Hmm. Even back then, that opinion sounded off to me.

My third and current job is really great. I was hired by two people who value non-technical expertise and people skills just as highly as technical expertise. The job was challenging from the start but I've learned so much there. If I hadn't been given the opportunity, I wouldn't have all that valuable experience behind me.

What will 2021 look like for me? Well, it'll soon be the fourth year anniversary of my first developer job. Am I proud of what I achieved and learned in that time? Yes! Do I still feel imposter syndrome around my technical abilities? Yes! But if there's one thing I've learned, it's to make sure I am comfortable with being uncomfortable.

Besides, many people have told me they admire what I achieved so far with my tech writing, helping organise codebar in Berlin, being involved in the web community, and more.

The top three bits of advice I'd give to anyone who is new(ish) in tech, especially those who aren't white cis guys, is firstly that while there are insensitive people, there will always be 100 amazing people in their place to support and cheer you on. Being part of the web community has kept my motivation and sanity up! Secondly, it's okay to feel imposter syndrome. Everyone does, even super-technical people who make amazing things. Being a developer means you need to be comfortable with never knowing everything, and always be learning.

Lastly - everyone works at their own pace, has their own strengths, and interests. Comparing yourself to others is never a good strategy. Only compare yourself to yourself. There is no way that you from today compared to you from 6 months ago has not progressed or learned anything. Above all, try to enjoy what you're doing and don't rush things for the sake of being the "best". 🙂

Writing a Winning Web Developer Resume

Amber — Sat, 16 Jan 2021 00:00:00 +0000

It's hiring season!

Do you want a new web developer job? You might call yourself a frontend (front-end/front end) engineer, a UI developer, a full-stack engineer, a software engineer, etc. There are many different and fun combinations of job titles!

I will assume you develop things for the web, so you are a web developer.

This post will give you, a web developer, tips on how to make a good impression at companies you'd like to work at.

Who cares about a good resume? Well, unless you know people at the company you want to work at, it's likely the first impression you'll make is with your resume.

Tips on writing your web developer resume

There are loads of tips out there on how to write a good resume. Below are some of my favourites that I gathered from both applying for jobs and from reviewing applications:

Write things you achieved, not only things you did. For example, instead of "added lots of JavaScript features", try "added JavaScript features that lowered load time by 400ms". Did you save your company money? Cool! Did you reduce loading times? Awesome! Explain how you did it and how it benefited your company or customers.

Evidence for how you helped your company succeed or improved customer experience allows reviewers to imagine how you could provide value at their own company.

Make sure your listed skills are relevant. It is not good to list a skill or technology just because you read a blog post about it or because it is popular. Focus on skills and technologies you have used, enjoyed, and want to use in your next job. There's nothing much worse than listing way too many skills for a job—mostly because it shows you don't really care about your application.

Adding relevant skills gives a clearer impression of what you actually enjoy and want to do in your job.

Separate your skills section into what you use daily, weekly, and monthly. If you only used Redux once a few months back, it's best not to give the impression that you use it all the time.

Being clear about how often you use different skills or technologies helps a reviewer understand your strengths.

Keep your "education" section simple. Reviewers won't pay too much attention to it, especially since many web developers are entirely or partially self-taught.

Details about your hands-on coding experience are most often more important than details about your studies.

The person reviewing your resume is short on time but has lot of other resumes to look at. Keep your resume short and concise. Imagine a reviewer has only thirty seconds to read each application.

If you can read through your own resume in 30 seconds then it is a good length.

Look at your resume and be honest - would you enjoy reading it? If not, then try to add space between content, use whitespace well, choose a pleasant font, make sure spelling and grammar are correct, cut it down to maximum two pages etc.

A tidy, short, and well-designed resume with no spelling or grammar errors shows you put effort into your application.

Add links to your projects and (if you want) social accounts. Linking to project work on a personal website or repository is a great way to show off what you can do. But beware, reviewers will look at your source code! Linking to social accounts is good if you are comfortable with that and believe it can give a useful impression of you.

Links to projects can help reviewers learn even more about you than what you can squeeze onto your resume.

Introduce yourself and your hobbies. At the start of your resume it can be nice to introduce yourself by summarising your work experience and perhaps mentioning some of your hobbies. A reviewer may be glad to see that you have interests outside of coding.

Summarising your work experience along with your non-work experiences (hobbies) can help a reviewer see that there is more to you than coding.

Consider not adding a photo. It may seem tempting but it is not really necessary. Some companies even ask for no photo. It makes more sense for a reviewer to judge your competency by your experience and not how you look.

Humans can be biased and may unfairly judge your capabilities based on how you look.

Bonus tips for cover letters and interviews

Being a web developer isn't only about writing code. Aside from coding achievements, describe proud moments you had while interacting with others at work, or decisions you made on a problem that helped you avoid wasting time and building up technical debt. Describe how well you collaborate with others and show off your problem solving skills.

Awareness of the importance of non-coding skills is crucial to being a good web developer.

Don't address your cover letter with "Dear sir or madam". It's a good idea not to assume the gender of whoever is reviewing your application. Find another way to start your letter - for example "Dear {company name}" or "Hello!"

Neutral language ensures that everyone is respected—including your reviewer and your customers.

2020 Year in Review

Amber — Thu, 31 Dec 2020 00:00:00 +0000

I got the idea to write a my first ever retrospective for the year from Monica Lent. 🙏

What a year it has been. Back in February I had no idea what the rest of the year was going to look like. I even attended a comedy night in Berlin where one of the comedians joked that she had coronavirus, and the audience actually found it genuinely funny!

I didn't get to fly and visit any of my family or international friends this year, which has honestly sucked. I also don't see much of my local friends and family. I really miss everyone and it feels like a piece of me is missing. The pandemic has also delayed several of my important appointments.

However, despite the pandemic and its effects on me this year, I am under no illusion of my privilege:

I am happy. I am loved. I have a roof over my head. I am fed. I have disposable income. I enjoy my job. I am warm. I am healthy. I am educated. I have prospects. I have time. I can pursue hobbies. I am safe. I feel included.

Have you checked your privilege today?

— Amber Wilson (@ambrwlsn90) November 10, 2020

Anyway, in this post I want to try and focus on what I learned and achieved as a web engineer this year.

What I set out to do in 2020

For 2020, I did not set out with a particular goal in mind. I was happy to go with the flow, work hard at my job, and maybe write a couple of blog posts on the side.

One reason I may not have set goals for myself this year is because I had been working towards getting promoted to a mid-level web engineer since October 2019. I got promoted in March. I was pleased with this and did not make any more solid professional goals.

For 2021, this is going to change. I've definitely got some plans for 2021. 😎

Achievements in 2020

It felt really good to remember things I achieved this year:

Got promoted to mid-level frontend engineer.
Wrote 16 blog posts (averaging 1 post every ~23 days).
Read 12 books (I wanted to read more than twice this - oops! I'll do better next year).
Spoke on my first web podcast.
Set up my own home office space that I'm quite pleased with.
Coached remotely at codebar Berlin.
Re-designed and re-wrote my site with a static site generator called Eleventy, which turned out to be the most fun I've had coding all year.
Began a CS50 course with some nice people, so I can dive into some fundamental computer science topics.
Cooked a lot of new meals and made a recipe book so I can remember them.
Got around 40 new plants, ¾three quarters of which I managed to keep alive.

Thanks I want to give

I want to thank a few people this year:

My partner for being amazing as always. You know why you're awesome!
Jeremy Keith for his support, mentorship, and being my most fave person ever to debate the web with.
Kitty for their support, mentorship, and enviable ability to make pretty much anything.
Eva for being a bright light in the murkiness of this year, and getting people motivated to socialise and learn together.
Kristian for keeping codebar Berlin alive and kicking while staying as cool, calm, and collected as ever.

The whole of the web community this year has, as usual, been my rock. I can always count on my web friends to lift me up, support me, and motivate me to be the best I can be. I'm looking forward to being a part of this amazing community again next year. Huge love to everyone who is a part of it. ♥

Plans for 2021

Create a Career Management Document. In short, this involves writing down personal and professional achievements at least once a week. It helps you remember what you've done and learned, and helps you show this off to employers!
Write 3 to 4 blog posts a month. By the end of the year, this means I would have written at least 36 blog posts. That's more than twice the amount I wrote this year! I want to write this many because there is so much I want to learn.
If I don't understand something, research it and write about it.
Be aware of the "curse of knowledge" and continue to write posts that developers of all levels can follow along with.
Read 30 books!
Do more codewars challenges.
Write at least one codewars challenge.
Coach at least 5 times in a virtual codebar workshop.
Record a video post and/or hold a live stream to teach something about web development.
Make an Eleventy plugin (e.g. for Webmentions).
Make more cute things, because the web is a place of expression where you can let your creativity roam free. ✨

Happy New Year!

How and when to use React useCallback()

Amber — Tue, 22 Dec 2020 00:00:00 +0000

In short, React's useCallback hook is used to wrap functions. It tells React to not re-create a wrapped function when a component re-renders, unless any of the useCallback's dependencies change. But when is it necessary to use useCallback?

Many posts I have read on useCallback contain example code where a function wrapped in useCallback could just be moved outside of a component function body and into its own scope, or another simpler way. React is a smart library that is optimised to not need a hook like useCallback in most situations.

The example code in this post aims to be more "real-world". Because of this, it's necessarily quite complex. As well as using common React hooks such as useState, useEffect, it also uses a number of JavaScript methods such as the fetch API, promises, filtering, splicing, destructuring, and currying.

Even if you aren't an expert in all of the methods used in the example code, I hope you can still learn something!

Object references

I want to explain an important fundamental JavaScript concept that will make understanding useCallback easier—object references:

Functions are objects in JavaScript. Even if two functions are identical, they won't equal each other:

var dog1 = func(){console.log('14/10')}; // has a unique object reference
var dog2 = func(){console.log('14/10')}; // has a unique object reference

dog1 == dog2; // false
dog1 === dog2; // false

In comparison, if an object assigned to a variable is directly assigned to another variable, the references will match:

var dog1 = func(){console.log('14/10')}; // has a unique object reference
var dog2 = dog1; // assign the unique object reference of dog1 to a variable named dog2

// dog1 and dog2 point to same object reference
dog1 == dog2; // true
dog1 === dog2; // true

In the next section, we'll see why object references are fundamental to writing and understanding React apps.

Example app

This section will go through and explain each step of a dog park example app 🐶. If you want to take a look at the final code, here is the Dog Park GitHub repository. If you want to see a live version of the app, here is the Dog Park app.

The initial features that I built into the dog park app were pretty cool. They let you set a name for your park and choose the number of dogs in it!

Inside the function body of the DogPark component, there is a function called fetchDog. This function fetches an array of dogs from The Dog API by Postman. DogPark re-renders whenever a user interacts with any of its elements, including its child component, Dogs. Whenever DogPark re-renders, fetchDog will be re-created and receive a new object reference.

import React, { useState, useCallback } from 'react';
import Dogs from './Dogs';
import shuffle from './shuffle';

const DogPark = () => { 
  const [text, setText] = useState('');

  const handleText = (event) => {
    setText(event.target.value);
  };

  // Gets a new object reference when it is re-created.
  // It is re-created whenever DogPark re-renders.

const fetchDog = (number) => {
   const result = fetch(`https://api.thedogapi.com/v1/breeds/`)
    .then((response) => response.json())
    .then((json) =>
    shuffle(json).splice(0, number)
    );

    return result;
};

return (
  <> <h1>Welcome to {text || 'The Dog Park'}!</h1>
    <p>
      <label>Name your dog park:{' '}
        <input type="text" value={text} onChange={handleText} /> 
      </label>
    </p>
    <p>Add the perfect Dogs to your park! Maximum of 10.</p> 
    <Dogs onFetchDog={fetchDog} />
  </>
  );
};

export default DogPark;

Let's take a look at the Dogs component:

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

const Dogs = ({ onFetchDog }) => {
  const [number, setNumber] = useState(1);
  const [dogList, setDogList] = useState([]);

  // Runs the "fetchDog" function when either the number
  // variable or the onFetchDog variable changes.
  useEffect(
    () => {
      if (number && typeof onFetchDog === 'function'){
        async function fetchDog() {
          const response = await onFetchDog(number); 
          setDogList(response);
        }
        fetchDog();
      }
    },
    [onFetchDog, number] // dependencies of the useEffect
  );

  return (
    <>
      <label>Number of dogs:{' '}
        <input max="10" min="1" value={number} type="number" onChange={(event) => setNumber(event.target.value)} /> 
      </label>
      {dogList && (
        <ul>
          {dogList.map((dog) => (
            <li key={dog.id}>{dog.name}</li>
          ))}
        </ul>
      )}
    </>
  );
};

export default Dogs;

The useEffect in the Dogs component has in its dependency array the fetchDog function (which has been passed down as onFetchDog), and the numbers variable.

An input with a type of number lives inside the Dogs component. Whenever the number of dogs is changed, Dogs will re-render and fetchDog will be run. This is good! It's what we want. Note: when state that lives inside a child component changes and the child is re-rendered, this will not trigger a re-render of the parent component.

If state that lives inside the parent component changes and the parent is re-rendered, the child component will also re-render. You can usually work around this issue by wrapping the child component in React.memo. But, if a value in the parent component that the child component depends on gets a new object reference, React.memo won't work. In our app, Dogs depends on the fetchDog function coming from DogPark.

Whenever a character is typed into the "Name your dog park" input in DogPark, DogPark will re-render and fetchDog will be re-created and get a new object reference. Dogs will also re-render and because the fetchDog dependency in its useEffect has changed, the useEffect will trigger, and the fetchDog function will run. This means that the list of dogs inside Dogs will refresh every time a single character is typed into the "Name your dog park" input. That is not good! It's not what we want. But what can we do?

We could wrap the fetchDog function inside DogPark into a useCallback to ensure it is not re-created each time DogPark re-renders. However, as the fetchDog function has no dependencies, it can safely be moved out of the function body of DogPark. This is a simpler way to ensure that fetchDog is not re-created every time DogPark re-renders:

// This function now lives outside of the DogPark function
// body and so is not re-created whenever DogPark re-renders

const fetchDog = (number) => { ...};

const DogPark = () => { 
  ... // DogPark function body

Ok, so, useCallback wasn't needed. But now, a third feature is going to be added to the app that is going to require useCallback. This feature will be the ability to choose dogs that have names beginning with either A-M or N-Z.

A new state variable and two radio buttons are added. And the fetch function is moved back into DogPark and altered a little:

const DogPark = () => {
  const [text, setText] = useState('');
  // New state variable
  const [charRange, setCharRange] = useState('A-M');

  const handleText = (event) => {
    setText(event.target.value);
  };

  const fetchDog = (number) => {
    const result = fetch(`https://api.thedogapi.com/v1/breeds/`)
    .then((response) => response.json())
    .then((json) => 
      shuffle( 
        // Filters dogs depending on the value of
        // the new state variable "charRange"
        json.filter((dog) => {
          return charRange === 'A-M'
          ? dog.name[0] < 'N'
          : dog.name[0] > 'M';
        })
      ).splice(0, number)
    );
  return result;
};

return (
  <>
    <h1>Welcome to {text || 'The Dog Park'}!</h1>
    <p>
      <label> Name your dog park:{' '}
        <input type="text" value={text} onChange={handleText} />
      </label>
    </p>
    <p>Add the perfect Dogs to your park! Maximum of 10.</p> 
    {/* Two new radio buttons */}
    <p>
      <label>
        A-M 
        <input type="radio" checked={charRange === 'A-M'} onChange={() => setDogHalf('A-M')} />
      </label>
      <label>
        N-Z
        <input type="radio" checked={charRange === 'N-Z'} onChange={() => setDogHalf('N-Z')} />
      </label>
    </p>
    <Dogs onFetchDog={fetchDog} />
  </>
  );
};

The fetchDog function now relies on the charRange state that lives within DogPark. This means fetchDog has to live in the function body of DogPark. I thought I could solve this issue by passing charRange to the fetchDog function that's passed down to Dogs:

// Here, fetchDog is outside of DogPark and gets the
// charRange state as a curried value but the returned
// function is still re-created each time DogPark re-renders
const fetchDog = (charRange) => (number) => {
  ...
};

const DogPark = () => {
  ...
  <Dogs onFetchDog={fetchDog(charRange)} />
};

Even though I successfully moved fetchDog out of DogPark, fetchDog is still re-created every time DogPark re-renders.

So, fetchDog needs to stay within DogPark, and useCallback can help to avoid fetchDog being re-created every time DogPark re-renders. This means that when a character is typed into the "Name your dog park" input, even though DogPark re-renders, fetchDog keeps its object reference, and so the useEffect in Dogs is not triggered. And the dog list in Dogs is not needlessly refreshed!

// Now the fetchDog function is wrapped in the
// useCallback hook, with "charRange" in the hook's
// dependency array.
const fetchDog = useCallback( 
  (number) => { const result =fetch(`https://api.thedogapi.com/v1/breeds/`) 
  .then((response) => response.json()) 
  .then((json) => 
    shuffle(
     json.filter((dog) => { 
      return charRange === 'A-M'
        ? dog.name[0] < 'N'
        : dog.name[0] > 'M';
      })
      ).splice(0, number)
    );
    return result;
  }, [charRange]
);

When to actually use useCallback

In most use cases, your application won't be affected if a function is re-created and gets a new object reference upon each render. Even so, it can be tempting to proactively wrap a function in a useCallback to improve app performance. However, this premature optimisation can actually do harm rather than doing good. A blog post by Kent Dodds explains when and when not to use useCallback.

A good way to approach using useCallback is reactively rather than proactively. This means that, depending on your components, use it when you obviously need to, and not as a premature performance optimization. In short, don't wrap every function living inside a function body in a useCallback.

It's highly recommended that you have React linting in your development environment, so that your linter can suggest appropriate times to use useCallback.

If your linter is not suggesting useCallback, but you see that your UI is re-rendering in unexpected ways (as in the example in this post), or you have an infinite loop, check to see whether useCallback helps.

Resources

Official React docs for useEffect and useCallback
Kent Dodd's post on when to use (and not use) useCallback
Dan Abramov's guide on useEffect() offering a deep dive into React hooks

Are your Anchor Links Accessible?

Amber — Mon, 14 Dec 2020 00:00:00 +0000

One day I decided I wanted to add anchor links to each of the sections in my blog posts. Over the past few months, I'd seen these links on a lot of pages—from official documentation pages to smaller blog posts. I find them really useful for sharing sections of pages with other people!

To make the different sections of my blog posts shareable, I decided to add an anchor link to all of the section headers (<h2>s) in each of my posts.

While researching the best way to do this, something I noticed again and again was that other sites had almost always implemented anchor links in an inaccessible way.

Within a few hours, I had made a plugin to automate the addition of anchor links to my blog post sections, AND I had ensured the links were accessible!

What are anchor links exactly?

Anchor links provide a way to link to separate sections of a page. On this page, hover over the level two headings on desktop to see the links (the links are always visible on smaller screens).

In essence, an anchor link is a link containing a URL fragment. This fragment usually appears at the end of a URL. It begins with a hash character (#), and is followed by a string. This string identifies a section in a web page.

For example, a page may have a section containing a section header element such as an <h2>. This element can be given an id attribute. An anchor link is created when the value of the id matches the href value of an anchor (<a>) element on the same page. Consider the following code:

<h2 id="introduction">Introduction</h2>
<a href="#introduction">#</a>

Imagine the web page containing this code had the following URL: https://example.com/blog/nice-post/. Clicking on the hash character within the <a> element would do two things; the browser window would scroll to the beginning of the introduction section, and the URL would become https://example.com/blog/nice-post/#introduction. This URL can be shared and when opened in a browser, the page will automatically scroll to the introduction section.

Accessibility check

Of course, I wanted to make sure the anchor links I had written were accessible. I turned on VoiceOver (a screen reader for MacOS), and using caps lock with arrow keys to interact with the page's content, I moved to my section heading. I found a few issues. Below is the first version of my anchor link:

<h2 id="introduction">
  <a href="#introduction">#</a>Introduction
</h2>

When the <a> element is inside the <h2>, VoiceOver reads out "heading level 2 2 items, visited, link number introduction". A screen reader user who wanted to skip across multiple headings at once would have a nicer experience if they only heard the actual heading text (i.e. "introduction").

I realised the <a> element should exist as a sibling of the heading element, rather than a child of it. This is so that the <h2> text content remains clear. Below is the second version of my anchor link:

<a href="#introduction">#</a>
<h2 id="introduction">Introduction</h2>

When the <a> element is outside the <h2>, VoiceOver reads out "link number" for the <a> and "heading level two introduction" for the <h2>. This is a problem, as the elements are not associated with each other in any way.

Associating anchor links with what they link to is important. Some anchor links I found on a popular site have SVGs with no labels or titles as content. When there is no information about a link available, the screen reader falls back to the href value (e.g. https://example.com/blog/nice-post/). This makes the purpose of the link hard to decipher.

I realised I needed to better associate my section headings with their anchor links. Below is the third version of my anchor link:

<a aria-label="link to this heading" aria-describedby="introduction" href="#introduction">#</a>
<h2 id="introduction">Introduction</h2>

The attributes I added are aria-label and aria-describedby.

The aria label is read out by a screen reader in place of whatever child the <a> element has. This is necessary for anchor links, as these links often have a single character as text content. One alternative is to describe the link using text content, but visually hide it (hint: I removed this attribute in a later version of my anchor link - refer to the fifth version).

The aria describedby matches the id of the <h2>. When the link is focused, "link, link to this heading" is read out, followed by "introduction". This is much better, but there could be one more small improvement—having the heading before the link (hint: I removed this attribute in a later version of my anchor link - refer to the fifth version).

I realised that my anchor links would make more sense if the heading came before the link. Below is the fourth version of my anchor link:

<h2 id="introduction">Introduction</h2>
<a aria-label="link to this heading" aria-describedby="introduction" href="#introduction">#</a>

VoiceOver reads the <h2> out as "heading level 2 introduction" and the <a> as, "link, link to this heading, introduction". When the heading is first, screen reader users may be able to associate a section heading more easily with its corresponding anchor link.

While I made great progress by the fourth version of my anchor link, there are final some outstanding issues that I wanted to address. Thanks to my friend Kitty for helping me realise these outstanding issues. Be sure to keep up to date with Kitty's current A11y Advent Calendar and check out their other great posts. 🙂

First, aria-label is not actually brilliant for accessibility, as some translation services can have trouble accessing its value. So, it's best to add text content to the <a> element, and make sure to visually hide it. This way, screen readers can still access it but it'll be visually hidden for other users. Second, the # can be left in and hidden from screen readers using aria-hidden, while still being visible on the page.

Lastly, I removed aria-describedby because the anchor link's text content now references the section heading.

Here is the fifth version of my anchor link:

<h2 id="introduction">Introduction</h2>
<a href="#introduction">
  <span aria-hidden="true">#</span>
  <span class="hidden">Section titled introduction</span>
</a>

This fifth and final version of my anchor link is the one I am using on this page, along with a wrapper <div> for styling purposes. It is much better than the first version! However, if you can think of improvements, please let me know.

A word of caution

Edit (17th December): Beware, there be dragons! 🐉 I realise that including a link (that has its own text content) as a child of a heading may seem tempting (as it can make styling an anchor link easier). However, it's worth repeating that this can harm accessibility.

Version one of my example anchor link (see accessibility check) introduces the issues caused by placing a link inside a heading, but I want to provide some more context to why it is not a good idea! I'll do this by describing a handy feature of VoiceOver.

VoiceOver (and likely also other screen readers) gives a nice overview of a page's section headings. This feature, called the web rotor, is accessed by default by pressing caps lock + u while VoiceOver is on. Below are two screenshots of the web rotor comparing how headings are formed, depending on whether a link is inside or not:

VoiceOver web rotor displaying headings containing links

VoiceOver web rotor displaying headings without links

If a link that has its own content is placed within a heading, the computed heading text may be more difficult for a screen reader user to understand. This can affect how clear a page's structure is.

Another option

Edit (18th December): Despite warning against the following option above, I want to write about making a whole heading into an anchor link. Or, more specifically, wrapping the heading text content in a link. Several people across different sites have asked me why I didn't mention this option before:

Interesting reading but why do you need the # symbol in the HTML at all?

Why not just make the whole heading the link (easier clicked too!) and use ::before or ::after to put the symbol there through CSS? https://t.co/ecaDkZjJH0

— Barry Pollard (@tunetheweb ) December 15, 2020

I think both options—using an icon as a link, and making the header a link (when the content of the link is the heading text)—can be valid. However, I have a few concerns with wrapping a heading's text content in a link:

It can be useful separate the anchor link from the heading so that the link can have its own text content
It may be harder to select heading text wrapped in a link
Both screen reader and non-screen reader users may find this option less familiar and not understand its purpose

Here are two examples of sites that implement anchor links where a link wraps the text content of a heading: MDN Web Docs and The Web Almanac.

Here is a code example of an accessible anchor link where a link wraps the text content of a heading:

<h2 id="introduction">
  <a href="#introduction">Introduction</a>
</h2>

Would you rather implement anchor links in this way? It is a simpler solution. However, it is also less flexible.

Of course, the way a feature is implemented depends on your own personal use case. But, no matter which way you implement something, please remember to think of the user experience!

Automating accessible anchor links

I use Eleventy together with markdown-it to convert my markdown files into HTML files.

I tried finding a plugin that would help me to automate the addition of anchor links for all my <h2> elements. I did find one but soon realised it didn't make accessible links possible. So, I decided to make my own plugin.

There is handy markdown-it developer documentation for people wanting to create plugins. Using these docs, a markdown-it demo page, and some inspiration from a plugin called markdown-it-anchor, I wrote a plugin.

Here is a permalink to my plugin file. It recreates parsing functions for opening and closing <h2> elements from the markdown-it library. In my eleventy.config file, I use (connect) the plugin with markdown-it. This allows me to automatically add custom anchor links for all my level two headings.

Grow the IndieWeb with Webmentions

Amber — Tue, 08 Dec 2020 00:00:00 +0000

When I re-made my site with Eleventy, the pages didn't change much, but I had loads of fun adding new features. The most fun was webmentions and I'm here to convince you to add them!

First, let me step back and explain why webmentions exist—the IndieWeb.

IndieWeb

Check out this official description of the IndieWeb:

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data—indieweb.org

So, a community of personal websites, connected together, used as identities, that makes ownership of data possible. 🦄 🌈 How does this all work?

There's a great IndieWeb resource that will tell you everything you need to know
But, start here if you want to know why the IndieWeb deserves your attention
When you're convinced, see this handy page for a quick start to becoming a citizen of the IndieWeb
International IndieWebCamps are here to help—I wrote a post about my first IndieWebCamp visitNürnberg IndieWebCamp 2017 (I'm in the bottom right)

Webmentions

Now the juicy stuff!

I think the coolest thing about the IndieWeb is that it is decentralised. Currently, there is a handful of corporations that own much of our data. With webmentions, each person owns their own data and each person can communicate with others. Webmentions are basically a way to display on your personal site ways that others have interacted with your content.

On my site I display mentions and bookmarks. It's possible for someone to link to one of my blog posts within one of their blog posts or bookmarks. If they do this, I won't know about it unless they let me know about it. Letting others know you've mentioned their posts can be done manually or can be automated.

I also display likes, retweets and replies on blog posts that I have tweeted about. If the URL to my post is in my tweet, I can gather the interactions on that tweet and display them on that post. Although most social media platforms do not support webmentions, it's possible to gather them by using a great free service called Bridgy.

Some people have had webmentions on their site for many years, so I am a bit behind. Jeremy has had webmentions since 2013. But, there are more people posting content online than ever before, and personal websites aren't shown the love they used to get.

So, there has never been a more pressing need to put content creation platforms (e.g. Medium) and social media platforms (e.g. Twitter) second, and put your very own little corner of the web first 💖

I used Max Böck's post on using webmentions in Eleventy to get started. I was able to get something on the screen quickly with Max's advice, and then I refined the incoming data a bit. Here is a summary of what I did:

Sign up via Webmention.io - if this doesn't work right away, check out ways to set up your website for indie logins (I'm able to sign in by linking to my GitHub account on my site's homepage)
Add two <link> tags to your HTML document's <head> element: <link rel="pingback" href="https://webmention.io/{your-domain-here}/xmlrpc"> and <link rel="webmention" href="https://webmention.io/{your-domain-here}/webmention">
For social media mentions, sign up to Bridgy
Fetch all of your site's webmention data in JSON format using one of the webmention endpoints described by IndieWebCamp co-founder Aaron Parecki and the API token provided by Webmention.io
Shape your webmention data however you like - I filter webmentions into separate re-tweet, reply, like, mention, and bookmark functions using the 'wm-property' (check out the filter functions and before you say anything, yes I know they could be DRYer)
Use the data to display webmentions on your blog posts

Here are some of my webmentions (from my Gatsby to Eleventy post):

If all of this seems too difficult and inaccessible, please don't give up! I thought getting webmentions on my little static site would be way too difficult. But there are so many wonderful posts about setting up webmentions, and so many great people willing to help. I count myself as one of those people :) If you want to implement webmentions on your site and are stuck on any of the points I listed above, ping me on Twitter and I'll do my best to help out.

From Gatsby to Eleventy

Amber — Fri, 20 Nov 2020 00:00:00 +0000

In this post I'll compare my experience building my personal blogging site (the one you're on now) with two static site generators (SSGs) - Gatsby and Eleventy.

The first version of my site was rolled out with Bootstrap CSS and no framework, the second and third used SCSS and again no framework. The fourth version was built with a popular static site generator (SSG) called Gatsby. This SSG uses React and GraphQL. My learning curve from using no framework to using Gatsby was not huge though, as I use React and GraphQL at work.

The fifth, and at the time of publishing this post, current, version of this site uses a static site generator called Eleventy. I was a bit daunted about using this SSG, because the tools I was used to working with all day weren't baked in. This meant no default React, or GraphQL. This SSG would be a new paradigm for me to learn from scratch. I'd have to pick a templating language I had never used before, and learn how Eleventy manages data. Even so, there were a number of reasons I wanted to move from Gatsby to Eleventy.

Firstly, I'll summarise the reasons that I decided to use Gatsby in the first place. It lets people write React, takes care of a lot of performance concerns for you, and has a lot of good starter templates. So, it's excellent for getting started quickly, getting a reasonably good site created, and offers a good developer experience. This was a big pull for me, in addition to all the hype it was creating a few years ago, and the fact I could already use its baked-in tools. Also, the fact I could have my very own, nice and shiny single page app (SPA) was a plus for me, at the time.

Gatsby sounds really good, so why did I move to Eleventy? This is a question I've put a lot of thought in to. First, I want to explain that I didn't add any new features to the site between the Gatsby and Eleventy versions. The only thing that changed is that now, all the learn posts have their own page, instead of existing on one page.

Benefits gained

As my Eleventy site outputs a non-SPA, I didn't need to check or ensure that it is server-rendered, is able to be crawled by search engines to allow good search engine optimisation (SEO), or works without JavaScript. Non-SPAs do all of this by default.
A number of Gatsby plugins stopped some of the functionality on my site working. For example, Gatsby's progressive web app plugin caused my server-side rendering to stop working.
My site is a personal blog site that does not have thousands of users or masses of data. So, I don't need to make sure I'm saving on bandwidth or server resources. If I did need that, I would consider creating a SPA, as they tend to request fewer server resources across page views, compared to non-SPAs.
I don't need to force users to download large chunks of React library in their browsers. Gatsby by default forces this, and requires a plugin to ensure that React is only used on the server.
I didn't need to bother code-splitting any React components to ensure users aren't downloading my whole site on initial page load.
I was able to gain more control over performance optimisations such as image rendering. When I first released my Gatsby site, I used their image plugin but ended up disliking several things about it, such as styling inflexibility, and inability to use the <picture> element.
I know enough about web development that I can write performant code on my own. Therefore, I can do without plugins that enhance performance, but don't make it clear how they do so. Also, I prefer using my own skills to create things wherever possible, as it teaches me how things really work.
I could pick and choose what JavaScript is necessary in the client (browser), thereby limiting the size of the JavaScript a user needs to download. The only JavaScript my site needs on the client-side is for the dark mode toggle, the blog search input, a tiny (and privacy-first) analytics tool, and some linked data (JSON-LD) for SEO.
By writing lower-level template code (Nunjucks vs JSX), I felt like I had more control over the generated code, which allowed me to output better and more consistent HTML.
Gatsby has GraphQL baked in. For a lot of use cases, especially a personal blog site, GraphQL is overpowered and can be a large learning curve for some.

Challenges faced

Eleventy is newer and maintained by less people than Gatsby. Therefore, I felt that Eleventy is a bit less feature-rich and has less documentation. Although honestly, this isn't a huge deal. Firstly, I found Eleventy simpler to use (less abstract), and found the documentation covers all the most important aspects of the SSG. Secondly, almost any time I needed extra help or information, I found it in the form of excellent blog posts or example repositories created by other web developers.
One of the very few issues I couldn't find help with was the sharing of one type of data (blog post excerpts) across my Eleventy-powered site. Gatsby, along with React, makes it easy to see what data is being shared and how. Eleventy has a fantastic data-sharing API (in my case the data sharing was orchestrated between Nunjucks and the Eleventy config file). However, I found it to be quite abstracted and struggled a lot trying to get my blog post excerpt data to be easily shared across pages. In the end, I created a workaround for this, but this workaround is quite hacky. I plan to write about it in a separate post.
I had to learn how to use the Nunjucks templating language. This is only a small nitpick, as the learning curve was in no way steep.

Concluding thoughts

Using Gatsby has taught me a lot about single page apps, and that's important! Sometimes using it was frustrating, and a few things broke without me realising why or even when, but these experiences can be good lessons. Also, I am employed to work on a large SPA, and probably will continue to work on SPAs professionally for years to come, so any experience working with them is good!

I believe it is a good idea to use the least-powerful technology possible for any given task. Building with Eleventy made this possible for me. I find React and GraphQL nice to use, and I was daunted at the thought of not being able to use JSX. But, using simpler and lower-level tools such as Nunjucks made me feel more confident about my site's output (robust HTML and the least JavaScript possible), and I enjoyed the experience much more than I thought I would.

Please don't take what I've written here as a reason not to choose Gatsby over Eleventy. I chose to re-write my site in Eleventy for several reasons. I have the knowledge to build in performance and accessibility myself, I realised I didn't need an SPA for my use case, and I wanted to use simpler, less powerful developer tools. I think developers should use the tools that suit them best. There is only one thing I want to encourage you to do: no matter what tools you use, please pay attention to your site or app's final output! It's never a good idea to make users pay for your technology choices.

Caches are for Copies

Amber — Wed, 11 Nov 2020 00:00:00 +0000

When someone uses their browser to visit your website, the browser fetches files from your website's server. One example could be a CSS file. Once the CSS file has been fetched, the browser can cache (store) a copy of it. This means that, as the visitor browses your site, the CSS does not need to be fetched once again from the server.

The advantages of caching a file are: one less network request per page load, less use of the visitor's internet data, and faster load times. Additionally, CSS is a blocking resource. This means that while it is being fetched and loaded, other files have to wait to be loaded. So, the quicker CSS can be loaded, the quicker a visitor can enjoy your site.

It is important to note once again that the files cached by the browser are copies. This means that if a file living on your server is updated, the browser might not know about it. Therefore, a visitor might get the outdated copy of that file, rather than the updated one. The file will still load fast, as it is coming from the browser cache, but it will be outdated.

How do servers manage files?

The server you're using to serve your website determines which of your site's resources are cached, and how they are cached. There are many different server options available. For the rest of this post, I'll talk about the one hosting the post you are reading - Netlify.

Netlify has default cache settings. This means that with no effort on my part, I can write my website, deploy it, and share it without needing to worry about configuring cache settings. There is a blog post about Netlify's default cache settings entitled "Better Living Through Caching".

I briefly mentioned earlier the issue of getting an outdated file from the cache. Netlify admit that "cache invalidation is one of the hardest problems in computer science" and that they have found a way around this issue:

“max-age=0, must-revalidate, public” = “please cache this content, and then do not trust your cache”. This seems a bit counterintuitive, but there’s a good reason. This favors you as a content creator — you can change any of your content in an instant.

So, no visitors will be served outdated files. However, all files are re-requested on every single page load. This would be no good, except that Netlify uses "e-tags". These are hash values (long strings of unique characters). The server and browser share the e-tags. If a file changes on the server, for example a CSS file, the e-tag value changes, the browser notices, and the changed file is requested.

Additionally, Netlify makes the constant checking of files faster using their CDN (content delivery network) and HTTP/2. Please look up these two things, as discussing them is beyond the scope of this post.

Trust, then verify

It is a really nice thing in modern web development to be able to enjoy stuff done for you automatically by your browser and server. This doesn't mean that you shouldn't know how it all works, though.

If a server such as Netlify offers default cache settings, it pays to look up what they are, and how they work. A server's default cache settings are unlikely to be the best for every website.

If it is necessary to change cache settings for your website, look up how to manually create your own settings. Here is a post on how Netlify users can set custom cache headers.

Accessible Link Text

Amber — Thu, 05 Nov 2020 00:00:00 +0000

I use a bookmarklet tool called Tota11y, which gives me a quick overview of my site's accessibility. I opened it on my site's homepage and clicked "link text". The tool flagged not one, but SIX inaccessible links. Woops!

The homepage, GitHub, Twitter, and LinkedIn links were all flagged for the same reason. There was no text between their opening and closing <a> tags, only an SVG. Even though the tool flagged these links, I didn't have to change anything. This is because each SVG already had a <title> element, paired with a <description> element to aid accessibility. A screen reader will read out the values of the title and description elements.

I was a bit confused why the 'learn' and 'about' navigation links were flagged, so I checked Tota11y's source code. The words 'learn' and 'about' are listed as stop words. I believe these words are singled out because they can be used alone or out of context. However, I think that both words make sense in my navigation bar. So, I ignored the warning.

I was happy that I didn't have to add any new code in order to make the six flagged links accessible! If an accessibility audit flags any links on your site, and you determine that they are in fact inaccessible, there are a few things you can do.

One method is to add a <span> next to the existing text that is hidden (this post describes a method for visually hiding text using CSS). This would make the text invisible in the UI, but a screen reader would still read it out.

Another similar method is to add more descriptive (non-hidden) text to links, just as I have done for the link in the previous paragraph.

The most common method is probably the aria-label attribute. This is popular because the value of this attribute is read out by a screen reader even if the link already has text. For example, for my 'project' link, I could have added aria-label="a selection of my projects".

A screenshot of the VoiceOver for Chrome screen reader announcing the aria-label of the 'projects' link

Note 1 of 2: please see this post on aria labels for the important difference between aria-label and aria-labelledby (hint: aria-label values are not always easy for translation systems to access).

Note 2 of 2: try to use a variety of accessibility tools to audit your web pages. It isn't possible to catch all accessibility issues with one tool. It's also probably not possible to catch all issues with ten of them. Manual testing is highly recommended! By that I mean using a screen reader and keyboard to tab around your web pages.

More resources

Make Your Own Dev Tool

Amber — Wed, 19 Aug 2020 00:00:00 +0000

Bookmarklets - a cool personal dev tool

I have just found out what bookmarklets (aka favelets - a term coined by my friend Tantek back in the early 2000s) are and I like 'em! So what are they?

Bookmarklets run a JavaScript (JS) script against the DOM of the current document loaded in the browser. They allow a way to alter the DOM at the press of a button. They may not offer all that a browser extension or add-on can, but they can still be super handy, and also do not require downloading or installation of software.

What's a nice example of a bookmarklet? Here is a nice accessibility bookmarklet called Tota11y to try out! Thanks to Jeremy for showing me this one 👍

How can a bookmarklet like Tota11y be used? First, the bookmarklet's link needs to either be saved as a bookmark, dragged into the browser's bookmark toolbar, or be available to be clicked on a web page. Second, while on a valid website, the bookmark containing the bookmarklet link should be clicked to run the bookmarklet's code.

How bookmarklets work

First you should know (or be reminded) that in a browser, bookmarks are made up of URIs (uniform resource identifiers). Each URI consists of a protocol such as http:, https:, file:, etc., which is followed by a string. An example is https://cat-bounce.com/. The https: is the protocol, and the string is the domain.

There is also a javascript: protocol. The browser treats this protocol and its following string just like a JS application. When visiting a link that is using this JS protocol, the JS code it contains is executed. If such a link is bookmarked, it is called a bookmarklet!

Something to note is that a link usually works by sending the user to a new page. To prevent a bookmarklet from triggering a page reload, the JS code that makes up the bookmarklet should return an undefined type. To do this, an anonymous, self-executing function can be used (i.e. one that does not return a value, doesn't have a name, and executes immediately).

The Tota11y bookmarklet example has a link that points to a hosted JS file. This is because the link would be pretty messy if all the JS code was included as a single string within it. Below is what the Tota11y bookmarklet's link (in a beautifed format for readability) looks like:

javascript:
  (function()
    {
      var tota11y=document.createElement('SCRIPT');
      tota11y.type='text/javascript';
      tota11y.src='https://khan.github.io/tota11y/dist/tota11y.min.js';
      document.getElementsByTagName('head')[0].appendChild(tota11y);
    }
  )();

In order for a bookmarklet to point to a hosted JS file, its URI needs to contain a few things. At the very least,it should create a new script element, make this element's source (src) the hosted JS file, and then append this script to the head of the document.

Making your own bookmarklet

I tried making a bookmarklet and found it was really easy to get started.

I decided that I'd try something really simple that does not use a hosted JS file, but contains all the JS code in one line. So I made a bookmarklet to put a red border around each paragraph on a page. Here's what it looks like:

javascript: 
(function(){
    let paragraphs = document.getElementsByTagName('p');
    for (let i=0; i < paragraphs.length; i++){
      paragraphs[i].style.border = '3px solid red';
    }
  })();

It is also possible to put bookmarklet code into the href of an <a> element, that you can then drag into your bookmarks or your bookmark toolbar. If you like, try dragging the following link into your bookmarks and clicking on the resulting bookmarklet (refresh the page to remove the effects)!

Paragraph border maker

Some things to note

A browser will automatically encode any characters within a URI that it does not understand (such as quotation marks, spaces etc.) so that a bookmarklet can run smoothly.

As bookmarklets contain JS, there are security concerns to be aware of when using bookmarklets created by others. However, making a few of your own bookmarklets for personal use, or using ones that have been shown to be trustworthy, is fine. More than fine - it's great!

Why are bookmarklets so great? You can make a separate folder for your bookmarklets within your bookmarks folder. Then you can place this bookmarklets folder in your bookmark toolbar for your own list of easy-access, personal dev tools.

Sometimes browsers may cache bookmarklet code, so changes made after it is added won't show up.

Check out this nice video on bookmarklets (Chrome-focused) that covers what I have written about in the "Making your own bookmarklet" section.

I am completely new to bookmarklets so I may not have covered every essential thing regarding them. I really found them super easy and nice to get started on though. As usual I learn more about them as I keep trying them out!

CSS Tips for New Devs

Amber — Mon, 04 May 2020 08:53:34 +0000

May the 4th be with you!

If you enjoyed that greeting you'll love the nerdy stuff that is to follow. Over one evening, I wrote down some of the CSS tips I've learned over a few years of being a developer and put them in this post 😃. I saved my most important tip for the end of the list. Enjoy!

CSS stands for Cascading Style Sheets. This means that they are style sheets that cascade. Take a look at this brilliant site on the CSS cascade (that has quizzes!) to learn more.
Various online games have been made to help people learn CSS and they are amazing to this day! https://flexboxfroggy.com/ for Flexbox, https://cssgridgarden.com/ for Grid, and https://flukeout.github.io/ for CSS selectors.
One part of the CSS Cascade is Specificity. HTML elements can be styled in a number of ways. Some of your styles may be overridden depending on the way you've targeted your element for styling. Writing inline styles will override any style in a stylesheet. An id on an element will override a class, and a class will override targeting the element directly. In the spirit of the day this blog post was created, see this post on calculating CSS specificity - Star Wars edition! Note that Many CSS-in-JS libraries are designed to take care of specificity issues for you by scoping styles to single files. It still absolutely pays to learn about it though!
It's not a good idea to fix shortcomings in your HTML with CSS. Fix your HTML first!
There are pseudo elements in HTML that can also be styled and provide handy hacks when it comes to styling elements. The most well-known are ::before and ::after, but there are seven pseudo elements in total.
CSS allows organisation of elements on web page. There are even some layout systems - the most well-known include Grid, Flexbox, floats and table (in order from newest to oldest).
If your project's browser support allows, definitely try some of the newest CSS out there, e.g. Grid. If people are too afraid to try new CSS even if it doesn't have full browser support yet, then nobody would ever try it out! Check browser support with https://caniuse.com.
Elements on a web page can be sized and spaced using quite a number of different values. There are px, ems, rems, ch, vw, vh, %, etc. When building more complex web pages, the interplay of element sizing or spacing values can make a big difference in the ease and maintainability of styles.
For every shorthand way of writing CSS, it's more than likely that there is a long-hand way to write it. E.g. margin: 20px 30px 10px 15px can be margin-right: 30px, margin-left: 15px, margin-top: 20px, margin-bottom: 10px. Writing the long-hand version can sometimes be clearer for other developers reading your CSS!
You can change CSS right in your browser's dev tools (to open them, right click the browser window and choose "inspect" or "inspect element"). The great thing is, none of the styles will be saved so you can experiment here! Another great thing about the dev tools is the "computed styles" tab, because this shows you exactly what styles are currently applied to an element. This can be really helpful when it comes to debugging your CSS!
As well as computed styles, the dev tools will also show the layout styles, giving you a clear indication what margin, padding and borders are applied to an element.
Stack Overflow and CSS Tricks are two of your CSS-related-questions friends (but beware of outdated answers).
Check the MDN docs for up-to-date CSS documentation. They even have some live playgrounds for many CSS properties - e.g. https://developer.mozilla.org/en-US/docs/Web/CSS/transform.
It pays to learn about position relative and absolute. By this I mean parent elements with position: relative that have child (nested) elements with position: absolute.
A web page tends to consist of a lot of different-sized boxes. Every element is actually viewed as a box by the browser - headings, paragraphs, spans, everything. Each box consists of 4 things - the element's content, its padding, margin and border. By default, the box model states that any border or padding you add to an element will be added on top of the element's width or height. This can be confusing or counterintuitive. Setting box-sizing: border-box tells elements not to grow in width or height when border or padding is added. Instead, the content size is adjusted.
Don’t remove the default browser focus outlines unless you are sure you are managing your own focus state correctly. Removing the outlines could prevent a user from being able to navigate your site using assistive technology or the keyboard.
There are a lot of CSS preprocessors that allow you to generate (compile) CSS using their own unique syntax, which often offers a way to write CSS in a more organised, shorter or functional way. Beware using preprocessors, as they can be overkill for many projects, create over-sized compiled CSS, or make CSS hard to refactor in the future. Examples of preprocessors include Sass, Less, and Stylus.
CSS custom properties (aka CSS variables) are a way for developers to move away from CSS preprocessors and still get the benefits. They allow you to define specific values under a variable name. These variables can be used on any number of elements and if the value needs to change, it only has to be changed in one place. E.g. a variable containing a large font size such as --fontSizeL: 150% can be used on many different elements like this: font-size var(--fontSizeL). If the value needs to change to 140%, it can be done once quickly and easily. There is no support for Internet Explorer, but polyfills exist to get around this!
CSS has a lot of weird quirks that you’d not think of. If you don’t know why some CSS is not doing what you want, feel free to search for the reason. Just a couple of examples include images being display: inline-block so that they have an implicit bottom spacing, or that you need to set min-width: 0 on flex items to stop the items from growing infinitely.
CSS doesn't have to be overly complex. There is most often a simple solution to a styling problem. I can't tell you how many times I have over-used CSS and hacked a fragile solution together. If I had looked at the DOM (document object model - something you can see within your dev tools) and thought about what was happening properly, I could've saved myself time and many lines of unmaintainable CSS.
As with all programming (and to non-believers, yes, CSS is programming 😉), if your head is too far into the CSS you’ve been doing, take a break and go back to it later. It can work wonders.
Check out some blog posts about the history of CSS and who works on it today. There is still an active CSS working group thinking about the future of CSS!
You may have heard of CSS3, but don't hold your breath for CSS4. The CSS working group is working on different CSS feature modules, each of which have their own 'levels' or version numbers, e.g. Flexbox version 1, or selectors level 4, etc.
CSS expertise comes with time! While CSS is easy to start with and gives you immediate visual results, mastering it takes time and this is perfectly okay 😃. It is the same for everyone.

ARIA labels

Amber — Sat, 15 Feb 2020 14:12:45 +0000

Recently, I've been chatting about accessibility with two of the biggest experts on the subject. Also, the web developers I work with at N26 take accessibility very seriously. This got me interested enough to read some blog posts on the subject. Many of these posts mentioned 'landmark roles' - one of which is 'navigation'. The navigation landmark is for identifying groups of links that help users navigate around a site, or within a page. You can give an HTML element a role of navigation (please see code block below):

<div role="navigation" aria-label="Main navigation">
  <!-- list of links -->
</div>

However, the nav element in HTML is automatically assigned role = navigation, making it the best element for creating navigation sections. It is always best to use native, semantic HTML elements where possible, to avoid writing too much ARIA.

For developing the N26 web app, we use agnostic axe to warn us when accessibility is not up to scratch. In my console, it notified me of the following:

New aXe issues
moderate: Ensures landmarks are unique https://dequeuniversity.com/rules/axe/3.5/landmark-unique?application=axeAPI
Element: <nav>…</nav>

I knew from my reading that this warning came from having two nav elements (i.e. two elements with role=navigation) on the same page. The nav elements need to be distinguished from each other in some way. This is where aria-label and aria-labelledby come in.

My first attempt at a fix involved using aria-label (please see code block below):

<nav aria-label="Text describing the purpose this navigation">…</nav>
<nav aria-label="Text describing the purpose this navigation">…</nav>

Whatever value is given to aria-label will be accessible to screen reader users, making it much easier to understand a HTML page's structure and purpose. The labels should provide a concise description of what each navigation element contains.

After using aria-label, the warning was gone from my console! Was I all done? I could have been. However, I soon learned something else. Some translation systems (e.g. Google translate) might not translate the value of aria-label. Luckily, there is a way around this (please see code block below):

<nav aria-labelledby="main-navigation">
  <h2 id="main-navigation">
    Text describing the purpose this navigation
  </h2>
</nav>
<nav aria-labelledby="secondary-navigation">
  <h2 id="secondary-navigation">
    Text describing the purpose this navigation
  </h2>
</nav>

Here, an aria-labelledby value of a nav matches the id value of an h2. The h2 contains human-readable text. It is this text that will be accessible to screen reader users. The element containing this text can also be a hidden element which exists purely for screen readers. In this case, the hidden element of course still needs text content. This method has an advantage over aria-label in that the human-readable content is contained in a text node rather than an attribute. Text nodes are easier for some translation systems to access. See Heydon's post for more information.

I learned all of this today and I am very grateful for the knowledge. Now I know it, I'll be able to apply it wherever needed in my HTML.

For more information on the nav element, see this post from html5 doctor.

Originally posted on my personal site.