DEV Community: Corina: Web for Everyone

Testing for SC 2.5.3 Label in Name with Playwright

Corina: Web for Everyone — Tue, 21 May 2024 17:45:43 +0000

What is Success Criterion 2.5.3?

It’s a WCAG (Web Content Accessibility Guidelines) rule that requires careful naming of interactive elements and headings. For these types of elements, the browser has to compute an accessible name which may be different from the visible text or label of that element. The 2.5.3 criterion requires that the accessible name contains the visible text. In fact, as a best practice, the start of the accessible name should match the visible text.

For example, given a button with visible text “Submit”, an accessible name of “Submit form” will guarantee compliance with the rule, but “Form submission” will not.

This rule helps two groups of users:

Speech input users who rely on the visible text to activate an interactive element. Since voice software can recognize an element only by its accessible name, a user’s command should match the name assistive tech will recognize.
Sighted users who rely on screen readers. With this rule in place, they will hear the same text as the one they see on the screen.

Testing conformance with 2.5.3

In the past, I used to rely on Google’s Lighthouse scans.

Note: Google's Lighthouse scans use Deque's axe-core library.

Several months ago my code unexpectedly failed this rule a couple of times, so I decided to develop my own test. I just wanted to explore the criteria such an evaluation might use. Since the source of failures were elements with aria-label, I decided to design the test around them.

This is certainly not to say that aria-label is the recommended way to name an interactive element. Quite the contrary. I just didn't know any better at the time. My advice: use it when semantic HTML can’t take you any further, and even then you should first consider better ARIA solutions (like aria-labelledby) or CSS solutions (like visually-hidden text).

First approach: collect all elements with `aria-label`

This approach has one advantage: once all elements are collected, it takes the visible text and the accessible name (given by the aria-label value) and compares the first few words.

test.beforeEach(async ({ page }) => {
    await page.goto('https://webforeveryone.us/');
});

test('Controls conform with SC 2.5.3 Label in Name', async ({ page }) => {
    const elements = page.getByRole('main').locator('[aria-label]');
    const elementsCount = await elements.count();
    const errors: string[] = [];
    for (let i = 0; i < elementsCount; i++) {
        const element = elements.nth(i);
        const visibleText = await element.innerText() ?? "";
        const accName = await element.getAttribute('aria-label') ?? "";

        if (visibleText && accName) {
            const textToCompareFromVisible = firstNWords(visibleText, 3).toLowerCase();
            const textToCompareFromAccName = firstNWords(accName, 3).toLowerCase();
            const match = textToCompareFromAccName === textToCompareFromVisible;
            if (!match) {
                errors.push(`Acc name "${accName}" should start with "${visibleText}"`);
            }
        }
    }  
    if (errors.length > 0) {
        throw new Error(`Label in Name test failed:\n${errors.join("\n")}`);
    }
});

function firstNWords(text: string, n: number) {
    return text.split(" ").slice(0, n).join(" ");
}

Why this first approach is far from perfect

It excludes any elements named with aria-labeledby, the other ARIA attribute used to compute the accessible name. This attribute supersedes any attribute, including the aria-label.
It excludes elements whose accessible name is based on visually-hidden text or attributes like the alt text for images.
It does not try to match the entire string of the visible text with the start of the accessible name.

Note: When testing with Windows’ speech software, I can successfully activate a control using the first two words of the visible text or label. Of course, one testing scenario should not speak for all possible contexts, but for the purpose of this test I went with the assumption that the speech software can recognize an element based on the first few words of its accessible name. This assumption takes care of the speech input users that SC 2.5.3 is concerned with, but it ignores the sighted screen reader users. For them, a scenario in which the visible text and the accessible name diverge significantly after the first few words is not a great experience.

The motivation to try a different approach was driven not only by these drawbacks but also by necessity. Lighthouse has removed the 2.5.3 rule from its tests, and it’s only available with the axe-core Pro account. Below is my second, still very raw attempt. I’m hoping to improve on it as I keep tinkering with it.

Second approach: manually select all target elements

This is more labor intensive. Playwright’s Codegen feature helped with collecting the information about each clicked element:

await page.getByRole('Learn accessibility').click();

and then I used it to set up the Locator object:

const buttonLearnA11y = page.getByRole('link', { name: 'Learn accessibility' })

The ideal solution would involve grabbing a Locator using page.getByRole('link', { name: 'Some name' }) or page.getLabel('link', { name: 'Some name' }) and then directly accessing the name from the Locator object itself. As far as I can tell, this is not possible, so I had to manually add the name value to the checkLabelInName function:

const labelCheck = await checkLabelInName(buttonLearnA11y, 'Learn accessibility');

Here’s the entire code, including the helper functions:

export async function checkLabelInName(element: any, accName: string) {
    const visibleText = await element.innerText();

    if (!visibleText.trim() || !accName.trim()) {
        return true;
    }

    const normalizedVisibleText = normalizeText(visibleText);
    const normalizedAccName = normalizeText(accName);

    const numWordsToCompare = Math.min(countWords(normalizedVisibleText), countWords(normalizedAccName));

    const textToCompareFromVisible = getWords(normalizedVisibleText, numWordsToCompare).toLowerCase();
    const textToCompareFromAccName = getWords(normalizedAccName, numWordsToCompare).toLowerCase();

    return textToCompareFromVisible === textToCompareFromAccName;
}

function normalizeText(text: string) {
    return text
        .replace(/[,.!?;:"'()]/g, '')  
        .replace(/\s+/g, ' ')          
        .trim();                      
}

function countWords(text: string) {
    return text.split(' ').length;
}

function getWords(text: string, count: number) {
    return text.split(' ').slice(0, count).join(' ');
}

test.beforeEach(async ({ page }) => {
    await page.goto("https://webforeveryone.us/");
});

test.describe("home-main controls conform to 2.5.3 Label in Name", () => {
   test("Learn accessibility BUTTON conforms to 2.5.3 Label in Name", async ({ page }) => {
        const buttonLearnA11y = page.getByRole('link', { name: 'Learn accessibility' })
        const labelCheck = await checkLabelInName(buttonLearnA11y, 'Learn accessibility');
        expect(labelCheck).toBeTruthy();
    });

    // more 2.5.3 Label in Name tests
}) ;

Why the second approach in not perfect

Quite labor intensive (or maybe Playwright has been spoiling me too much with its Codegen voodoo?! Is this even an excuse when judging the quality of a test?!)
It relies on the tester’s accuracy and knowledge of which elements need to be tested (I know, I know. That's the tester's job ...)
The test passes in scenarios where the rule simply does not apply. As test defects go, this is not an outrageous one, but it's still misleading.

This is it! Right now, I'm out of ideas. As I'm adding this test to all the pages of my site, I will (hopefully) come across instances of false positives and other inconsistencies that will help with the next iteration.

Thank you for reading! I'd appreciate your thoughts or hints on how to improve my approach.

Image credit: Photo by Alex Kondratiev

Image description: Glass test tubes containing green, orange, and blue liquids.

Testing for Accessibility with Playwright

Corina: Web for Everyone — Mon, 27 Nov 2023 04:18:11 +0000

Merging my favorite tool with my passion: 🎭 + A11y

For my first accessibility tests, I decided to start with a couple of ready-made scripts provided in the documentation. These tests use the @axe-core/playwright package to evaluate a wide range of accessibility rules.

Some of these rules align with specific criteria from the Web Content Accessibility Guidelines (WCAG), while others are considered best practices but not explicitly required by WCAG.

Testing for WCAG A Compliance

If you are interested in scanning an entire page for accessibility violations, the following test is a good start:



test.describe('homepage', () => { 
  test('should not have any automatically detectable accessibility issues', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/'); 

    const accessibilityScanResults = await new AxeBuilder({ page }).analyze(); 

    expect(accessibilityScanResults.violations).toEqual([]); 
  });
});

If you prefer to focus on rules that correspond to particular WCAG criteria, you could use AxeBuilder.withTags().

I also started with AxeBuilder.withTags(). My targets were the WCAG A guidelines for which I used the wcag2a and wcag21a tags.



import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('should not have any automatically detectable WCAG A violations', async ({ page }, testInfo) => {
    await page.goto('https://corinamurg.netlify.app/');

    const accessibilityScanResults = await new AxeBuilder({ page })
        .withTags(['wcag2a', 'wcag21a'])
        .analyze();

    expect(accessibilityScanResults.violations).toEqual([]);
});

I did not expect to see any violations, and indeed there were none. Moving on!

Unexpected Results with WCAG AA

A different story with WCAG AA! Again, I did not expect any violations, but there were quite a few!



test('should not have any automatically detectable WCAG AA violations', async ({ page }, testInfo) => {
    await page.goto('https://corinamurg.netlify.app/');

    const accessibilityScanResults = await new AxeBuilder({ page })
        .withTags(['wcag2aa', 'wcag21aa'])
        .analyze();

    expect(accessibilityScanResults.violations).toEqual([]);
});

I had previously run the axe Dev Tools scan and the page received a clean bill of health:

But the Playwright scan revealed SIX(!) elements with color contrast issues:

three with the sample-project--title class, and
three with the sample-project--description class.

All failure summaries were similar to this one:



+ "failureSummary": "Fix any of the following:
+    Element has insufficient color contrast of 2.61 
       (foreground color: #a0a0a0, 
       background color: #ffffff, 
       font size: 14.4pt (19.2px), 
       font weight: normal). 
       Expected contrast ratio of 4.5:1",
 +   "html": "<p class=\"sample-project--description\">
                    React, Typescript
              </p>",
 +    "impact": "serious",
 +    "none": Array [],
 +    "target": Array [
 +    ".my-portfolio-site > .sample-project > .sample-project--description",
 +         ],

Troubleshooting the Color Contrast Issue

It was quite the head-scratching moment because the CSS declaration blocks told a different story.



.sample-project--title {
    align-self: start;
    display: inline-block;
    font-size: 1.7rem;
    font-weight: 500;
    margin-top: 32px;
    padding-bottom: 10px;
    position: relative; 
}



.sample-project--description {
    font-size: 1.2rem;
    font-weight: 400;
    margin-top: 0;
}

To determine the color contrast of an element we need to know the foreground and the background colors. In this case, neither element has specific colors, so they inherit from the body element: white background, and black text. Doesn't this combination give the best color contrast one can ask for?! 🤔

And yet, the test revealed a color-contrast violation … Not only that, but it was referring to a text color that my site does not even use: foreground color #a0a0a0.

This actually gave me the idea to be more specific about the colors for each element. So, I added color:inherit. And … surprise! It worked ... for the sample-project--title elements, that is! Running the test again revealed only 3 errors, one for each of the three sample-project--description elements.

After this semi-victory, I assumed the test needed more specificity so I replaced color:inherit with the actual hex values. No luck! (and in hindsight, no surprise. I was at a point where I was just guessing …) 😕

Looking for Help from the WebAIM’s Contrast Checker

Was the size of the text too small? I wouldn’t have thought that to be the cause of the violation, again because of the black text on white background combination. Still, I checked WebAIM’s color contrast tool just to make sure (and because I did not know what else to do!!!):

Here’s also WebAIM’s specification about the relationship between font size and expected color contrast:

WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders).

WCAG Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.

Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger.

Back to my trouble-making elements: with a font size of 19.2px and a contrast ratio of 21:1, they should pass not just the AA guidelines, but the AAA ones as well!

Will AAA Fail Too?!

Sigh of relief … running the WCAG AAA scan found no errors with those particular elements. But wait ... why not? They failed the lower standard. How come they passed the higher standard?! 😲

There were a few errors regarding another elements, and for good reasons. This is an example of one of the failure summaries:



+ "failureSummary": "Fix any of the following:
+    Element has insufficient color contrast of 4.5 
       (foreground color: #1a73c6, 
        background color: #f6f6f6,
        font size: 12.0pt (16px), 
        font weight: normal). 
        Expected contrast ratio of 7:1",
+    "html": "<span class=\"footer-heading\">Profiles</span>",
+    "impact": "serious",
+    "none": Array [],
+    "target": Array [
+           ".footer-right--social > .footer-heading",
+         ],

This is the CSS declaration block for one of the elements with the AAA violations:



.footer-heading {
    background-color : #f6f6f6
    color: #1a73c6;
    font-size: 1rem;
    font-weight: 500;
    text-transform: uppercase;
}

At 16px, the font-size for this element is considered “normal” so it needs a contrast ratio of 7:1 to meet the AAA guideline. The failure summary confirmed (correctly this time!) the contrast checker’s result: the element’s contrast ratio is only 4.5:1, good enough for AA but falling short of the AAA guidelines.

Back to the WCAG AA failed test …

How much time is too much time investigating and troubleshooting a problem when you have no idea why it exists in the first place? After the failed attempts mentioned above, I scoured the documentation, reached out to Playwright’s Discord community, and opened a bug issue on Playwright’s GitHub repo. It had to be a bug, there was no other explanation I could find.

The response was swift:

This sounds like a bug which should be reported at @axe-core/playwright or axe-core since Playwright does not do anything related to axe.

Ahhh ... if it’s indeed a bug, as I had assumed, it must be from the package that actually checks for violations. Why did I not think about that?!

Another round of electronically leafing through another documentation. So far, no answers. But will soon find a way to submit a bug report. Stay tune! 😎

Update

I did reach out to the axe-core team and they were super helpful. They explained that AxeBuilder analyze() runs as soon as the DOM is ready. Since my code has CSS fade-in transitions, they get in the way of the Playwright test. Adding a 2-second timeout solved the problem.

Coming Up

In the mean time, I have another a11y bug to deal with. Found by Google’s Lighthouse extension:

Can you guess my next challenge?

Write a test in Playwright that will check for the following WCAG guideline:

For each user interface component that includes a visible text label, the accessible name MUST match (or include) the visible text in the label.

Resources

WebAIM Contrast Checker

Debbie O’Brien’s Playwright Series on dev.to

Playwright Documentation

Image credit: Photo by Alex Kondratiev

Description: The image shows a hand pouring a blue liquid from a glass test tube into a flask with red liquid, and another hand pouring a green liquid into the flask. The background is plain white.

Using Codegen

Corina: Web for Everyone — Mon, 20 Nov 2023 03:51:52 +0000

Start with confidence with autogenerated tests! 🎭

Playwright allows you to generate test scripts based on your interactions with the UI. This feature is known as Playwright's code generation capability. When you interact with your app's UI elements during a testing session, Playwright records these interactions and generates corresponding test scripts. Quite straightforward!

Steps to Get Started with Codegen

Step 1. Open the Testing sidebar and click Record new.
Playwright will open a new test file, as well as a blank browser page.

test('test', async ({ page }) => {
  // Recording...
});

Step 2. In the browser, type the URL for the site you want to test.

Step 3. Once typed in, the URL automatically gets recorded inside the testing file:

test('test', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/');
})

Step 4. Now Playwright expects you to manually perform actions on that site, so it can translate these actions into test scripts.

For more details, visit Playwright's documentation on codegen

My Codegen Session

My goal was to test the links inside my navbar. As I was manually clicking every link in my navbar, Playwright translated these actions into test scripts. At the end, my test function looked like this:

test('test navigation links', async ({ page }) => {
  await page.goto('https://corinamurg.netlify.app/');
  await page.getByRole('banner').getByRole('link', { name: 'Corina Murg' }).click();

  await page.getByRole('navigation').getByRole('link', { name: 'Home' }).click();

  await page.getByRole('navigation').getByRole('link', { name: 'Projects' }).click();

  await page.getByRole('navigation').getByRole('link', { name: 'Accessibility' }).click();

  await page.getByRole('navigation').getByRole('link', { name: 'About' }).click();

  const page2Promise = page.waitForEvent('popup');
  await page.getByRole('navigation').getByRole('link', { name: 'Blog' }).click();
  const page2 = await page2Promise;
});

My assumption was that the automated test would

check that each link is clickable, and
check that it opens the expected page.

It just happens that when I learn, I like to break the code and notice how it reflects in the browser. So, I disabled the paths to the Blog and the About links and expected an error for each link.

Well, this did not happen! At least not for both links, that is. I received the error for the Blog link (note: this link connects to an external site and has an target="_blank" attribute), but I did not receive the error for the About link. 🤔

Help came from the (awesome) Playwright documentation! Here's what it says about .click() method:

Under the hood, this and other pointer-related methods:

wait for the element with the given selector to be in the DOM

wait for it to become displayed, i.e., not empty, no display: none, no visibility: hidden

wait for it to stop moving, for example, until the CSS transition finishes

scroll the element into view

wait for it to receive pointer events at the action point, for example, wait until the element becomes non-obscured by other elements

retry if the element is detached during any of the above checks

It turns out that in the case of my 'About' link, the .click() method checks if an element with the role of 'link' and the name 'About' exists within the navigation, and then it clicks on that element. BUT it does not check whether the link leads to a specific destination!

Checking a Link to an External Page

There was no error for the About link, but then why did I get the error about the Blog link? The clue was in the last three lines of code:

const page2Promise = page.waitForEvent('popup');

await page.getByRole('navigation').getByRole('link', { name: 'Blog' }).click();

const page2 = await page2Promise;

When a page is opened by a target="_blank" link, we get a reference to it by listening to the popup event on the page. The waitForEvent() method waits for the popup to happen within a given timeout. If the popup event doesn't occur, Playwright will throw an error.

One caveat: the waitForEvent() method and the popup event help confirm the link's functionality by triggering its action, yet they don't verify if the link navigates to a specific URL. To make sure the link led to my blog page, I had to add additional lines of code. I also personalized the code by renaming the popup promise variable:

const blogPromise = page.waitForEvent('popup');

await page.getByRole('navigation').getByRole('link', { name: 'Blog' }).click();

const blog = await blogPromise;

// WAIT FOR THE BLOG PAGE TO LOAD, THEN CHECK URL AND TITLE
await blog.waitForLoadState();
await expect(blog).toHaveURL('https://dev.to/corinamurg');
await expect(blog).toHaveTitle('Corina: Web is for Everyone - DEV Community');

Checking the Link to an Internal Page

As I mentioned above, using .click() is a necessary start, but not sufficient on its own. We have to add extra checks or assertions to verify the full functionality of a link.

For my (internal) navbar links, I added assertions for all the URLs and a check for the 'About' page that a certain text was visible:

await page.getByRole('navigation').getByRole('link', { name: 'Projects' }).click();
await expect(page).toHaveURL('https://corinamurg.netlify.app/projects');

await page.getByRole('navigation').getByRole('link', { name: 'Accessibility' }).click();
await expect(page).toHaveURL('https://corinamurg.netlify.app/accessibility');

await page.getByRole('navigation').getByRole('link', { name: 'About' }).click();
await expect(page).toHaveURL('https://corinamurg.netlify.app/about');
await expect(page.getByText('My Career in a Nutshell')).toBeVisible();

Conclusion

What should you focus on while in codegen mode?

First, decide on what tests you want to automate. Then, when using the codegen feature, interact with those elements of your web application that are relevant to the test you want to automate.

The idea is to mimic the actions a real user would perform to achieve a certain task or navigate through a particular flow in your application. The code generated by Playwright will reflect these interactions, creating a baseline script.

I ❤️ how the codegen feature significantly simplifies the initial setup of a test, especially for those who are new to writing test scripts (moi!). I don't have to write code from scratch and I can quickly get started. But of course, as I shared above, the auto-generated code has to be refined and expanded upon to create comprehensive automated tests. For that, don't forget to make use of the documentation!

So, what are you waiting for? Start playing! 🎭

Coming up: testing for accessibility!

Note: My site is still in construction, so expect to find UI and accessibility bugs/errors beyond those tested here.

Resources

Debbie O’Brien’s Playwright Series on dev.to

Playwright Documentation

Image credit: Photo by Alex Kondratiev

Description: The image shows a hand pouring a blue liquid from a glass test tube into a flask with red liquid, and another hand pouring a green liquid into the flask. The background is plain white.

My First Playwright Tests

Corina: Web for Everyone — Fri, 17 Nov 2023 14:18:54 +0000

A blog series about playing and writing in 🎭

I'm a developer learning about web accessibility, and I would like to add Playwright to my toolset for testing web accessibility compliance.

So far, I've found that it offers straightforward syntax and excellent automation capabilities. Plus, the best documentation in the universe. (Yes, I believe aliens would use Playwright for some of their testing needs!)

This post is about the first three tests I wrote and how I applied them to my portfolio site.

Getting Started with 🎭

First, to get started (i.e., installation, how to run tests, etc.), I highly recommend Debbie O’Brien’s series of articles published on dev.to. I've included the link below in the Resources section.

Once installed, Playwright comes with example tests to help you get started. I adapted some of these examples to create three tests specifically for my portfolio site:

✔️ To navigate to the home page of my portfolio site and check if the title matches an expected string.
✔️ To check for the visibility of the home page’s heading.
✔️ To check whether the “My Projects” link is functional.

Note: My site is still in construction, so expect to find errors beyond those tested here.

Here are all three of the tests:

import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/');

    await expect(page).toHaveTitle(/Corina's Portfolio/);
});


test('has heading', async ({ page }) => {
    await page.goto('https://mywebsite.com/');

    await expect(page.getByRole('heading', {name: 'HELLO, I’m CORINA!'})).toBeVisible();
});


test('My Projects link', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/');

    await page.getByRole('link', {name: 'My Projects'}).click();
});

Understanding the Code for Test 1

Let's break the code down into smaller steps and analyze them!

Step 1: We have to import two functions from Playwright: test and expect:

import { test, expect } from '@playwright/test';

the test function is used to define an individual test.
expect is an assertion function that checks whether a certain condition is met.

Heads up: the term assertion frequently appears in Playwright. An assertion is a check within a test that verifies whether certain conditions are met. So it basically evaluates a specific condition and passes or fails the test based on the result.

Step 2: Define a test named has title

test('has title', async ({ page }) => {

Step 3: Navigate to my website

 await page.goto('https://corinamurg.netlify.app/');

Step 4: Add an assertion to check if the webpage's title contains the text "Corina's Portfolio"

await expect(page).toHaveTitle(/Corina's Portfolio/);

A few important notes

the test function requires a string as its first argument to name the test, and a function as its second argument. This function is where you write the actual test code. It’s an asynchronous function that receives a page object.
a test interacts with web pages through this page object, which is an instance of the Page class. The Page class provides a wide range of methods that allows us to simulate any possible user interactions and scenario. For example, use .goto() to navigate to URLs, page.click() or page.fill() to interact with elements, page.locator() to query the DOM. I highly recommend checking out the documentation on the Page class and its methods.
await is necessary because Playwright operates asynchronously. It performs actions in a browser environment that requires waiting for the actions to complete before moving to the next step.

Now let’s look briefly at the other two tests as well.

Test 2

// Define a test named 'has heading' 
test('has heading', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/')
    // Expect page to have a heading with name of 'HELLO, I’m CORINA!'
    await expect(page.getByRole('heading', { name: 'HELLO, I’m CORINA!' })).toBeVisible();
});

Test 3

// Define a test named 'My Projects link'
test('My Projects link', async ({ page }) => {
    await page.goto('https://corinamurg.netlify.app/')

    // simulate a user clicking on the 'My Projects' link
    await page.getByRole('link', { name: 'My Projects' }).click();
});

Playing with Errors

As an experiment, I modified the has title test with a different expected title, which, as anticipated, led to a failed test due to the mismatch.

Here is the (quite long) error log:

Error: Timed out 5000ms waiting for expect(locator).toHaveTitle(expected) 
Locator: locator(':root') 
Expected pattern: /My site/ 
Received string: "Corina's Portfolio" 
Call log: - expect.toHaveTitle with timeout 5000ms 
- waiting for locator(':root') 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio" 
- locator resolved to <html lang="en">…</html> 
- unexpected value "Corina's Portfolio"

The expect function was waiting for the page title to match "My site", but instead found "Corina's Portfolio". This mismatch between expected and actual results caused the test to fail.

The repeated lines like -unexpected value 'Corina's Portfolio' and -locator resolved to <html lang='en'>…</html> show that Playwright was continually checking the page title within the specified timeout period (5000ms). Each line likely represents an attempt to recheck the title against the expected value. Of course, it consistently found a value that did not match the expected pattern.

Conclusion 😊

I'm thrilled that my first three tests were successful! To create these tests I adapted the example tests that Playwright adds at installation. In the next post I will talk about another test that I created with just a click of a button! Seriously!

Resources

Debbie O’Brien’s Playwright Series on dev.to

Playwright Documentation

Image credit: Photo by Alex Kondratiev

Description: The image shows a hand pouring a blue liquid from a glass test tube into a flask with red liquid, and another hand pouring a green liquid into the flask. The background is plain white.

HTML: Buttons vs. Links

Corina: Web for Everyone — Wed, 15 Nov 2023 04:04:11 +0000

Using Buttons and Links with Accessibility in Mind

Buttons and links are fundamental elements in web design, but each has a distinct semantic meaning and accessibility implications.

Let’s learn how to use them!

Buttons

Purpose: Use them for actions!
They are intended to trigger an event when you click on them. Examples include submitting a form, opening a modal window, or any other action that does not navigate to a new page or resource.

Be Accessibility-focused: Create them with the <button> tag!

Buttons created with this tag come with important benefits:

assistive technologies like screen readers interpret them as interactive controls;
they are focusable by default, which means they are accessible through keyboard navigation;
they can be activated with the Enter or Space key.

All these features are important for users who do not use a mouse and/or rely on assistive technologies, and they come for free just because you use the <button> tag!

Name Your Buttons!
When screen reader users navigate to a button they need to hear its name in order to understand its purpose.

What should you do?

use descriptive text that clearly describe the action it will perform. For instance, "Search Flight Deals" is more informative than just "Search."
avoid using the same text for multiple buttons on the same page unless they perform the same action. Unique and specific text for each button helps users distinguish between different actions.

Styling Buttons: You can style them to look like almost anything! But make sure they are still recognizable as interactive elements.

Links (Anchors)

Purpose: Use them for navigation!
Their primary role is to take you from the current location to a new resource. This could be a different page, a different section of the same page, or an external website.

Be Accessibility-focused: Create them with the <a> HTML tag! You’ll also have to add an href attribute pointing to the destination URL or page anchor.

Screen readers announce links as such, and just like buttons, they are focusable by default and can be accessed through keyboard navigation. To activate a link, press the Enter key.

Label Your Links!
Just like buttons, links must have a name. Screen readers might announce links separately from their surrounding text, so make sure to use descriptive text.

Styling Links: You have many options to style them as long as they remain distinguishable from the surrounding text. Stick with the default style (underlined and colored differently from surrounding text) to help users identify them as actionable items.

What to Avoid

div or span elements as substitutes for buttons or links! Simply because they are not inherently accessible. If you (or your designer) insist on using them, then you must add the appropriate ARIA roles, tabindex, and keyboard event handling to make them accessible.

<div 
    role="button" 
    tabindex="0" 
    onclick="yourFunction();" 
    onkeydown="if(event.key === 'Enter') { yourFunction(); }"
    onkeyup="if(event.key === 'Space') { yourFunction(); }"
>
    Close
</div>

Really, why would you go down this road given all the extra work?!

Key Aspects To Remember

Your users have specific expectations when activating a link (e.g., the page will change) versus a button (e.g., some action will occur on the page). So use the correct element for the intended action: <button> for on-page actions, <a> for navigation.

Resources

Please visit Web for Everyone for a thorough introduction to accessibility.

HTML: Tag vs. Element

Corina: Web for Everyone — Sat, 11 Nov 2023 23:05:29 +0000

In a previous post, we looked at semantic vs. non-semantic HTML elements. Now, it’s common for web developers to use HTML element and HTML tag interchangeably. But are they really the same thing? Or is there more than meets the eye?

Let's decode this lingo!

HTML Tag

A tag is used to create an HTML element in source code. When we say tag we must refer to the opening <tagname> or closing </tagname> syntax used in HTML documents.

Tags come in pairs for most elements, with an opening tag marking the beginning of the element and a closing tag marking the end. However, some tags are self-closing, such as <img /> or <br />, which do not need a closing tag.

HTML Element

An HTML element is a DOM element. It refers to everything from the start tag to the end tag, including the tag itself, its attributes, and the content in between.

For example, an element can consist of:

the opening tag: <p>
the content: Hello, World!
the closing tag: </p>

So when you write <p>Hello, World!</p>, you're creating a paragraph element.

Elements can also be nested, meaning you can have elements within elements, and they can contain attributes that provide additional information about the element.

Example
Let's look at an example to illustrate the difference:



<a href="https://www.example.com">Visit Example.com</a>

The HTML Tags include:

the opening tag <a> (which also stores the element's attribute href with its corresponding value).
the closing tag </a>.

The HTML Element is the entire line of code, including

the opening tag <a>,
the attribute href="https://www.example.com",
the content Visit Example.com, and
the closing tag </a>.

Conclusion

In HTML, the terms "element" and "tag" are related but have distinct meanings:

a tag is a part of an element that defines the element's type and boundaries
an element includes the tags, attributes, and content.

. Above each part, labels indicate "Opening tag", "An attribute and its value", "Enclosed text content", and "Closing tag""/>
Source: MDN (see link below)

Resources

MDN Definition of an HTML element

MDN Definition of an HTML Tag

Use Semantic HTML!

Corina: Web for Everyone — Sat, 11 Nov 2023 22:40:47 +0000

In most conversations about accessibility, the use of semantic HTML is most likely to be the first and most common piece of advice you will receive. Let's understand why!

Semantic HTML

These are elements whose names convey information about their content, and sometimes about the role they have on a page. For example, if I see <nav> in a codebase I understand that to be a container for navigation elements.

Using semantic HTML elements is important for accessibility because of the extra power these elements have: they can provide information about their purpose, and assistive technologies transfer this information to their users.

Here are a couple of examples:

an <a> tag creates a link that can lead to a new page or a different section on the same page.
in order to get a quick understanding of a page's content and structure a screen reader user can press the "h" key and navigate through all the headings - created with tags <h1> through <h6> - because headings are used to define the main sections on a given page.

It's not an overstatement to note that using semantic HTML elements (using them correctly, of course!) allows assistive tech users to navigate the web with ease.

Non-Semantic HTML

Non-semantic elements are those that do not convey any particular meaning about their content to browsers or assistive technologies. They are typically containers used for styling purposes or for layout.

The <div> and <span> are examples of non-semantic elements. They tell nothing about their purpose on the page and are generally used to apply CSS styling.

A Few Semantic Examples

<header>
This element typically contains a group of navigation links and introductory content. Assistive technologies use it to identify the main heading and navigation area of a page, allowing users to easily orient themselves on your site.

<nav>
This element contains links to other pages or to parts within the page. When a screen reader encounters this element, it announces to the user that this section of the page is for navigation.

<main>
It refers to the main content of the page, distinct from content like sidebars, navigation links, and footers. Marking your important content with this tag allows user of assistive technologies to skip directly to the main content, bypassing headers and navigation links for a more streamlined browsing experience.

<article>
Use this for independent, self-contained content that could be distributed outside of the webpage, like a forum post, a magazine or newspaper article, or a blog entry. Assistive devices announce when they reach the end of an article, which can be very useful for users consuming a series of articles or posts.

<aside>
Use it to mark content that is tangentially related to the main content on the page. One approach would be to make it a sidebar. Assistive technologies will announce this content as additional information, allowing users to distinguish between primary content and side content.

Important to Remember

These semantic elements play a crucial role in accessibility. For users who rely on screen readers or other assistive devices, they present content in a more meaningful and navigable way.

A semantic element can be the deciding factor in whether or not some users are able to understand and interact with web pages!

Beyond Accessibility: The Wider Benefits of Semantic HTML

Semantic HTML isn't just about making websites more accessible. It also plays a vital role in making your content machine-readable, which has wide-ranging benefits:

SEO Advantages: Search engines love semantics! Semantic HTML helps them understand the structure and content of your website. By tagging your content correctly, you make sure that they can easily parse and index your site, focusing on the content you want them to see.

Maintainability and Scalability: For developers, semantic HTML means easier maintenance and scalability. It's like leaving a breadcrumb trail in your code, making it intuitive to understand, update, and extend.

Future-Proofing: As web standards evolve, having a semantically structured website ensures better compatibility with future browsers and tech. Think of it as an investment in your site's longevity.

Resources

W3 Schools Page on HTML Elements and Their Definitions

MDN Page on HTML Elements and Their Definitions

The World of Sparse Arrays in JavaScript

Corina: Web for Everyone — Fri, 10 Nov 2023 16:10:04 +0000

Me: The length of an array is determined by the number of its elements, right?

JavaScript: Hmm, not really . . .

Ah, JavaScript arrays! 😊

At first glance, they seem so simple, just a linear collection of items, right? But dig a little deeper, and you'll find some surprises. Call them just another nod to the sometimes perplexing nature of JavaScript.

In this post I will talk about:
✅ what determines the length of an array
✅ the difference between sparse and dense arrays
✅ how to work with sparse arrays

The Case of the Mysterious Array Length

Remember the first time you thought you'd mastered arrays? Same. I thought the array length was determined by the number of defined elements. But alas, JavaScript had other plans.

Sparse Arrays

Let's create an empty array:

let arr = []  ✅

Looks harmless, right? Now let's put an element at index 2:

arr[2] = 5  ✅

What do you think arr.length would be? If you said 1, join the club of the fooled!

console.log(arr.length) -> 3  😱

Yes, arr.length is 3, not 1!

In JavaScript, arr.length = highest index + 1 (plus 1 because we start indexing at 0).

It's true, this is not your everyday array. It's what we call a sparse array. And if you're wondering what a sparse array is, try logging the array to the console:

console.log(arr) -> [ <2 empty items>, 5 ]  🤔

You'll notice that there are two empty spots preceding the value 5. These empty spots, called also holes, make the array sparse, as it contains gaps where no explicit values have been set.

Think of it like a parking lot where you decide to park your car in a spot marked #10. This implies that there are 9 other spots before it. Even if these preceding spots are empty, the parking lot is still considered to have a capacity of 10 spots.

JavaScript arrays operate on the same principle: marking a spot at index 2 means there are two other spots before it (at indices 0 and 1), making the array's length 3.

Dense Arrays

In contrast, you may be more accustomed to dense arrays, where every index corresponds to a value, even if it's set to undefined.

let dense = [ "dense", "arrays", "are", "boring"]  😉

In dense arrays, there are no gaps; each slot in the array is accounted for, whether it's holding a value or is explicitly undefined.

Sparse Array Meets map( )

A Surprise

So, you might wonder, what happens when you run the map() function on our sparse array?

const newArr = arr.map(x => x + 3)

console.log(newArr) -> [ <2 empty items>, 8 ]  😲

Expected to see NaN (ie "Not-a-Number")? So did I. But it turns out that map() just ignores the empty spots!

Think of a sparse array as a parking lot divided into two sections: free parking and paid parking. Free parking spaces are like the empty slots in our array. Our parking officer - the map() function - ignores them and walks right past them.

A Question

A fair question to ask: if the empty spots are ignored, why aren’t they just eliminated from the new array? Because after our parking officer finishes their rounds, the parking lot (our array) must remain the same size!

Similarly, JavaScript's map() method will always return a new array of the same length as the original. It doesn't eliminate empty spots; it keeps them as they are, ensuring that the length of the array remains consistent.

An Experiment

Now let's explicitly set the first element as undefined:

arr[0] = undefined
console.log(arr) -> [ undefined, <1 empty item>, 5 ]  ✅

const newArr = arr.map(x => x + 3)

console.log(newArr) -> [ NaN, <1 empty item>, 8 ]  😲

Notice how the first element of the new array is now NaN. Why?

When we use map() on an array in JavaScript, the function we provide as an argument is called on each index that has been assigned a value. We know it ignores the empty spots, but it does pay attention to every element with an assigned value. Even when that value is undefined!

So if we explicitly set an element to undefined, map() will indeed invoke the function on that element. In our specific example of arr.map(x => x + 3), the function is attempting to add 3 to undefined. In JavaScript, any arithmetic operation involving undefined will output NaN.

To exhaust our parking lot analogy: when an array element is explicitly set to undefined, it's like a metered but unoccupied spot in the paid parking section. Our parking officer (again, the map() function) walks by and makes note of it. In JavaScript terms, that means paying attention to that value and trying to work with it.

A Note

In the above example, we got lucky. JavaScript will automatically convert undefined to NaN when it tries to perform an arithmetic operation. The map() function will then continue to operate on the rest of the elements in the array.

It is different with strings. When map() encounters undefined and the function is trying to, let’s say, convert it to lowercase, you'll run into a TypeError because undefined is not a string and does not have a toLowerCase() method. The execution stops at that point.

const array = ['HELLO', 'WORLD', undefined]

const newArray = array.map(element => element.toLowerCase())  🚫
//TypeError: Cannot read properties of undefined

To ensure your code runs smoothly, it's essential to handle undefined values before calling any methods on them: filter them out before applying map() or use a try-catch block. And of course, do not purposefully declare your elements as undefined! We did it here in the name of learning. 😊

Sparse Array Meets filter()

Shouldn't we just filter out the empty spots as well? Of course! You can filter out empty spots by using the filter() method. Remember how map() ignores them? Well, the empty slots are being treated as undefined for the purpose of filtering!

Let’s take our updated array and apply filter() to it. The array has undefined at first index, followed by an empty spot, and value 5 at index 2.

console.log(newArr) -> [ undefined, <1 empty item>, 5 ]

const filteredNewArr = newArr.filter(x => x !== undefined);

console.log(filteredNewArr) -> [5]  ✅

Ok, but what if, theoretically, you only want to remove the holes but keep the undefined? You can do something like:

const filteredNewArr = newArr.filter((item, index) =>         
                            arr.hasOwnProperty(index));

console.log(filteredNewArr) -> [ undefined, 5 ]  ✅

In this example, hasOwnProperty() checks if the array has an actual value, including undefined, at each index. Therefore, it will return true for all indices where a value exists and false for holes.

To Recap

✔️ Not all array are dense. Some have holes and we call them sparse.

✔️ For the purpose of finding the length, we must count the holes as well.

✔️ The map() method ignores the holes, but it does not remove them.

✔️ We can remove the holes with the filter() method.

Are We Ready to Conclude?

Is a sparse array a thing in real-world applications? I don’t have an answer yet, and promise to update the post if and when I do. But then, even if the answer is a resounding no, it does not matter. It would not make these quirky facets of JavaScript arrays any less captivating to explore. Long live quirkiness!

Keep exploring! ⛵

Resources

JavaScript: The Definitive Guide
7th Edition, by David Flanagan
O'Reilly Media, 2020

Blog post originally published on August 1, 2023 on corinamurg.dev.

Credit: Photo by Krzysztof Kotkowicz on Unsplash

Immutability in React

Corina: Web for Everyone — Sat, 04 Nov 2023 17:30:23 +0000

JavaScript objects are mutable. BUT, React asks that we treat objects in state as immutable. Should we listen?

Let's dive into the world of React and unravel the following mystery: why updating state feels like we're constantly moving into a new home instead of just rearranging our old furniture. 🏠

In this post, we will focus on two things:

✅ What it means to use immutable objects in React

✅ How to safely update objects in state

To mutate or not to mutate, that is the question!

Updating state in React: an example

Whether a beginner or a more seasoned React developer, code like the one below is relatively easy to grasp.

function SingleDie() {

    // set up the state: die is an object, with one property
    const [die, setDie] = useState({
        value: Math.ceil(Math.random() * 6),
        color: "blue"
    });

    // Generate new value when rolled, then update state
    function goodRollDie() {
        const newValue = Math.ceil(Math.random() * 6);
        setDie(oldDie => ({ ...oldDie, 
                            value: newValue 
        }));
    }

    // JSX code that renders the component
    return (
        <div>
        <p>Value: {die.value}</p>
        <button onClick={rollDie}>Roll Die</button>
        </div>
    );
}

Here we have a component named SingleDie that represents a die which can be rolled to produce a random value between 1 and 6.

The state die is an object with two properties: value and color :

value: Gets a random number between 1 and 6
color: Set to the string "blue"

When the goodRollDie function is invoked a new random value between 1 and 6 is generated. The setDie function is called to update the die state with this new value. Here, it uses the current state (referred to as oldDie) to spread out all of its properties and only change the value property to the new random number. The color property remains unchanged.

The Bad, Bad Code 👎

For me, a React newbie, the updating-state-by-creating-a-new-object approach was puzzling in the beginning. Why not just change the properties of the existing die object and update state with the modified object?! 🤔

function badRollDie() {
    // update value with a newly generated one
    die.value = Math.ceil(Math.random() * 6);  

    // set the modified object as the state
    setDie(die); 
}

It turns out that this approach is problematic because it directly modifies the state, which goes against the principle of immutability in React.

Just a reminder: JavaScript/React objects ARE mutable. We CAN change their content. BUT, React wants us (ok, implores us!) that we treat objects that are already in state as read-only, “as if they were immutable.”

To further quote from the React documentation,

. . . without using the state setting function, React has no idea that the object has changed. So React does not do anything in response. It’s like trying to change the order after you’ve already eaten the meal. While mutating state can work in some cases, we don’t recommend it. You should treat the state value you have access to in a render as read-only.

In the (BAD) code example above, the badRollDie function is designed poorly because it directly modifies the value property of the existing die object. 🚫

Instead, as the goodRollDie function shows, and I’m quoting again from the React documentation, "when you want to update an object, you need to create a new one (or make a copy of an existing one), and then set the state to use that copy." ✔️

The GOOD CODE 👍

So what happens in the good code ? In the goodRollDie function, a new object is created using the spread operator when updating the die state. This technique ensures that the state is updated in an immutable way. ✔️

We generate a new value. Then, the spread operator creates a new object by copying all the properties of the oldDie object and overriding the value property with the newValue. This new object is used as the updated state to set the die using setDie. ✔️

function goodRollDie() {
  const newValue = Math.ceil(Math.random() * 6);

  // Copy the old fields &override the value property  
  setDie(oldDie => ({...oldDie, value: newValue}));
}

To summarize, a new object is created for the die to be updated. The ... die syntax, using the spread operator, ensures that the properties of the existing die are copied into a new object. Then, for the goodRollDie function, a new value is created, which will override the previous value in the NEW object. All is good with the world now! 😊

The BIG QUESTION

Why immutability? As mentioned above, immutable data structures allow React to quickly determine if changes have occurred, and that makes the re-rendering process more efficient.

It turns out it provides other benefits as well, such as easier debugging, simpler code maintenance, and compatibility with future React features. React team's reasoning behind these benefits is more thorough than my one-sentence attempt, even if esoteric at times for a React beginner. So for right now, I will just have to take their word for it and simply follow the rule! 😎

My hope is that, as I continue to work in React and my coding skills improve, by embracing immutability (of course!) I will develop a deeper understanding of its advantages and how it benefits my projects.

In the meantime, I will remember to REPLACE, and NOT mutate. ✔️

Resources

React Documentation on Updating Objects In State

Blog post originally published on July 24, 2023 on corinamurg.dev.

Credit: Photo by Simon Schwyter on Unsplash

The Recent at() Method in JavaScript

Corina: Web for Everyone — Fri, 03 Nov 2023 13:41:59 +0000

The Cool Way to Dial Elements in JavaScript 📞 😎

Python devs, hold the smirks! JavaScripters, rejoice! Our syntax is catching up, and coding just got a tiny bit easier!

A concise, elegant syntax has been introduced for accessing elements from the end of an array or string. Meet the .at() method! 🎉

Before we dive into some of the details, here’s a quick example:

let arr = [1, 2, 3, 4];

arr.at(-1) -> 4

This feature has long been requested by developers, as it can simplify coding and make the syntax more intuitive, similar to languages like Python. Initially, the proposed name was .item(), but due to web incompatibility issues and potential conflicts with existing properties and methods in different libraries, .at() seems to be a better alternative.

Let's explore it!

In a world without at() 😔

Before at(), accessing elements from the end of arrays or strings involved cumbersome syntax or performance drawbacks.

array.length
The prevalent method was arr[arr.length - N], where N is the Nth item from the end, and arr.length – N gives the index position to access the N-th element from the end.

Let's look at an example!

let arr = [10, 20, 30, 40, 50];

arr.length -> 5

To get the 2nd element from the end (40 in this case), we subtract 2 from 5 (the length of the array), so arr[arr.length - 2] is equivalent to arr[3] :

arr[arr.length - 2]  // Output: 40

Notice how this approach, while functional, requires using the name of the array twice. It then adds 7 more characters due to .length. It is also incompatible with anonymous values. If a function returns an array, we first have to store it in a temporary variable before we can grab one of its values. Too much effort for a developer in 2023!

slice()
While it is compatible with anonymous values, slice() is less optimal: it creates a temporary array that is immediately discarded after retrieving a given element.

let arr = [1, 2, 3, 4, 5];

arr.slice(-2)[0] -> 4

// happening behind the scene
// arr.slice(-2) -> [4, 5]

Notice how it also requires the use of the square brackets to access an element of the resultant array? Too much work!

Why not just use [ ]? 🤔

The [] syntax in JavaScript is a universal one, applicable to all objects, and not exclusive to arrays and strings. When we refer to a value using an index, such as arr[3], we are essentially referring to the property of the object with the key "3", a feature applicable to any object.

Using arr[-1] in the current JavaScript environment will not output an error. JavaScript will be looking for the property with the key "-1", and not for an index counting backward from the end. If it does not find it, the output will be undefined.

How does at() work? ⚙️

The .at() method takes an index as its parameter and returns the element in the array corresponding to the given index. This index is zero-based and is converted to an integer.

Let's start with an array:

let arr = [10, 20, 30, 40, 50];

and loop through every possible case!

✅ Given a positive index, at() behaves just like the square bracket notation:

arr[2] -> 30

arr.at(2) -> 30

In this case, the [] syntax is probably better, since it's shorter.

✅ An index equal to or greater than the array length is out of the range for the given array, and the method will return undefined:

arr.at(5) -> undefined

✅ Given a negative index, at() will count back from the end of the array:

arr.at(-2) -> 40

// index + array.length = -2 + 5 = 3

arr[3] -> 40

Notice how the accessed index will be equivalent to "index + array.length"!

✅ An index that is less than the negative value of the array length is also out of the range:

arr.at(-6) // Output: undefined

The method will not attempt to access any property, and it will return undefined.

All is GOOD with the world now! 😊

So, there we have it, the new .at() method, making array and string manipulation more intuitive and clean!

Now we can effortlessly dial in the index we want, be it from the start or the end, and JavaScript will connect us to our element without any fuss!

Who's laughing now, Python? 😜

References

MDN Documentation on the at() method

GitHub repository for the TC39 proposal to add the .at() method to the JavaScript language

Blog post originally published September 22, 2023 on corinamurg.dev.

Credit: Photo by Wesley Hilario on Unsplash

The Temporal Dead Zone

Corina: Web for Everyone — Thu, 02 Nov 2023 03:24:33 +0000

JavaScript's Restricted Realm for LET and CONST

The Temporal Dead Zone sounds like a sci-fi movie, doesn't it? But in the JavaScript universe, it's the space where a variable is off-limits, even though you might think it should be available. This behavior occurs with variables declared using let and const.

In this post we will answer the following questions:

What is the Temporal Dead Zone?
Where or when do we encounter it?
Why do we have it?

Before we dive any deeper though, let's review hoisting.

Hoisting: What is it again?!

In The Curious Case of JavaScript Hoisting we talked about how both variable and function declarations are moved - or hoisted - to the top of their containing scope during the compilation phase.

However, not all hoisting is created equal. While function declarations are hoisted with their definitions, allowing us to call them even before their code appears, variables show more nuances:

Variables declared with var are hoisted, but their initialization stays where it is. This means they'll exist (with an undefined value) from the beginning of their scope, but they won't get their assigned value until the code execution reaches the point of initialization.
In contrast, variables declared with let and const are also hoisted but they enter a 'Temporal Dead Zone'. They remain inaccessible until the point of initialization, and any attempt to access them prematurely will throw an error.

Let's look at an example!

A Variable Declaration with var

console.log(myCat) -> undefined

var myCat = "Petunia"

In the code above, the var myCat declaration is hoisted to the top of the scope, but its initialization with the value Petunia is not. This is why it returns undefined when we try to log it before actually defining it.

Now you might ask: what about let and const? Do they also get hoisted? Indeed, they do! JavaScript hoists all declarations, it's very uplifting in that manner. 😊

Yet, while hoisting applies to all three, let and const get special treatment - they get sent to the Temporal Dead Zone! 💀

The Temporal Dead Zone 🚫

The Temporal Dead Zone (TDZ) is JavaScript's no-access zone. When a let or const variable is hoisted, it enters the TDZ. From the start of the block until the line where the variable is declared, it's in the TDZ. Attempt to access it too soon, and JavaScript throws a ReferenceError.

console.log(myVar)   // Output: undefined
var myVar = 'red'    // myVar is now delcared
console.log(myVar)   // Output: 'red'

console.log(myLet)   // ReferenceError: myLet is not defined
let myLet = 'orange' // myLet is now declared
console.log(myLet)   // Output" 'orange'

Notice how myVar floats up like a helium balloon and is undefined before the line where it’s actually tied down. This behavior is because of how var declarations are hoisted. On the other hand, myLet does get hoisted but lounges in the TDZ until the let myLet = "orange" line runs.

Here's an example using const inside a block scope:

{  // start of the block scope

 console.log(cat)      // ReferenceError: cat is not defined
 const cat = "furry"   //  Ah, now cat is finally declared!
 console.log(cat)      // "furry"

}  // End of the block scope

In this example, the scope of cat is the entire block (the code within the { }). The TDZ for cat is the stretch of this block until right before the const cat = "furry" line. Once we pass that line of code, the cat is out of the TDZ ... and out of the bag, ready to be used (and cuddled).

Phew, I am finally in the clear! 😸

Finally: Why Does the TDZ Exist?

Understanding the TDZ is one thing, but you might wonder why such a concept exists in the first place.

The idea behind the TDZ is to help catch bugs in your code. Deciding between var, let, and const for variable declaration? The strict behavior of let and const in TDZ suggests that they are generally better choices for writing robust, debuggable code.

When you declare a variable using var, it gets hoisted and initialized with undefined. Using the variable before it's defined could lead to unexpected behavior, but you will not necessarily see an immediate error. Your code will not explicitly fail; it just operates unexpectedly.

Let's remember an example from a previous post:

var result = 2 * myVar // Output: NaN

var myVar = 7;

In this scenario, result will be NaN because myVar is undefined at the time of the multiplication, and any arithmetic operation involving undefined results in NaN. These types of bugs are subtle and can be tricky to debug as they don’t throw an error and might not become apparent until much later in the program’s execution.

On the other hand, let and const put the variable in the Temporal Dead Zone until it's declared and initialized. If you try to access the variable while it's in the TDZ, JavaScript throws a ReferenceError and the code execution stops; you learn about the potential problem immediately.

Takeaway

Oh, the intricacies of scope, hoisting, and the Temporal Dead Zone! Only in JavaScript, right? It pays to remember them in order to produce bug-resistant code. So, the next time you declare a variable, remember these quirks and choose wisely!

Happy Halloween month! 🎃 😸

Resources

JavaScript: The Definitive Guide
7th Edition, by David Flanagan
O'Reilly Media, 2020

Blog post: The Curious Case of JavaScript Hoisting

Blog post: Demystifying Function Declarations Within Conditional Blocks

Blog post originally published October 2, 2023 on corinamurg.dev.

The Curious Case of JavaScript Hoisting

Corina: Web for Everyone — Thu, 02 Nov 2023 03:07:46 +0000

Giving Code Elements a Head Start in the Race to Execution!

Ever played with a yo-yo? In JavaScript, variables and traditional function declarations act much like one: they start at the bottom but magically make their way to the top!

Welcome to the fascinating realm of hoisting where function and variable declarations are silently shifted to the top of their respective scopes during the compilation phase (so before execution begins). But here's the plot twist: for some of them, the initializations stay grounded! ⬇️ 😲

We will look at the nuanced ways JavaScript deals with hoisting and focus on:

function declarations,
variables declared with var, and
the somewhat mysterious behavior of let and const.

Time to elevate our understanding! 🚀

But before we dive any deeper, let's talk about scope.

What is Scope? 🏖️

Think of scope as your own private beach - only the variables declared there can have access and play!

In JavaScript, scopes can be:

✅ Block Scope: the region of code within a pair of curly braces { }.

Variables declared with let and const are block-scoped, meaning they can only be accessed within that block in which they are declared.

if (true) {
  let blockedCat = "It's cozy in here!";
  const blockedDog = "I am stuck in here!";
} 

// blockedCat and blockedDog are not accessible outside this block

✅ Function Scope: the region of code within a function definition.

Variables declared with var inside a function are function-scoped, meaning they are only accessible within that function.

// Here captured is not accessible outside this function

function selfishFunction() {
  var captured = "Get me out of here!";
}

✅ Module Scope: the entire module has its own scope if you're coding using ES6 modules.

This means that variables declared in a module are only accessible within that module unless they are explicitly exported.

✅ Global Scope: Variables declared outside of any function or block are globally scoped. These variables can be accessed and altered from any other scope in the program.

The Drama of Hoisting in JavaScript

Everyone is getting an early invite to the party but not everyone is being allowed to enter just yet!

In JavaScript, both function declarations and variable declarations are hoisted, but their behavior varies due to the JavaScript engine's parsing rules.

1. Function Declarations

Traditional function declarations - using the function keyword - enjoy VIP status; they are hoisted along with their definitions. This means you can call such a function BEFORE its code even appears, and it will execute flawlessly. 🍹 😎

Example:

hoistedFunction()
// Output: "This function has been hoisted."

function hoistedFunction() {
    console.log("This function has been hoisted.")
}

Thanks to hoisting, you can structure your code by placing the more important logic at the top and the helper functions at the bottom, even if those helper functions are used in the upper parts of your code.

Note: there are subtle nuances when these declarations appear inside conditional blocks. For a closer look at how different JavaScript environments handle function declarations inside conditional blocks, please refer to the Demystifying Function Declarations Within Conditional Blocks post in this series.

2. Variable Declarations Using `var`

Variables declared with var do get hoisted but without their initializations (where you assign a value to a variable). Should you access such a variable before its definition, you'll receive undefined.

console.log(myNumber) // Output: undefined

var myNumber = 5      // variable is now assigned a value

In the code above, the var myNumber declaration is hoisted to the top of the scope, but its initialization with the value 5 is not. This is why it returns undefined when we try to log it before actually defining it.

However, in the example above, we are fortunate: the console displays undefined, silently whispering to us that a variable is being accessed before its assignment.

What do you think happens when the uninitialized variable is part of a calculation or logical expression? Possible mayhem! Because it can lead to obscure and harder-to-detect issues.

Example:

var result = 2 * myVar // Output: NaN

var myVar = 7;

In this scenario, result will be NaN because myVar is undefined at the time of the multiplication, and any arithmetic operation involving undefined results in NaN. These types of subtle bugs can be especially tricky to debug as they don’t throw an error and might not become apparent until much later in the program’s execution.

3. Variable Declarations Using `let` or `const`

Variables declared with let or const exhibit unique scope behavior. Although technically hoisted, attempting to access them prematurely leads to a ReferenceError rather than undefined.

The ultimate effect on your code is crucial: encountering undefined will not interrupt code execution, but it may lead to logical errors or unexpected behavior. On the other hand, encountering a ReferenceError will stop execution.

We call this space from the start of the block until the line where the variable is actually declared the Temporal Dead Zone (TDZ). 🚫

Example:

{  // Start of the block scope

console.log(boo) 
// Output: ReferenceError: boo is not defined

let boo = "ghost"
// boo is declared

console.log(boo) 
// Output: "ghost"

}  // End of the block scope

In this example, the scope of boo is the entire block (the code within the { }). The TDZ for boo is the part of this block before the let boo = "ghost" line. Once we pass that line of code, boo is out of the TDZ and ready to be used.

Many developers prefer using let and const because a ReferenceError immediately alerts them to a scoping issue, halting the code and thus making it easier to debug. This behavior reduces the risk of logical errors that could arise when code execution continues with an undefined value, as is the case with var.

Note: For an in-depth look at the Temporal Dead Zone, please check out the second post from this series. Link at the end of the post.

4. What about Function Expressions?

It's important to note that function expressions - defined with var, let, or const - fall into this category as well.

Example:

console.log(myFunc)  
// Output: ReferenceError: myFunc is not defined

const myFunc = function() {
    console.log("myFunc is hoisted.")
}

Unlike traditional function declarations, function expressions do not enjoy VIP hoisting privileges, as the example above illustrates. Just the dread of the TDZ!

Hoisting in Other Languages

While the notion of scope and lifetime of variables exists in virtually all programming languages, can we say the same thing about hoisting? Not at all! The concept of hoisting as it exists in JavaScript is not very common in other programming languages.

Most languages do not need a crane operator because they have a more straightforward scope and declaration system, where the order in which variables and functions are declared matters explicitly.

Languages like C, C++, Java, and Python do not hoist variables and functions in the way JavaScript does. In these languages, trying to access a variable before it has been declared usually results in a compile-time or run-time error. Therefore, developers have to be more deliberate about the order in which they declare and use variables and functions.

Conclusion

In JavaScript, hoisting behavior allows for more flexibility (and sometimes more confusion) in how you can order your code. When choosing how to define a function and what types of variables to use, remember the mechanics of hoisting!

But, the story continues! Two related posts:

The Temporal Dead Zone

Demystifying Function Declarations Within Conditional Blocks

Resources

JavaScript: The Definitive Guide
7th Edition, by David Flanagan
O'Reilly Media, 2020

Post originally published August 26, 2023 on corinamurg.dev

Credit: Photo by Gunnar Ridderström on Unsplash

DEV Community: Corina: Web for Everyone

Testing for SC 2.5.3 Label in Name with Playwright

What is Success Criterion 2.5.3?

Testing conformance with 2.5.3

First approach: collect all elements with aria-label

Why this first approach is far from perfect

Second approach: manually select all target elements

Why the second approach in not perfect

Testing for Accessibility with Playwright

Testing for WCAG A Compliance

Unexpected Results with WCAG AA

Troubleshooting the Color Contrast Issue

Looking for Help from the WebAIM’s Contrast Checker

Will AAA Fail Too?!

Back to the WCAG AA failed test …

Update

Coming Up

Resources

Using Codegen

Steps to Get Started with Codegen

My Codegen Session

Checking a Link to an External Page

Checking the Link to an Internal Page

Conclusion

Resources

My First Playwright Tests

Getting Started with 🎭

Understanding the Code for Test 1

Test 2

Test 3

Playing with Errors

Conclusion 😊

Resources

HTML: Buttons vs. Links

Buttons

Links (Anchors)

What to Avoid

Key Aspects To Remember

Resources

HTML: Tag vs. Element

HTML Tag

HTML Element

Conclusion

Resources

Use Semantic HTML!

Semantic HTML

Non-Semantic HTML

A Few Semantic Examples

Important to Remember

Beyond Accessibility: The Wider Benefits of Semantic HTML

Resources

The World of Sparse Arrays in JavaScript

The Case of the Mysterious Array Length

Sparse Arrays

Dense Arrays

Sparse Array Meets map( )

Sparse Array Meets filter()

To Recap

Are We Ready to Conclude?

Resources

Immutability in React

Updating state in React: an example

The Bad, Bad Code 👎

The GOOD CODE 👍

The BIG QUESTION

Resources

The Recent at() Method in JavaScript

In a world without at() 😔

Why not just use [ ]? 🤔

How does at() work? ⚙️

All is GOOD with the world now! 😊

References

The Temporal Dead Zone

Hoisting: What is it again?!

A Variable Declaration with var

The Temporal Dead Zone 🚫

Finally: Why Does the TDZ Exist?

Takeaway

Resources

The Curious Case of JavaScript Hoisting

First approach: collect all elements with `aria-label`

2. Variable Declarations Using `var`

3. Variable Declarations Using `let` or `const`