DEV Community: Todd Libby

Names Are Hard But They Don't Have To Be

Todd Libby — Thu, 22 Jan 2026 00:00:00 +0000

The $10,000 Bug

In 2015, a major airline's booking system rejected a passenger's name because it contained an apostrophe. The passenger—who had flown with them dozens of times before—missed their flight. The airline had to refund the ticket and compensate for the inconvenience. Total cost: over $10,000.

The name? O'Brien.

One of the most common Irish surnames in the world, rejected by a validation rule that probably took someone five seconds to write.

This isn't an isolated incident. Every day, millions of people around the world encounter forms that reject their names, corrupt their characters, or force them into boxes that don't fit their cultural identity. It's frustrating for users, expensive for companies, and completely avoidable.

Take for instance this article

where a woman was denied a hotel room for having an apostrophe in her name! This is the kind of laziness that I find more than off-putting.

So I'm going to show you how to build forms that respect the diversity of human names while maintaining security and data integrity. Because names—something we think is simple—are actually one of the hardest problems in software development. Even harder, is the fact that most devs cannot be bothered to learn and implement these inclusive patterns.

Why This Matters

Before we dive into the technical details, let's establish why getting names right is so critical:

The Scale: There are over 7 billion people on Earth, speaking thousands of languages, writing in hundreds of scripts, and following countless cultural naming conventions. Your form isn't just for people like you—it's potentially for everyone.

First Impressions: Your form is often the first real interaction someone has with your product. When that form rejects their name, you're not just creating a technical error—you're telling them "this product wasn't built for people like you."

Business Impact: Failed form submissions mean:

Lost customers and revenue
Increased support tickets and costs
Damaged brand reputation
Potential legal issues (discrimination claims)
Inaccessible services for entire populations

It's Solvable: The good news is that handling names correctly isn't actually that hard once you understand the requirements. The bad news is that most developers have absorbed incorrect assumptions about how names work and don't want to put the work into it whether it be learning regex patterns or just plain laziness.

Real Examples

Let me show you some real examples I've seen and talked to people about (company names redacted to protect the guilty):

Example 1: The Length Validator

A major social media platform rejected the name "José" because it required a minimum of 4 characters. José is one of the most common Spanish names in the world, used by over 6 million people in the United States alone. It is a 4-letter word. So what the hell is going on? A dev couldn't be bothered to get out of their own little bubble to make this work and a manager was too busy with paperwork and meetings to actually check and see what was going on. Peer reviews didn't happen because everyone had their heads down and faces in a keyboard. No accountability.

Example 2: The Diacritic Stripper

An online retailer automatically stripped accent marks from names, turning "Müller" into "Muller" and "François" into "Francois." When customers received packages addressed to "Muller" instead of their actual name, delivery drivers couldn't find them in apartment directories. Again, a fundamental breakdown in systems, checks and balances, and accountability for devs who could not be bothered to take into consideration names and their origins.

Example 3: The Character Set Disaster

A banking application using an outdated database encoding turned Chinese names into question marks. Users named 张伟 (Zhang Wei, one of the most common Chinese names) saw their bank statements addressed to "???." So why the absolute failure by financial institutions? Because someone couldn't be bothered to fix it or even find out if it needed fixing. (It needed to be fixed).

Example 4: The Punctuation Police

A government service portal rejected names containing apostrophes or hyphens, making it impossible for people named D'Angelo, Mary-Kate, or Jean-Luc to use the service. The error message? "Special characters are not allowed." Because a dev just did not know how to do something. Plain and simple. Instead of making it work and educating themselves, they took the easy way out and closed the door on many people. Great attitude to have in a government job, and par for the course apparently.

Example 5: The Western Format Enforcer

An HR system required separate "first name" and "last name" fields with no way to leave either blank. This made the system completely unusable for:

Indonesian users (many have single names like Sukarno)
Icelandic users (who use patronymics, not surnames)
Chinese users (whose family name comes first)
Anyone else who doesn't follow Western naming conventions

These aren't edge cases. Combined, these examples affect billions of people.

"Well! People always have two names, right?" No Kevin, no they do not. Head in the sand syndrome is a horrible affliction.

So yes, I am being critical. Very critical because this still goes on to this day. Just this morning I read a post on Bluesky about this very topic, so I had to write this. Because as long as the Web has (questionably) existed, this has been going on because devs are lazy (especially with the advent of AI, LLM's and 'vibe coding'). Do better. Here's how!

Understanding Names Globally

To build better forms, we first need to understand how names actually work around the world. Let's bust some myths. (Puts his Mythbusters shirt on).

Myth 1: Everyone Has a First Name and Last Name

Reality: Naming conventions vary wildly across cultures.

Indonesian Names: Many Indonesians have a single name with no family name. Famous examples include Sukarno and Suharto, former presidents of Indonesia. When forced to fill out forms with separate first/last name fields, they often have to make something up or repeat their name in both fields.

Icelandic Patronymics: Icelanders don't use family names. Instead, they use patronymics—a given name plus their father's (or sometimes mother's) name with "son" or "dóttir" added. The singer Björk's full name is Björk Guðmundsdóttir, meaning "Björk, daughter of Guðmundur." If she had a son, he might be named "Jón Björksson"—note that the family doesn't share a surname.

Chinese Naming Convention: In Chinese culture, the family name comes first, followed by the given name. Zhang Wei means Family Name: Zhang, Given Name: Wei. Many Chinese people adopt a Western order when dealing with international contexts, but this can create confusion and inconsistency.

Spanish Naming: In Spanish-speaking cultures, people typically have two surnames—one from each parent. María García López has García from her father and López from her mother. When she marries, she might add her husband's surname, becoming María García López de Martínez.

Burmese Names: People from Myanmar typically have no family name at all and use a system where names indicate generation and personal identity.

Myth 2: Names Fit in ASCII

ASCII contains 128 characters, including uppercase and lowercase English letters. That's it. No accents, no umlauts, no characters from non-Latin scripts.

Here are names that don't fit in ASCII:

Vietnamese: Nguyễn (with tone marks)
Arabic: محمد (right-to-left script)
Chinese: 王 (logographic characters)
German: Müller (umlaut)
Hawaiian: Kealiʻi (ʻokina - the glottal stop)
French: François (cedilla)
Spanish: José (acute accent)
Polish: Łukasz (l with stroke)
Turkish: Çağlar (c with cedilla)
Czech: Dvořák (r with caron)

These aren't exotic edge cases—they're normal names used by hundreds of millions of people every single day. ADD THEM!

Myth 3: You Can Validate Names with Simple Rules

Names can be:

Very Short: The surname "O" is common in China and Korea. Single-letter names exist in many cultures.

Very Long: Wolfeschlegelsteinhausenbergerdorff is a real German surname. Thai names can easily exceed 20 characters. The longest personal name on record is 747 characters.

All Consonants: Ng is a Chinese surname. Try pronouncing that according to English rules.

Numbers: In some jurisdictions, people can legally change their name to include numbers. For example, Jennifer 8. Lee is a legally registered name.

Special Characters: Apostrophes (O'Brien), hyphens (Jean-Luc), spaces (von Braun), and periods (St. John) all appear in legitimate names.

Capitalization Rules: Names like "McDonald," "MacLeod," "von Neumann," and "de la Cruz" have internal capitalization that you can't predict with simple rules.

Myth 4: You Need to Split Names into Fields

This assumption causes immense problems because:

Many cultures don't have a clear first name/last name distinction
The meaning of "first" and "last" varies by culture
Some people have multiple middle names or no middle name
Asking people to incorrectly split their name is disrespectful
Even "how should we address you?" requires cultural context

The Icelandic phone book, for example, is sorted by first name because that's the most meaningful ordering in their culture.

So why are we still sticking with the same old song and dance pattern of firstname/lastname fields (especially in the US) when some people in the world may not have a qualifier as we talked about earlier? Especially if your company deals with international businesses and people (internationalization-i18n anyone?)

The Technical Solution

Now that we understand the problem (hopefully), let's look at how to solve it properly.

1. Input Validation: Be Permissive

The golden rule: If you're not sure whether to accept something, accept it. Your users know their own names better than your regex does. I cannot stress that enough. This isn't your form! Stop treating it as such! This brings me to my saying, "It works on my machine so it must be correct!" Nope. No it is not.

Here's what not to do:

<!-- Bad: ASCII only -->
<input
  type="text"
  name="name"
  pattern="[A-Za-z]+"
  title="Letters only"
>

This rejects billions of legitimate names.

Here's a much better inclusive and accessible pattern:

<!-- Good: Unicode-aware -->
<input
  type="text"
  name="name"
  pattern="[\p{L}\p{M}\s'-.]+$"
  maxlength="150"
  title="Please enter your name"
>

Let's break down that regex pattern:

\p{L} - Matches any Unicode letter from any language
\p{M} - Matches any Unicode mark (diacritics, accents, tone marks)
\s - Matches whitespace (spaces, which can appear in names)
'-. - Matches apostrophes, hyphens, and periods (common in names)
+ - One or more of the above
$ - End of string

Note: The \p{} syntax works in modern JavaScript regex with the u flag. For older browsers, you may need to be even more permissive or use a library.

Even this pattern might be too restrictive. A truly inclusive approach would be:

function isValidName(name) {
  const trimmed = name.trim();

  // Check for reasonable length
  if (trimmed.length < 1 || trimmed.length > 255) {
    return false;
  }

  // Block only dangerous characters:
  // - Control characters (0x00-0x1F, 0x7F)
  // - HTML/XML special chars that could enable injection
  if (/[\x00-\x1F\x7F<>]/.test(trimmed)) {
    return false;
  }

  // Everything else is allowed
  return true;
}

This approach blocks only characters that pose actual security risks while accepting virtually all legitimate names.

2. Database Design

Your database needs to support the full range of Unicode characters. (If it doesn't then maybe it is time it does.)

Bad:

CREATE TABLE users (
  name VARCHAR(50) CHARACTER SET latin1
);

This limits you to Western European characters and will corrupt or reject everything else. We are trying to get people to not do this.

Good:

CREATE TABLE users (
  name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
);

Important Notes:

utf8mb4 is the correct encoding for MySQL/MariaDB (the plain "utf8" in MySQL is actually a limited subset)
utf8mb4_unicode_ci provides case-insensitive collation for sorting
VARCHAR(255) gives generous space for names (adjust as needed for your use case)

For PostgreSQL:

CREATE TABLE users (
  name VARCHAR(255)
);

PostgreSQL uses UTF-8 by default, which is correct.

For MongoDB, JavaScript, and most modern systems, UTF-8 support is built-in, but always verify your configuration.

3. Form Field Design

The best approach is to use a single name field when possible:

<label for="full-name">Full name</label>
<input
  id="full-name"
  type="text"
  name="full_name"
  maxlength="150"
  autocomplete="name"
  required
>
<span class="help-text">Your name as it appears on official documents</span>

Benefits:

Works for all naming conventions
Doesn't force incorrect splitting
Respects how people identify themselves
Simpler for users
Easier to maintain

When you must split names (for example, government forms with legal requirements):

<fieldset>
  <legend>Your name</legend>

  <label for="given-name">Given name(s)</label>
  <input
    id="given-name"
    type="text"
    name="given_name"
    autocomplete="given-name"
  >

  <label for="family-name">Family name(s)</label>
  <input
    id="family-name"
    type="text"
    name="family_name"
    autocomplete="family-name"
  >

  <p class="help-text">
    If your name doesn't fit this format, enter your full name
    in the first field and leave the second field blank.
  </p>
</fieldset>

Notice:

Using "given name" and "family name" instead of "first" and "last"
Neither field is required
Clear help text explaining what to do if the format doesn't fit
Proper autocomplete attributes for browser assistance

4. The Preferred Name Pattern

For many applications, you can solve multiple problems at once by asking for both legal name and preferred name:

<fieldset>
  <legend>Your name</legend>

  <label for="legal-name">Legal name</label>
  <input
    id="legal-name"
    type="text"
    name="legal_name"
    autocomplete="name"
    required
  >
  <span class="help-text">As it appears on official documents</span>

  <label for="preferred-name">Preferred name (optional)</label>
  <input
    id="preferred-name"
    type="text"
    name="preferred_name"
  >
  <span class="help-text">What you'd like us to call you</span>
</fieldset>

This approach:

Accommodates legal requirements
Respects personal identity
Handles nicknames and chosen names
Works across cultures
Supports transgender users who may use a different name than their legal name
Allows for informal names or anglicized versions

5. Backend Validation

Your server-side validation should match your client-side approach:

function validateName(name) {
  // Don't do this!!!
  if (!/^[A-Za-z\s]+$/.test(name)) {
    return { valid: false, error: "Name can only contain letters" };
  }

  // Do this instead!
  const trimmed = name.trim();

  if (trimmed.length < 1) {
    return { valid: false, error: "Please enter your name" };
  }

  if (trimmed.length > 255) {
    return { valid: false, error: "Name is too long" };
  }

  // Block control characters and HTML/XML special chars
  if (/[\x00-\x1F\x7F<>]/.test(trimmed)) {
    return {
      valid: false,
      error: "Name contains invalid characters"
    };
  }

  return { valid: true };
}

Additional security considerations:

// Sanitize for display (prevent XSS)
function sanitizeForDisplay(name) {
  return name
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;');
}

// For SQL queries, use parameterized queries
// Never concatenate user input directly
const query = 'SELECT * FROM users WHERE name = ?';
db.query(query, [userName]);

6. Display and Formatting

Never automatically transform names:

// Bad: This breaks names like McDonald, von Neumann, de la Cruz
function formatName(name) {
  return name.toLowerCase()
    .split(' ')
    .map(word => word.charAt(0).toUpperCase() + word.slice(1))
    .join(' ');
}

// Good: Display exactly as entered
function displayName(name) {
  return name;
}

The only acceptable transformation is trimming leading/trailing whitespace.

7. Sorting and Searching

Sorting names across languages requires locale-aware collation:

const names = ['Müller', 'Möller', 'Mueller', 'Moeller', 'Zhao', 'Zhang'];

// Bad: ASCII sort gives unpredictable results for non-ASCII
names.sort();

// Good: Locale-aware sort
names.sort((a, b) => a.localeCompare(b, 'de-DE'));

For search, consider using full-text search with proper language analyzers:

// Use a library like ElasticSearch or PostgreSQL full-text search
// that understands Unicode and language-specific rules

// Example: PostgreSQL with unaccent extension
SELECT * FROM users
WHERE unaccent(name) ILIKE unaccent('%' || $1 || '%');

Testing Strategy

Testing names properly requires a comprehensive test suite with real-world examples.

Essential Test Cases

Your test suite should include:

const testNames = [
  // Basic Latin with punctuation
  "O'Brien",
  "Mary-Kate",
  "St. John",
  "von Neumann",
  "de la Cruz",

  // Accented Latin characters
  "José García",
  "François",
  "Müller",
  "Dvořák",
  "Łukasz",

  // Non-Latin scripts
  "张伟", // Chinese
  "محمد", // Arabic
  "Nguyễn", // Vietnamese
  "Παύλος", // Greek
  "Владимир", // Cyrillic
  "ธนา", // Thai

  // Special cases
  "Kealiʻi", // Hawaiian (ʻokina)
  "Sukarno", // Mononym
  "X Æ A-XII", // Unusual characters
  "O", // Single character

  // Edge cases
  "Jean-François D'Aubigny de La Tour", // Long with multiple hyphens
  "Maria García López de Martínez", // Spanish double surname
  "Nguyễn Tấn Dũng", // Vietnamese with tone marks
];

describe('Name validation', () => {
  testNames.forEach(name => {
    it(`should accept ${name}`, () => {
      expect(validateName(name).valid).toBe(true);
    });
  });

  it('should reject empty names', () => {
    expect(validateName('').valid).toBe(false);
  });

  it('should reject names with HTML', () => {
    expect(validateName('<script>alert("xss")</script>').valid).toBe(false);
  });
});

Manual Testing Checklist

Beyond automated tests, manually test your forms:

✓ Copy-paste names from different scripts
✓ Test with a screen reader
✓ Try names with various combinations of special characters
✓ Verify database storage and retrieval
✓ Check email generation and display
✓ Test PDF generation if applicable
✓ Verify sorting and searching work correctly

Real User Testing

The best way to catch issues is to test with people who have diverse names:

Recruit testers from different cultural backgrounds
Ask employees with non-ASCII names to test
Run a bug bounty specifically for name handling issues
Monitor support tickets for name-related problems

Common Questions and Edge Cases

"What about legal requirements?"

Some forms genuinely need to match government formats. In these cases:

Explain why you need the specific format
Provide clear instructions
Offer a way to contact support if their name doesn't fit
Consider storing both a legal name (in required format) and actual name (as they write it)

"How do I handle sorting?"

Use locale-aware collation in your database and localeCompare() in JavaScript. For international applications, let users choose their preferred locale for sorting.

"What about performance?"

Unicode-aware regex and collation are slightly slower than ASCII operations, but the difference is negligible in modern applications. Don't optimize prematurely—correctness matters more than nanoseconds.

"Should I use a name validation library?"

Most name validation libraries are too restrictive. If you use one, verify it:

Accepts all Unicode letters
Doesn't enforce Western name formats
Has been tested with diverse real names
Is actively maintained

Libraries like validator.js can help with basic sanitization, but their name validation often falls short.

"How do I handle display names vs. legal names?"

Use the preferred name pattern shown earlier. Store both and use the preferred name for all user-facing interactions, falling back to legal name only when legally required.

"What about email addresses?"

Email addresses have stricter rules defined by RFC 5321. The local part (before @) can contain letters, numbers, and certain special characters. Handle email validation separately from name validation.

"Should I allow emoji in names?"

Some jurisdictions now allow emoji in legal names. Unless you have a specific reason to block them, accept emoji. They're valid Unicode characters.

Accessibility Considerations

Handling names correctly intersects with web accessibility:

Proper Labels

<!-- Good: Explicit label association -->
<label for="name-input">Full name</label>
<input id="name-input" type="text" name="name">

<!-- Bad: No label or implicit association -->
<input type="text" name="name" placeholder="Enter name">

Error Messages

<label for="name">Full name</label>
<input
  id="name"
  type="text"
  name="name"
  aria-describedby="name-error"
  aria-invalid="true"
>
<span id="name-error" role="alert">
  Please enter your name
</span>

Help Text

Provide clear, visible help text for complex fields:

<label for="name">Legal name</label>
<input
  id="name"
  type="text"
  name="name"
  aria-describedby="name-help"
>
<span id="name-help" class="help-text">
  Enter your name exactly as it appears on your passport or ID
</span>

Implementation Roadmap

Ready to fix your forms? Here's a practical implementation plan:

Phase 1: Audit (1-2 days)

Find all name input fields in your application
Check database character set and collation
Review validation rules
Test with non-ASCII names
Document problems found

Phase 2: Database Migration (1-3 days)

-- Check current encoding
SHOW CREATE TABLE users;

-- Backup first!
mysqldump -u user -p database > backup.sql

-- Migrate to UTF-8
ALTER TABLE users
  MODIFY COLUMN name VARCHAR(255)
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

Phase 3: Validation Updates (2-5 days)

Update backend validation to accept Unicode
Update frontend validation patterns
Remove overly restrictive rules
Add comprehensive test cases
Update error messages

Phase 4: UI Improvements (2-3 days)

Consider consolidating split name fields
Add preferred name fields where appropriate
Update help text
Improve error messages
Test with screen readers

Phase 5: Monitoring (Ongoing)

Track validation failures
Review support tickets
Monitor user feedback
Keep test suite updated with new cases

Resources and Further Reading

Essential Reading

Falsehoods Programmers Believe About Names by Patrick McKenzie

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

A must-read list of 40+ incorrect assumptions about names.

Personal Names Around the World - W3C

https://www.w3.org/International/questions/qa-personal-names

Comprehensive guide to cultural naming conventions.

Unicode Character Database

https://unicode.org

The definitive source for Unicode character properties.

Tools and Libraries

Unicode Regular Expressions

Most modern languages support \p{} patterns for Unicode-aware regex.

ICU (International Components for Unicode)

Libraries for proper Unicode handling in various languages.

Database Documentation

MySQL UTF-8 Guide: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode.html
PostgreSQL Character Sets: https://www.postgresql.org/docs/current/multibyte.html

Testing Resources

Create a test file with diverse names:

// names-test-data.js
export const realWorldNames = [
  { name: "O'Brien", culture: "Irish", notes: "Apostrophe" },
  { name: "José García", culture: "Spanish", notes: "Accent marks" },
  { name: "张伟", culture: "Chinese", notes: "Chinese characters" },
  { name: "Nguyễn", culture: "Vietnamese", notes: "Tone marks" },
  { name: "Müller", culture: "German", notes: "Umlaut" },
  { name: "محمد", culture: "Arabic", notes: "Right-to-left script" },
  { name: "Kealiʻi", culture: "Hawaiian", notes: "ʻOkina" },
  { name: "Sukarno", culture: "Indonesian", notes: "Mononym" },
  // Add more as you encounter them
];

Responsibility And Where It Lies

So where does the responsibility lie when we come across all these examples of laziness, overlooking, and plain irresponsibility? Look no further than:

The Developer: Whether it is laziness, lack of knowledge or education, or the "Well, I am not allowed to make changes like that because..." take the Nike approach and Just Do It! The Sisyphus Effect, or the eternal struggle to make change and there is resistance above you is real, I get it. Make your case! If that doesn't work, throw it in there! I bet BRad has so many meetings and so much paperwork that he really won't ever notice. If so, then we cross that bridge when we get there. Trust me, you'll get the avalanche of crap raining down on you in the end.
The Manager: Oh yes. My favorite part. Managerial decision-making. Whether you have the best manager since sliced bread or you have the worst manager that can stumble backwards into horse shit and come out smelling like roses, this is on them! They oversee a group of devs, they should know what they are doing, but should and do are two entirely different things. The onus lies with the manager though.
The Designer: A small part in this play, but a part nonetheless. If they don't design for this pattern then they aren't practicing accessible design and are shutting out billions potentially. Everything starts from a design doesn't it? Then the designer is the root of the problem somewhat. The root of the problem lies next.
The Conception of the Project: You know that meeting you all have (I hope) where you all get together and plan out what you will do and draw out the roadmap with all the cool tools you use? THAT is where this all starts. Conception of project. It's not going to be accessible if you don't start practicing accessibility from the very start! "We can go back and..." Great, now you have wasted resources, time, money, and more. Just because you didn't take that first step. The most important one. Accessibility and inclusivity.

Summary

Handling names correctly is fundamentally about respect. Every time someone encounters a form that rejects their name, they're not thinking "this is a technical limitation." They're thinking "this company doesn't care about people like me." They feel left out. Not included. A sense of "this company doesn't want me." and they aren't wrong. You don't if you keep shutting people out for whatever reasons.

The technical solution isn't complicated:

Use UTF-8 everywhere
Accept Unicode letters and common punctuation
Store exactly what users enter
Don't enforce Western name formats
Test with diverse real names

But the impact is profound. Good name handling:

Makes your product accessible to billions more people
Reduces support costs and user frustration
Demonstrates respect for cultural diversity
Improves your brand reputation
Can be legally required in many jurisdictions

Start today. Pick one form in your application. Test it with the names in this article. Fix what's broken. Then move to the next form.

Your users will notice. They'll appreciate being treated as the whole, complete people they are—with names that belong to them, not to your validation rules.

Take Action

Audit your forms today using the test names provided in this article
Share this guide with your team
Update your validation to be more inclusive
Add diverse names to your test suite
Monitor and improve based on real user feedback

Every person deserves to have their name accepted, stored correctly, and displayed with respect. It's not an edge case. It's not a nice-to-have. It's a fundamental requirement for building inclusive software.

Get names right, and you're telling your users: you belong here.

Have you encountered name validation issues? Found a name that breaks systems? Share your stories with me on Bluesky.

Building a Production-Ready Nuxt Module From Idea to Published

Todd Libby — Sat, 17 Jan 2026 00:00:00 +0000

How I built @colabottles/center-div - a complete journey from problem to published package

The Impetus

My background allows me to pick up on programming pretty good these days, that said, I don't have an eidetic memory, I have a 40-plus year trove of what I call "space junk" floating around in my head, real life things to think about, but I understand the fundamentals and can understand and process by doing and reading. I figured this project is a great little thing to do. So I did it.

The Post I Saw

I was on my usual jaunt through Bluesky seeing if there was anything positive or interesting to read and laid eyes on this comment and the reply to it by Daniel Roe, lead maintainer with the Nuxt core team. I thought to myself, "This looks like a funny thing I can do, here is something I can challenge myself with." and thus I started doing the research.

The Problem Issue That Started It All

If you've built anything with Nuxt (or anything with anything really), you've probably written this code (or something similar) dozens of times:

<div style="display: grid; place-items: center; min-height: 25vh">
  <button>Perfectly Centered</button>
</div>

or a version of this in your preferred programming language.

It's such a common pattern—centering content on a page—yet we repeat the same CSS (Cascading Style Sheets) Grid boilerplate over and over. Worse, when you try to abstract it into a component, you often run into hydration mismatches that make your console light up with warnings.

I decided to try and solve this once and for all by building @colabottles/center-div, a simple Nuxt module for accessible, hydration-safe centering. Here's what I learned building and publishing a production-ready Nuxt module.

The Journey: From Idea to npm

Day 1: The Hydration Nightmare

My first attempt was straightforward—create a Vue component that applies centering styles:

<script setup>
const props = defineProps({
  minHeight: String
})
</script>

<template>
  <div
    :style="{
      display: 'grid',
      placeItems: 'center',
      minHeight: minHeight
    }"
  >
    <slot />
  </div>
</template>

Simple, right? Wrong. Hydration errors everywhere.

The problem: Vue was applying styles differently on the server versus the client, causing the dreaded:

Hydration completed but contains mismatches.

The Solution: Timing is Everything

After researching (and a lot of trial and error), I discovered the issue was about when styles get applied. The fix involved two key changes:

1. Use computed styles instead of reactive object spreads:

<script setup lang="ts">
import { computed } from 'vue'

const computedStyle = computed(() => {
  const baseStyle: Record<string, string> = { display: 'grid' }

  switch (props.axis) {
    case 'horizontal':
      baseStyle.justifyItems = 'center'
      break
    case 'vertical':
      baseStyle.alignItems = 'center'
      break
    default:
      baseStyle.placeItems = 'center'
  }

  if (props.minBlockSize) {
    baseStyle.minBlockSize = props.minBlockSize
  }

  return baseStyle
})
</script>

<template>
  <component :is="as" :style="computedStyle">
    <slot />
  </component>
</template>

2. For the directive, use beforeMount instead of mounted:

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.directive('center', {
    beforeMount(el: HTMLElement) {
      el.style.display = 'grid'
      el.style.placeItems = 'center'
      el.style.height = '100dvh'
      el.style.width = '100%'
    }
  })
})

Result: Zero hydration warnings. The component rendered identically on server and client.

Making It Accessible: WCAG (Web Content Accessibility Guidelines) 2.2 Compliance

Centering seems simple, but accessibility matters. I wanted this module to be usable by everyone, including users with disabilities. Here's what I focused on:

1. Preserving DOM (Document Object Model) Order

Many centering techniques use absolute positioning or flexbox in ways that change visual order without changing DOM order. This breaks screen readers.

My approach: Pure CSS Grid with place-items: center. No position manipulation, no reordering.

.nuxt-center-div {
  display: grid;
  place-items: center;
}

2. Usage of Logical Properties

Instead of min-height, I used min-block-size to respect writing modes and text direction:

<CenterDiv min-block-size="25vh">
  Content
</CenterDiv>

This works correctly for RTL (Right-to-Left) languages and vertical writing modes.

3. Never Manipulate ARIA (Accessible Rich Internet Applications)

The component doesn't add any ARIA attributes, change roles, or trap focus. It's purely presentational—exactly what a layout utility should be. The less the ARIA, the better I say.

4. Support Semantic HTML (HyperText Markup Language)

The as prop lets users choose the correct semantic element:

<!-- Default: <section> -->
<CenterDiv>Content</CenterDiv>

<!-- Use <main> for main content -->
<CenterDiv as="main">Content</CenterDiv>

<!-- Use <article> for articles -->
<CenterDiv as="article">Content</CenterDiv>

Let's face it, semantic HTML is an art form and one we don't see too often these days that are all about "build fast and break things". That is complete malarkey by the way. I'll explain more in a future blog post.

Standards met:

✅ WCAG 1.3.2 - Meaningful Sequence
✅ WCAG 1.4.10 - Reflow (supports 400% zoom)
✅ WCAG 2.4.3 - Focus Order

Testing: The Foundation of Confidence

I learned that tests aren't optional for published packages. Users depend on your code working correctly. Here's the testing stack I built:

Unit Tests (Vitest + Vue Test Utils)

import { describe, it, expect } from 'vitest'
import { mount } from '@vue/test-utils'
import CenterDiv from '../../src/runtime/components/CenterDiv.vue'

describe('CenterDiv', () => {
  it('renders with default props', () => {
    const wrapper = mount(CenterDiv, {
      slots: {
        default: '<button>Test</button>',
      },
    })

    expect(wrapper.find('section').exists()).toBe(true)
    expect(wrapper.find('button').text()).toBe('Test')
  })

  it('applies minBlockSize prop', () => {
    const wrapper = mount(CenterDiv, {
      props: { minBlockSize: '100vh' },
    })

    const el = wrapper.element as HTMLElement
    expect(el.style.minBlockSize).toBe('100vh')
  })
})

Coverage:

Component rendering
Props (axis, as, minBlockSize)
Style application
7 tests total

E2E Tests (Playwright)

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

test('component renders and centers content', async ({ page }) => {
  await page.goto('/')
  await page.waitForLoadState('networkidle')

  const centerDiv = page.locator('.nuxt-center-div').first()
  await expect(centerDiv).toBeVisible()

  const styles = await centerDiv.evaluate((el) => {
    const computed = window.getComputedStyle(el)
    return {
      display: computed.display,
      placeItems: computed.placeItems,
    }
  })

  expect(styles.display).toBe('grid')
  expect(styles.placeItems).toBe('center')
})

These tests verify the component works in actual browsers , not just in Node.

Accessibility Tests (vitest-axe)

import { axe } from 'vitest-axe'

it('has no accessibility violations', async () => {
  const wrapper = mount(CenterDiv, {
    slots: {
      default: '<button>Accessible Button</button>',
    },
  })

  const results = await axe(wrapper.element)
  expect(results.violations).toHaveLength(0)
})

This caught issues I might have missed, like missing ARIA labels or incorrect heading hierarchy.

Final count: 11 tests, 100% passing.

The Module Structure: Following Best Practices

The official Nuxt module template provides excellent scaffolding. Here's the structure I ended up with:

center-div-module/
├── src/
│ ├── module.ts # Module registration
│ └── runtime/
│ ├── components/
│ │ └── CenterDiv.vue # Component
│ ├── plugin.ts # Directive
│ └── types.ts # TypeScript definitions
├── playground/ # Local development
│ ├── app.vue
│ └── nuxt.config.ts
├── test/
│ ├── unit/
│ │ └── CenterDiv.test.ts
│ └── e2e/
│ └── CenterDiv.spec.ts
├── package.json
├── tsconfig.json
└── vitest.config.ts

Key Files Explained

src/module.ts - Registers the component and plugin:

import { defineNuxtModule, addComponent, addPlugin, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  meta: {
    name: 'center-div',
    configKey: 'centerDiv',
  },
  setup(_options, _nuxt) {
    const resolver = createResolver(import.meta.url)

    addComponent({
      name: 'CenterDiv',
      filePath: resolver.resolve('./runtime/components/CenterDiv.vue'),
    })

    addPlugin({
      src: resolver.resolve('./runtime/plugin'),
      mode: 'client',
    })
  },
})

playground/ - Critical for development. Run pnpm dev and you get a live Nuxt app with your module loaded. Instant feedback loop.

The Build Process: Getting Ready for npm (Node PAckage Manager)

Building the module involves several steps:

1. Module Builder

Nuxt provides nuxt-module-build which handles:

Bundling (ESM (ECMAScript Modules) + CommonJS)
TypeScript compilation
Type definitions generation

pnpm run prepack

This creates the dist/ folder:

dist/
├── module.mjs # ESM entry
├── module.cjs # CommonJS entry
├── module.d.ts # TypeScript definitions
└── runtime/
    ├── components/
    │ └── CenterDiv.vue
    └── plugin.js

2. Package Configuration

The package.json tells npm what to publish:

{
  "name": "@colabottles/center-div",
  "version": "0.1.2",
  "type": "module",
  "exports": {
    ".": {
      "types": "./dist/types.d.ts",
      "import": "./dist/module.mjs",
      "require": "./dist/module.cjs"
    }
  },
  "files": [
    "dist"
  ]
}

Only the dist/ folder gets published. This keeps the package size tiny (4.4 kB).

3. Publishing

npm publish --access public

The --access public flag is required for scoped packages (@username/package-name).

CI/CD: Automating Quality

GitHub Actions runs tests on every push:

name: ci
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 20
      - run: corepack enable
      - name: Install dependencies
        run: pnpm install
      - name: Prepare playground
        run: pnpm run dev:prepare
      - name: Test
        run: pnpm run test

This catches issues before they reach users.

Challenges I Faced (And How I Solved Them)

Challenge 1: TypeScript Configuration

Problem: Tests failed in CI because tsconfig.json extended .nuxt/tsconfig.json which doesn't exist until you run the dev server.

Solution: Create a standalone tsconfig.json that doesn't depend on generated files:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "types": ["node", "vitest"]
  },
  "include": ["src/ **/*", "test/** /*"]
}

Challenge 2: Vite Version Conflicts

Problem: Vitest and @vitejs/plugin-vue used different Vite versions, causing type errors.

Solution: Add a type assertion to ignore the incompatibility:

export default defineConfig({
  // @ts-expect-error - Vite version conflict
  plugins: [vue()],
  test: {
    environment: 'happy-dom',
  }
})

Challenge 3: ESLint Checking Generated Files

Problem: ESLint was throwing 2,825 errors from generated files in playwright-report/.

Solution: Add ignore patterns to eslint.config.mjs:

export default createConfigForNuxt({
  // ...
}).append({
  ignores: [
    ' **/dist/**',
    ' **/node_modules/**',
    ' **/.nuxt/**',
    ' **/playwright-report/**',
    ' **/test-results/**',
  ],
})

Real-World Usage

Once published, using the module is straightforward:

Installation

npm install @colabottles/center-div

Configuration

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@colabottles/center-div']
})

Component Usage

<template>
  <!-- Full viewport centering -->
  <CenterDiv min-block-size="100vh">
    <button>Click Me</button>
  </CenterDiv>

  <!-- Horizontal only -->
  <CenterDiv axis="horizontal" min-block-size="50vh">
    <nav>Navigation</nav>
  </CenterDiv>

  <!-- Custom semantic element -->
  <CenterDiv as="main">
    <h1>Main Content</h1>
  </CenterDiv>
</template>

Directive Usage

<template>
  <div v-center>
    Quick full-viewport centering
  </div>
</template>

What I Learned

1. Developer Experience Matters

Small details make a huge difference:

Clear prop names (minBlockSize vs minHeight)
TypeScript autocomplete
Helpful README with examples
Fast development server

2. Tests Give Confidence

Every test I wrote caught a real bug. The time invested in testing paid off immediately.

3. Accessibility Isn't Optional (Which I Already Knew)

Building accessible components from the start is easier than retrofitting them later. Using semantic HTML and CSS Grid made accessibility almost automatic.

4. The Nuxt Ecosystem is Excellent

The module template, build tools, and documentation made this process smooth. The Nuxt team has done incredible work.

5. Community Feedback is Essential

Reaching out to experienced developers provides invaluable perspective before launching.

Performance Metrics

The final package is tiny :

Package size: 4.4 kB (compressed)
Unpacked size: 10.3 kB
Files: 15

For comparison, that's smaller than a single medium-resolution image. Zero dependencies beyond Nuxt itself.

Future Improvements

Ideas for future versions:

Gap prop for spacing between centered items:
Animation support for smooth centering transitions
Max inline size for constraining width:
Nuxt DevTools integration to visualize all CenterDiv instances on a page

Try It Yourself

The module is live on npm:

npm install @colabottles/center-div

Links:

npm:
GitHub:
Documentation: See README on GitHub

Key Takeaways for Building Your Own Module

Start with the official template: npx nuxi init my-module -t module
Test from day one: Unit, E2E, and accessibility tests
Use the playground: Instant feedback beats blind development
Focus on DX: Clear APIs, good docs, TypeScript support
Make it accessible: Follow WCAG guidelines from the start
Keep it small: Every kilobyte matters
Automate everything: CI/CD catches issues early
Get feedback: Community review prevents bad patterns

Conclusion

Building a Nuxt module taught me more about Vue, TypeScript, testing, and accessibility than any tutorial could. The process of taking an idea from concept to published package—with real users able to npm install it—is incredibly rewarding.

If you have a common pattern in your Nuxt projects, consider extracting it into a module. The ecosystem benefits, and you'll learn a ton in the process.

What patterns do you find yourself repeating in Nuxt? Maybe your next module idea is already in your codebase.

Resources

The Architecture of Anxiety and Shame, Part Two

Todd Libby — Wed, 08 Oct 2025 00:00:00 +0000

Part Two, Deception vs. Bad Design or Bad user experience

Roach Motels

A roach motel is a deceptive pattern to which it is easy to sign up for a service or subscription, but extremely difficult to cancel. This pattern usually involves hiding or obscuring the cancellation option, requiring users to call customer services to cancel, and in turn, makes the process of cancelling overly complex and time-consuming. This pattern can cause users to give up trying to cancel, and continue paying for the service for a longer period that they do not necessarily want to pay for any longer.

These roach motels are not the kind you book that are not clean and are not great to stay in or the ones that trap those nasty little bugs that may crawl around a house or business but these are nonetheless just as gross. The roach motels that are laid out all over to trap users into and like the Eagles said:

You can check out any time you like, but you can never leave.

Here is a couple examples.

Fun huh?

The pattern with roach motels focuses in on wearing a user out. Making you so tired, exhausted, irritated, mad, angry so that you give up and just say to hell with it, that you are not going to unsubscribe because it is a pain in the ass. Period.

That pattern, to trap you, to make you think twice. To make you stop and say, "Is it worth the hassle?" That stopping cue is what these companies don't want you to access or find.

Roach motels rely on a blend of cognitive fatigue and emotional pressure. The more friction a user encounters, the more their mental resources drain. At a certain point, anxiety rises ("What if I mess something up?"), frustration spikes, and shame creeps in ("Why is this so hard? Is it just me?"). This emotional cocktail is exactly what the pattern relies on to keep you trapped.

Deceptive patterns like "roach motels" are not just annoyances — they’re part of a larger ecosystem of manipulative design that exploits cognitive fatigue, shame, and decision friction. These patterns weaponize user psychology in subtle ways, and the result is often emotional exhaustion, frustration, and a breakdown of trust in digital products.

Why These Patterns Work

Cognitive Fatigue: People give up when their executive function is depleted.
Decision Friction: Intentionally adding micro-obstacles increases abandonment.
Loss Aversion: "You’ll lose access to ___" prompts trigger anxiety.
Shame Activation: Feeling "irresponsible" or "incompetent" makes users hesitate to continue cancellation.

Forced Continuity

Forced continuity is the operational engine behind a roach motel. Once the user is trapped, continuity keeps them there — through auto-renewals, hidden opt-outs, or the removal of natural stopping points.

This goes hand in hand with the roach motel, as well as other deceptive patterns. Infinite scroll again, for example. That forced continuity when the stopping cue (in this case the "load more" prompt or button) and the developer/designer has you in the palm of their hand.

You are forced to continue the pattern you did not want to go down and find yourself exhausted, frustrated, angry, mad by the time you get to where you need to go but you have either given up and left or you have just said, "To hell with it" and you are done. Or you're so exhausted you don't remember what you were doing and you just give in and stay subscribed, or you keep scrolling, or you keep clicking, or you keep doing whatever it is you are doing.

Forced continuity is your captor. The roach motel is where you are being kept hostage.

The Stopping Cue

The stopping cue is that point in the interaction where you are stopped. Whether it is an infinite scroll that the developer or designer has taken away (I will get to that in another post soon) or a roach motel that wears you out so you stop. That's the cue we need to get rid of regarding these patterns.

Anti-pattern or deceptive pattern, that cue, needs to go if it is used for nefarious reasons and they usually are used just for that. From an interview with Aza Raskin, the inventor of infinite scroll;

"I regret that I didn’t think more about how this thing would be used," he told The Times. He compares the feature to a study in 2005 that gave users bowls of soups that constantly refilled via a tube underneath the bowl. Participants ate 70 per cent more soup than those with normal bowls and did not even notice.

"I know as a designer that by taking away the stopping cue, I can make you do what I want you to do," Mr Raskin, a former head of user design at the browser Mozilla, said.

Mr. Raskin went on to say; "I contributed to this and I have been complicit," he said. "This story that we had all been telling ourselves that we were making the world better with technology, that story has been undone, I can’t tell myself that story any more." He added: "This is a profound moment in our species. We are losing control of the tools we made."

Stopping cues are the natural pauses in an experience — the end of a page, the bottom of a list, the confirmation of a completed action. When designers remove these cues, the user’s brain loses its moment to reset. Infinite scroll, autoplay, and friction-filled cancellation flows all target this vulnerability.

Examples of Stopping Cues

Pagination

Example: A "Next page" button at the end of search results.
What it does: Forces a conscious choice: "Do I want to keep going?"
Removed version: Infinite scroll keeps feeding content endlessly, removing the reflection point.

End of an Article or Section

Example: Reaching the end of a blog post.
Stopping cue: A natural break — the reading task is complete.
Removed version: Auto-loading the next article, keeping users from feeling "finished."

A Confirm or Complete Button

Example: "Submit," "Finish," "Place order," "Cancel subscription."
Stopping cue: Allows users to finalize a mental task and move on.
Removed version: Breaking the action into multiple hidden steps without confirming completion.

Load More Button

Example: Social media pages showing a limited number of posts with a "Load more" option.
Stopping cue: Users take stock before loading more content.
Removed version: Infinite scroll (removes the deliberate choice to continue).

Checkout Review Screen

Example: A summary of your cart before payment.
Stopping cue: Encourages review, consideration, and intention.
Removed version: One-click purchasing that bypasses reflection and increases impulse behavior.

End-of-Video Playback

Example: A video ends and pauses.
Stopping cue: The user chooses whether to watch more.
Removed version: Auto-play automatically begins the next video, bypassing the decision point.

Session Timeout Prompts

Example: "Are you still watching?" / "Still browsing?"
Stopping cue: Signals a check-in moment and chance to disengage.
Removed version: Sites that never pause playback or activity, encouraging passive overuse.

Natural End of a Workflow

Example: Completing a form returns the user to a dashboard.
Stopping cue: Signals the task is complete.
Removed version: Forms that loop users into upsells, surveys, or optional extras that look mandatory.

Breaks Between Notifications

Example: A notification digest that comes once a day.
Stopping cue: Encourages controlled re-engagement.
Removed version: Real-time, continuous notifications that keep pulling users back.

Physical World Stopping Cues

These can help illustrate your point with a relatable analogy:
The last page of a book
The credits rolling at the end of a movie

The bottom of a bowl (Aza Raskin’s soup analogy)

When tech removes these cues, it removes the user’s natural ability to stop.

How to Avoid the Pitfalls

So how does a user avoid all this garbage? Because once you’re in a roach motel or caught in a forced continuity loop, it feels like the product has all the power and you have none. The good news is: you do have options. Designers may remove stopping cues, but you can reintroduce your own.

Recognize the pattern early

If a service made it extremely easy to sign up and suddenly very hard to leave, that’s not an accident. The moment you see emotional language ("You’re going to miss out!"), multi-step cancellation hoops, or links that keep getting smaller and smaller, you’re in a deceptive pattern. Awareness kills half of the manipulation right there.

Bypass the interface entirely

Most roach motels rely on you trying to find the exit inside their maze. Don’t. A quick search for "service name cancel subscription" often leads straight to the hidden cancellation page. Or cancel through your bank, your credit card, or your phone’s app store. These systems don’t care about the company’s friction, and they let you escape without the drama.

Use your own stopping cues

If the interface won’t give you a moment to pause, create one. Slow down. Step back. Remind yourself why you came to the page in the first place. Infinite scroll, autoplay, and buried cancellation flows all depend on you reacting instead of deciding. When you reintroduce intention, the pattern loses its leverage.

Set reminders before free trials end

Forced continuity preys on forgetfulness. A calendar reminder set at the moment you sign up replaces the stopping cue the product intentionally removed. Don’t give them the luxury of you forgetting.

Use virtual or single-use cards

Some banks and privacy tools allow temporary or merchant-locked card numbers. If the company makes it difficult—or impossible—to cancel, you can simply cut off the payment source. They can’t force continuity if they can’t charge you.

Check your rights

In many regions, companies are legally required to provide a simple cancellation mechanism. Sometimes it’s buried in the footer under "Legal" or "Your Rights." It may not be prominent, but it exists—because it has to.

Contact support as a last resort

Support agents often have access to a straightforward cancellation tool the UI deliberately hides. A quick chat or email can end what the design tries to drag out.

At the end of the day, avoiding these traps is about reclaiming control—your time, your attention, and your autonomy. If the design won’t respect those things, you have to put the stopping cues back in yourself.

These traps work because they hijack executive function, shame, and emotional energy. The best way to escape them is to step outside the interface — cognitively or literally — and reclaim your control. When you reintroduce your own stopping cues, the manipulation loses its leverage.

For users with anxiety, ADHD, or executive function challenges, these patterns aren’t just annoying — they’re debilitating. What might be a minor irritation for a designer becomes a source of spiraling frustration or shame for someone already struggling with emotional regulation.

When systems are designed to trap us, the emotional cost is real. Anxiety spikes as we try to fight the interface, and shame sets in when we feel like the failure is ours rather than the design’s. Recognizing these patterns is the first step in resisting them — and the first step toward designing something better.

The Architecture of Anxiety and Shame, Part One

Todd Libby — Tue, 07 Oct 2025 00:00:00 +0000

Part One, The Scarcity and Pressure to Make Decisions and Placing Guilt in the Users Lap

Humanity and the Choices People Make

In the work and research I have done for a number of years now, I have found that the choices we make as developers, technologists, organizations and companies, founders and CEOs has come down to compromising humanity. There are very few instances I have found where the lines are drawn in the sand and never crossed by anyone I just mentioned, which is why the work I have done to bring perhaps a little bit of change to the WCAG (Web Content Accessibility Guidelines) 3 document (which is still in development and not a standard, please refer to WCAG 2.2 or 2.1) that we can mitigate some of the damage that has been done in the decades of grift and deceit that have been laid over the foundation of the Web as we know it.

“In the name of growth and profit!” is the steady battle cry that is silently shouted as the battle horns are sounded from the tops of the towers that CEOs and companies use as a bastion of corporate greed and capitalism and whatever methods they need to employ and deploy, they will certainly get all their workers that fall into line, they will do that for their fearless leaders who strut their stuff once, maybe twice a year on a stage with a big theatrical show for all to see.

Lost is the humanity I can see clearly. How that kid that just wanted to code, grew up to want to take over the world and throw away any kind of humanity though, that is the part that baffles me. Where does that get lost and at what point does something inside a person's head just snap and say, 'Let's do evil things today!'? As I try to answer those questions I have, I also look to help others that are the targets of these deceptive practices now so that they do not fall prey to the silent hunter that is literally stalking them.

I wanted to go over four patterns, four of many patterns, that are used to play with people psychologically, that draw out the anxiety and fear, the guilt and shame, and how these patterns are used and what we can do to combat them.

The Three Amigos

Timed-based urgency/Fake urgency/Confirmshaming

The exploitation of FOMO (Fear of Missing Out) and social comparison is used a lot. Literally everywhere in a digital space where there is some kind of revenue involved. Social anxiety is something that is used to pressure people into action. Many deceptive patterns come in pairs. Some, come in groups, like The Outsiders (a great movie and book by the way).

Fake scarcity (FOMO), time pressure (anxiety), and confirmshaming (guilt/social inadequacy) are used to target the social fears that are very real that affect 1 in 10 Americans. The economic and emotional/psychological cost is massive and any design that amplifies that anxiety for-profit isn't bad business. It is an ethical attack on the public's well-being. Businesses that use these patterns should never have business and people should never deal with companies that use these patterns for-profit against them.

The Data and Key Points

The condition of social anxiety isn't just a rare shyness, it is actually the third largest mental health care problem globally according to the Social Anxiety Association.

According to sources from the National Institute of Mental Health, Yale Medicine, Mental Health America, and the American Psychological Association, 12.1% of adults experience Social Anxiety Disorder (SAD) at some point in their lives. An estimated 7.1% of adults in the U.S. had SAD in the past year, which is approximately 15 million people. Of those adults with SAD in the past year, 29.9% of those people had serious impairment, and 38.8% had moderate impairment in their lives. The onset of SAD typically begins during childhood or teenage years with the median age being 13 years old.

The impact on function, work, and education can limit a person's participation in society, which is exactly where deceptive patterns in consumer tech can inflict the most damage. For instance individuals with SAD are over two times more likely to be unemployed than those without the disorder. Approximately 20% os people with SAD reported declining a job offer or promotion due to social fears.

Patients with SAD report greater absenteeism and reduced productivity due to social fears compared to control groups. Individuals with SAD are significantly less likely to aspire to social jobs suggesting they pre-emptively narrow their careers paths to avoid social scrutiny. SAD is consistently linked to lowered educational attainment, reduced income, and financial dependence.

The presence of SAD makes people vulnerable to other issues which is exactly the vulnerability that deceptive patterns seek to exploit in people. 66% of people with SAD have one or more additional mental health disorders, most common is clinical depression. An estimated one-fifth of people with SAD also struggle with alcohol use disorder. Women are more likely to have SAD than men, 8% to 6.1% past-year prevalence in U.S. adults.

Passive social media usage has been directly linked to an increase in social anxiety symptoms in some people.

The Examples

Fake Scarcity

The Pattern: Creating a false sense of limited availability of a product to pressure a user into an immediate purchase.

The Sources: Booking and travel websites.

The Case: You have seen them in your digital travels. Many major flight and hotel booking platforms that display messages like “Only 4 rooms left!” or “Only 2 seats remaining!” Even, “6 people are booking this flight right now!”

The Deception: Often, the price is not the only price or the scarcity is only for a specific, non-essential room type, for instance. The key manipulation is the weaponization of FOMO to get the user to skip comparison shopping, to get them to make a rash decision, or even review the cancellation policy. The war cry here is “Get the sale by any means necessary!”

Time Pressure

The Pattern: Usage of countdown timer or short windows of expiration that are often meaningless or reset easily, preventing rational-based decision-making.

The Sources: Flash sales and countdown clocks.

The Case: A popular e-commerce site uses a platform that is the widely used platform for e-com websites. That popular e-com platform has a plugin store, and that plugin store has a plugin for flash sales. “Sale ends in 11:34:21!” that is thrown in your face, you cannot miss the component this thing has been designed by. In fact, this is a plugin that got banned from this very widely-used e-com platform's plugin store, yet they still exist as a standalone product! You can go into the (plugin, at the time) administration panel and choose to restart the timer and just restart it whenever you feel the desire to. A 24 hour flash sale could, in reality, last as long as the company wants.

The Deception: The deal usually reappears the next day or the timer magically resets if the user refreshes the page or the user returns later. The pattern is aimed at inducing anxiety and panic, thus making the cognitive load so high, that the user clicks that buy button before they have time to consider anything about what impact buying the product will have on them financially, the necessity of having that product, or even the actual value of owning that product.

Confirmshaming

The Pattern: Insulting the target user or guilt-tripping them into opting into a service or remaining in a subscription they don't want or a mailing list they didn't sign up for.

The Sources: E-mail opt-outs and newsletter subscriptions and pop-ups.

The Case: When presented with an offer (usually a pop-up) to join a newsletter, the user clicks the “No” or “Decline” option, but the next pop-up or message shown is of text that is written to make the user seem foolish, selfish, morally inferior, or even less-than. A horrible individual even.

The Deception: Instead of a very simple, “No thanks”, the button or message reads, “No thanks, I don't want to save money today.” or “No, I don't care about that and prefer to stay in the dark.” Some even use cartoon or animated mascots or animals shedding a tear (looking at a very prolific language-learning platform who did this in the past and your green mascot).

Summary

To wrap this part one of a multi-part series on deceptive patterns and the weaponization behind them, I urge people to take their time and slow down. I know in the fast-paced world our lives are a mile-a-minute kind of speed where we have things to do and get things done. There is only twenty-four hours in a day and there isn't time to stray from the course. But you can!

Take time out and just do your due diligence. I know it is easy for me to say. Me, the author of this article, but I have experienced this very thing myself. SAD, FOMO, being manipulated by capitalism and corporate greed, deceptive patterns. I have lived this! Take your time, put an extra 15 minutes or more aside when you need to do a task online that involved your money. I don't let these companies take my money freely anymore. Neither should you.

Noticing the signs can be the first step to minimizing the impact these deceptive patterns have on us. Educating yourselves to make the right choice and steer clear of any company using these tactics, not doing business with the companies, can have a profound effect on a person. I can attest to this. The freedom I have now to spot the pattern and stay away from that temptation is great. It does not mean I don't occasionally fall prey to it, because I still do. This is why I wrote this article and I am writing more parts to this, and why I chose to deep dive into this to educate people.

Hopefully, this helps someone and we can fight these practices and learn, grow, and become aware that fighting deceptive patterns and practices can lead to better mental health, better choices, retaining our finances, and a little bit less stress, anxiety, shame, guilt, and fear in our lives. It can also show companies and corporations that the long-standing practice of eroding the general public's mental health is over and that we will not be subjected to these practices for the betterment of our lives.

Hero Image Photo by @felirbe on Unsplash

AI and Accessibility, Transforming Digital Access for People with Disabilities

Todd Libby — Thu, 12 Oct 2023 00:00:00 +0000

The Promise of AI-Powered Accessibility

AI has fundamentally changed what's possible in assistive technology. Machine learning models can now perform tasks that once required human intervention or were simply impossible. Screen readers have become more sophisticated, accurately interpreting complex web layouts and dynamically generated content. Image recognition allows blind users to understand visual content in real-time through their smartphones. Speech recognition has reached accuracy levels that make voice control a viable alternative to traditional input methods for people with motor disabilities.

The adaptive nature of AI represents perhaps its greatest strength. These systems learn from individual users, adjusting to speech patterns, writing styles, and interaction preferences. A person with atypical speech can train voice recognition to understand them specifically. Someone with cognitive disabilities can receive content simplified to their comprehension level. The technology molds itself to the person rather than forcing the person to adapt to rigid systems.

Real-time processing capabilities have opened new doors. Live captioning powered by AI makes spontaneous conversations, video calls, and streaming content accessible to deaf and hard-of-hearing individuals in ways that were previously limited to scripted, pre-captioned content. Predictive text and autocomplete features help people with dyslexia, motor impairments, or cognitive disabilities communicate more efficiently.

The Concerns and Limitations

However, AI accessibility tools carry significant drawbacks that cannot be ignored. Accuracy remains inconsistent, particularly for users from marginalized groups. Voice recognition systems frequently misunderstand accents, dialects, and non-standard speech patterns. Image description algorithms often misidentify objects or miss crucial context, potentially providing misleading information to blind users who rely on these descriptions to understand their environment.

The bias embedded in AI systems poses serious equity concerns. Training data often under-represents disabled people, people of color, women, and other marginalized groups. This results in systems that work better for some users than others, effectively creating a two-tiered accessibility experience. A voice assistant that struggles to understand a person with cerebral palsy or someone speaking with a strong regional accent fails at its fundamental purpose.

Privacy concerns loom large. Many AI accessibility tools require constant data collection to function effectively, continuously listening, watching, or tracking user behavior. For disabled people who may have no alternative way to access certain services, this creates a coercive dynamic where privacy must be sacrificed for basic access. The data collected could reveal sensitive information about a person's disability, health conditions, or daily activities.

Cost and infrastructure present additional barriers. Advanced AI tools often require expensive devices, high-speed internet connections, and ongoing subscription fees. This excludes disabled people who face higher rates of poverty and unemployment. The digital divide within the disabled community risks widening as AI-powered accessibility becomes the standard expectation.

Over-reliance on AI can also lead to the neglect of fundamental accessibility principles. Companies may treat AI as a silver bullet, using it to patch inaccessible designs rather than building accessibility into products from the ground up. Automated image descriptions, for example, should supplement rather than replace proper alt text written by content creators who understand context.

Long-Standing AI Accessibility Tools

Several AI-powered accessibility tools have maintained presence for years now, demonstrating both longevity and continued evolution. Google's Live Transcribe, launched in 2019, uses speech recognition to provide real-time captioning on Android devices. Microsoft's Seeing AI, also released in 2017, narrates the visual world for blind and low-vision users through their smartphone cameras, identifying objects, reading text, and describing scenes.

Apple's VoiceOver screen reader has incorporated machine learning elements since at least 2019, using AI to improve image recognition and provide better descriptions of on-screen content. Dragon NaturallySpeaking, now Dragon Professional, has used various forms of AI and machine learning for speech recognition since well before 2020, continuously improving its accuracy and adaptability.

Otter.ai, launched in 2016, provides AI-powered transcription services used by deaf and hard-of-hearing students and professionals. While primarily a transcription tool, its accessibility applications have made it valuable in educational and workplace settings. Windows' built-in voice typing and dictation features have incorporated increasingly sophisticated AI since their introduction in Windows 10.

Be My Eyes represents a particularly innovative approach to AI accessibility. Originally launched in 2015 as a platform connecting blind and low-vision users with sighted volunteers through video calls, the service evolved significantly with the introduction of its Virtual Volunteer feature in 2023. This AI-powered assistant uses advanced vision models to analyze images captured by users and answer questions about their surroundings, read labels, provide navigation guidance, and assist with countless daily tasks.

The integration of AI hasn't replaced the human volunteer network but rather complements it, offering immediate assistance when volunteers aren't available or for quick queries that don't require human judgment. This hybrid model demonstrates how AI can enhance rather than eliminate human connection in accessibility services, providing both technological efficiency and the warmth of community support.

Impact on the Disabled Community

The impact of AI on disabled people's lives has been profound and multifaceted. For many, these tools have enabled independence that was previously difficult or impossible. A blind person can now identify currency, read handwritten notes, or navigate unfamiliar spaces with smartphone apps. Someone with severe motor impairments can control their entire digital environment through voice commands.

Educational access has improved dramatically. Students who struggle with traditional note-taking can use AI transcription. Those with reading disabilities benefit from text-to-speech that sounds natural rather than robotic. Language translation powered by AI helps deaf individuals who use sign language access content in spoken languages.

Employment opportunities have expanded as AI tools enable disabled people to perform tasks that were once barriers to certain careers. Voice recognition allows those who cannot type to work in writing-intensive fields. Screen readers with better AI understanding enable blind programmers to navigate complex codebases more efficiently.

However, the community remains divided on the net impact. Some disability advocates worry that AI perpetuates a "medical model" approach, trying to "fix" disabled people rather than addressing societal barriers. Others note that AI accessibility often focuses on individual solutions rather than pushing for universal design that benefits everyone.

The rapid pace of AI development has created anxiety about being left behind. Disabled people and advocacy organizations often lack the resources to evaluate new tools, provide feedback, or influence development priorities. When AI systems are deployed without adequate testing with disabled users, the results can be frustrating or even dangerous.

Looking Forward

The future of AI in accessibility will likely depend on how well the technology industry addresses current shortcomings. Meaningful involvement of disabled people in design and testing processes remains essential. Training data must become more representative. Privacy protections need strengthening. Business models should ensure that cost doesn't become a barrier to access.

AI holds genuine potential to create a more accessible world, but only if deployed thoughtfully and ethically. The goal should not be to replace human-created accessibility or fundamental design principles, but to augment them. AI works best as one tool among many in a comprehensive approach to accessibility that centers the needs, preferences, and expertise of disabled people themselves.

The conversation about AI and accessibility must continue to include the voices of those most affected. Their lived experiences provide insights that no algorithm can replicate, and their perspectives are essential for ensuring that technological progress truly serves everyone.

Whataboutism

Todd Libby — Fri, 15 Sep 2023 14:24:52 +0000

What about it? This doesn’t need accessibility.

The amount of ego doesn’t surprise me when the conversation of accessible code arises. Code, in any stage, from alpha all the way to production needs to be, should be, and can be made accessible. But a subset of the developer community, a rather large subset seems to think otherwise.

Thinking that there is no such thing as a disabled developer is on par with thinking we are the only living organism in the entire universe. That level of ego makes part of the reason why the Web and digital world is inaccessible. Those people would rather go to the grave thinking they are right, rather than be wrong.

We don’t talk about it much these days.

“This product uses AI and it will ship production-ready code!” but when challenged, they (the developer subset with egoism at the forefront) come out of the woodwork to attack people and argue with people that are pointing out the fact that is in fact a falsity.

That’s just one example of why without education and research, the Web is doomed to be inaccessible even more than it already is.

If those who egos aren’t checked at the door had their way, they’d ship their own computers and call it a day because, “It works on my machine!”. Hey Blaine, we’re not shipping YOUR machine.

If there were less ego from those that would rather die on the cross they make for themselves then maybe, just perhaps there would be a little more accessibility in the digital world. Yet, here we are and here I am writing what I can imagine will ignite some kind of firestorm in some ecosystem of keyboard wunderkind who can’t see beyond their own screens.

“Oh, I agree there needs to be accessibility but…” You ended the hate with the key word in that sentence. “But”. A “but” is an underlying statement to prove to yourselves you are correct. The reassurance that you are right and the other side of the argument is wrong no matter what the facts are or what the data is.

So when an accessibility professional says, “Hey, I just wanted to bring to your attention there are issues here. Accessibility concerns you want to address before making a a statement such as…” Stop going into a defensive posture and on the attack immediately.

That’s not an attack, it is someone telling you there are issues that need to be fixed to make your product, your brand, your app, your site, accessible to people with disabilities.

You created something more likely to make you money. That’s how tech works isn’t it? Then why would you shut out a subset of the population for whatever reasons because you didn’t want to make it accessible? Do a search for “disposable income of disabled persons”. You’d be surprised.

And to devs that wonder why it matters so. Think of these times when and if you ever become disabled because it could happen at any time to any of us.

Dear Molly

Todd Libby — Wed, 06 Sep 2023 00:00:00 +0000

CW: Death

Molly Holzschlag passed away yesterday at age 60 in Tucson, Arizona. As I sit and type and get choked up, I cannot even begin to tell you about how someone I looked to and who helped me become who I am today, meant to me, especially after corresponding with Molly the last three years. Two, with me in Arizona.

I learned of Molly's passing through social media yesterday and for some reason, although we had talked and chatted since at least 2004, it has hit me harder than most passings I have been through.

We had always chatted about the Web, I had interviewed Molly for the podcast, and we chatted and were friends on Facebook where we exchanged messages.

I had always said to Molly, "When I can I want to come out to Arizona and meet you and just talk about the good old days of the Web." and in Molly fashion we went into a dive into the good and the bad of the Web.

Those were our conversations. Then I moved to Phoenix in 2021. I had got in touch and had tried unsuccessfully a few times to see Molly, but either she wasn't feeling well, it wasn't a good time for her, I respected the fact she was going through what she went through and we had cancelled a few times.

When we did exchange telephone numbers and speak on the phone, I could hear the pain and said, "It is okay. There will be another day." Well, there will not be another day and this makes me incredibly sad.

When we had our chat for the podcast, before and after we talked about the people that she blazed the trail with. Dave Shea, Eric Meyer, Jeffrey Zeldman, and the list goes on and on. The face-to-face showdowns with Bill Gates numerous times about Internet Explorer, calling her "the annoying web standards girl", the conferences and speaking, and owning the stage.

We discussed behind the scenes with Aaron Gustafson about reviving the Web Standards Project and wanted to do something(time permitting) starting near the end of the year or next year.

If you knew Molly and knew her well, I envy you. She was a bright light and a magnum opus all her own. If you did not know Molly, or are new to the game of the Web, familiarize yourself with what Molly was able to accomplish in her lifetime that would take others countless lifetimes. We would not be here if it was not for the tour de force Molly was.

Molly has been described as "a force of nature" and I have to say, nature doesn't have anything on what and who Molly was and forever will be. She leaves an indelible mark on the Web.

Molly was one of the first few I got the courage to converse with via comments on her site and although I never got to attend a conference she spoke at, I followed her with the fervor she had when she advocated for web standards. She taught me from far away as much as she taught me the last two years in the same state mere hours away.

The world is a little less brighter, the world has lost a force never seen before and maybe never will. Molly is looking from beyond and still telling us to get our shit together. She looked death in the face and laughed. She is finally with her Ray now.

Rest easy, dear Molly. Rest peacefully. ♥

The Perpetual Circle of Accessibility

Todd Libby — Tue, 05 Sep 2023 19:15:44 +0000

The History

In the time I have been practicing accessibility, whether it was behind-the-scenes in a not-so-public way of putting myself out there like I did for most of my career or whether it is like it is now with me. Writing articles, giving conference talks, appearances on podcasts and streams.

The fact of the matter is this. I have had to repeat myself it seems a million times over. And over. And over it seems year after year after year since 1999. That's 24 years if you're keeping score.

It is the same items of order. Low contrast of text, alternative text of images, empty buttons or input labels. Empty links and missing document language attributes.

Sound familiar&quest; Well if it does, then you know. If it does not, then I shall point you to the WebAIM Million Report which only goes back the past five years. I can tell you with conviction that I have been harping these things over and over for longer than that. Ten-plus years at least.

The Question

Why do accessibility professionals scream at us when we…

I am not going to speak for the accessibility community as a whole, but if my colleagues and accessibility professionals agree, then you can bank on it.

We have told you over and over again. Time after time, year after year. Most of you do not listen or care enough to listen.

Or when you see something we post, like "Hey, if you're doing this, please don't. Please do that." and then you post:

As you see in my reply, I have told you. I have posted on my blogs, on other sites, on message boards and in social media circles about what to do but you do not listen or you do not care enough to listen. Maybe you do?!

Maybe, you care enough to actually see it, but you do not retain the information, and then when you see another post, you ask me again (yes, this happens!).

I have told you. I have seen the suggestions, the tutorials, the guides on how to make something accessible without mucking it up and yet, 95-99% of the internet is still inaccessible (I lean towards 99%).

The reasons are your own, but when you snap back at me with "Why do you scream at us, tell us what we're doing wrong!" I have. I mean, I have.

<button>This is a cool button</button>

is more accessible and easier to implement than:

<div
  role="button"
  aria-label="A button as a CTA"
  aria-labelledby="IdOfSomethingUnrelated"
  onClick="Do something JavaScripty()"
>
    This is a div disguised as a button
</div>

A div has no semantic meaning. More often, you see a <div> as a "wrapper" in the times since HTML5. That one container to rule them all. Then you get into your HTML5 landmark elements (e.g., <main>, <section>, <nav>, <footer>, etc.). But I have told you.

The Examples

Please put alternative text on the image you posted on Twitter.

Please use better contrast for the text on this because I cannot read it.

Screen reader technology will not read a label because you have forgotten it.

You are not shipping your machine. A screen reader will skip over all this.

Who do you want to exclude when you make this inaccessible?

Please use the button element. It is more accessible than a div.

One example: Flashing video content on the former Twitter. I asked the original poster (OP), "Please add a content warning for people that are prone to epileptic seizures and other vestibular issues, thank you." Just to have some clown reply with "Well then don't watch the video."

Well, it is easy for someone that is abled to say that and dismiss the disabled community with their ableism and ignorance. They do it every day online. Developers and designers included. More in the developer space than the designer space. Because "move fast and break things" or "coding is my life, here are ten reasons why you should do what I list here on Twitter."

If you're going to blatantly dismiss the disabled community and exclude them, then prepare for that backlash. Because it is deserve and justified. Since the internet became public and more and more disabled people try to gain access, you are the barrier.

and there are many more examples. You don't have to look too far to find them on Twitter.

The Burnout

Developers will experience burnout if they are not cognizant of the amount of work they are doing. It is inevitable. Well, accessibility professionals do too. Tenfold.

I'm tired. I'm burnt out. I'm sad, depressed, struggling, tired, tired, tired. I am the parent, developers and designers, and everyone at the organization(s) that I have to tell over and over again, are the child.

I have scolded you, I've finger-wagged, I've publicly shamed, I have educated, I have suggested, I have done everything in my power until I am blue in the face and angry, exhausted, and exasperated to try and get it through to you that accessibility for disabled people matters. You, most of you. The majority of you, have not listened. You don't care.

I am burnt out. I'm the beyond tired parent with all the children running around wreaking havoc. I need a vacation from you but I cannot because I have got to look over you and make sure you're not burning the house down. Yet, I don't know about the small fires that have already been set around the house. Only the small fires I can see in the room I'm in.

The Education

There are those that are happy to help and answer questions because they are passionate about accessibility and want a more accessible Web and a level playing field for people with disabilities. I'm always happy to say, "Here is why this isn't an accessible solution..."

There are those that will virtually spat at you and block you or admonish you, or scold you, or tell you to "fuck off" (Yes, this has happened to me). Whatever their personal issues, leaving those aside, they are fed up way beyond what anyone can comprehend. Because they have been repeating themselves over and over and over again.

The one's that help, the helpers? Just send me a DM, or a post and ask. Or do an internet search (search engines still exist. Fewer now than when I went online, but they are there!) for the solution! If you question that, please ask!

The Solution

Ask. Simply stated. Ask.

The Takeaway

There is a group of people that need a fair and equal Web, the disabled community. For decades, they have been fighting on and off the Web for equal access. Hardly anyone listens. If anyone does listen, how many of them act on that? A few.

You see a post, it suggests something but doesn't explain why, but you don't use the back channels to ask. That is on you that is not on the person that posted the suggestion without a solution. Just because you cannot see it does not mean that it is not there. It is.

It is a never-ending perpetual circle of grief and pain for me that I have to look at something online and pass it by because I have said it a billion times, "Use alternative text for your images for people who use screen reader technologies or assistive tech, please"

It's the constant merry-go-round that you get spinning so fast, you jump on and spin for an hour and you feel ill and like you are going to throw up.

That is the current state of accessibility. Every time someone ignores a suggestion, I get ill. Because that person doesn't care. Accessibility is a right, NOT a privilege.

That said, you wonder why we shout it out on socials? Read this article again.

Hero Image Photo by Elisa Ventur on Unsplash

Article Heading Photo by Towfiqu barbhuiya on Unsplash

Main-ly Speaking

Todd Libby — Thu, 24 Aug 2023 14:04:54 +0000

I tweeted/posted out a half-joking question the other day about the usage of the <div> tag still.

element to hold the content of their sites in?""/>

Then I started a small conversation. Then I got to thinking. Why are devs not using <main> more often?

The "why"

I've concluded my accessibility auditing career as of yesterday when I audited an education platform that was extremely inaccessible. The documentation was over 100 pages that I sent back to the client. That is a lot. Not the most, but it is a lot. Usually 100 pages are par for any high-level audit that I have done as a solo consultant.

The fact that I saw usage of the <header> and <footer> elements, yet so sign of <main> was there. The elements from HTML5 used were:

<header>
<nav>
<section>
<article>
<aside>
<footer>

No <main> as far as the eyes could see.

I mean there was no sign of the element to be found.

The "What"

Is it fear? I mean, I know it really isn't fear, but is it lack of education (yes) or is it lack of understanding semantic HTML and the benefits of using semantic HTML over an element that has no semantic meaning?

I have seen a lot of replies when I have asked this in the past and in 25 years of asking it is usually the same repsonses:

Don't have time to deal with HTML.

Not enough time to deal with it now.

It's X framework and I can't change that. (You can if it is open source).

It's habit and I just do it that way.

What is semantic HTML?

I'm using native apps, not hybrid/web app.

These are among a lot of reasons. I get it, but I got it 20 years ago. 10 years ago. 5 years ago maybe. But in 2023? Now that HTML5 has been out since 2008 (15 years ago), developers should know about HTML5.

Whether they know is one thing. They should. You should. Whether they care or whether you care, is another. You all should care.

I mean if you're using other HTML5 elements, why omit <main>? That says to me, that whomever it may be, you're being lazy if you know and if you are uneducated about HTML5, you're not doing the research. <main> is one of those elements that is widely known.

So what? Big Deal.

These "landmarks" have an impact on accessibility. If you have ever read the bulk of my articles, they are on accessibility. Using HTML5 landmarks as they are intended is helping out people with disabilities by making the structure of the page accessible to screen reader technology and other assistive technology(AT) e.g., keyboard navigation.

When I see this when I am creating a new project in a framework:

<!DOCTYPE html>
<html lang="">
  <head>
    ...
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

I'll tend to ask when doing an accessibility audit "why aren't you using <main>?" and only if it is a web or hybrid app knowing you'd have to file an issue and ask for the <div> to be changed to <main> but that isn't something I'd expect to happen but I am not opposed to it at all.

What I would like to see more of is this, if applicable:

<!DOCTYPE html>
<html lang="">
  <head>
    ...
  </head>
  <body>
    <main id="app"></main>
  </body>
</html>

The Benefits

Skip to content links. When someone using keyboard navigation or AT wants to skip repeated content, they can easily skip to the #main content area.
It's the fresh, new, and cool wrapper div! I'd use <div id="wrapper"> a lot until 2008, then I started to use <main id="wrapper"> or whatnot when using HTML5 more often in projects. It's a landmark, why not use it?
Reader mode looks for the <main> element as well as headings and content structure when converting the content into reader view.
<main> is a lot easier for maintenance and code readability. You'll be able to visually spot a <main> element much faster than a <div> within a vast sea of divs in that bowl of div chowder.
Using <main> could also possibly save some bytes within your files (CSS or otherwise) in that you can use main in the stylesheet instead of using classes or IDs (e.g., .main or #main).
Without <main> assistive technology cannot create an accurate outline (accessibility tree) of the page's content.

and I am sure there are more that I'm not listing, but the fact is and let's face it, if you're going to use all the other HTML5 landmarks, just use the main landmark in a web or hybrid web app or if you are authoring a Web page.

That's it. Don't be scared of <main> and if you already weren't, just use it if it is applicable in the project.

If you are not sure of how to use main, educate yourself. You could read the spec or the MDN docs which should be the de facto resource for researching anything HTML or CSS.

I get that there are cases where it is a <div> and what I am saying is moot. I know that, I understand that, I got it. But...

If you can use <main>, get it in there and make the experience just a little more accessible.

Photo by Jas Min on Unsplash

Is Your Community Accessible?

Todd Libby — Sun, 18 Jun 2023 22:55:52 +0000

As I was writing up some talks on a couple of topics having to do with accessibility, I stopped to think for a bit about community.

We are all part of some community perhaps, online as we do our jobs. Especially in developer relations and developer experience. We hang out is the Discords and Slacks, we chat on Twitter and Mastodon and other socials. We all have a tie that binds us to community to learn, to grow, to communicate.

As I thought about it more I kept thinking back to "how accessible and inclusive are those communities?" and I felt the need to write about it.

Accessibility

To the point of accessibility, how accessible is the platform of the community you are engaged in? Most of the communities we are a part of have their issues. Hell, 99% of the Web is inaccessible. Do we have a way to make it better? Indirectly we do. We ask for improvements, we file bug reports, feature requests (accessibility is not a feature), and we file pull requests.

We don't have much pull perhaps when it comes to the Twitters and the other sites we log into. But we can use our voices to help improve them. If we want everyone to be able to participate, that's advocacy for the betterment of our spaces. Listen to those people that have a request and share it, spread it around. Help make those communities a little bit better.

Inclusion

Which brings me to my next point, inclusion. We all want everyone to enjoy our communities (generally speaking). So we want to welcome those with open arms and make them feel like they are in a space where they can learn, thrive, and share.

Let's make sure those folks are included. That also ties into accessibility. You make the person feel included, that makes the community accessible to them. If you don't have that feeling of inclusion, you make the community inaccessible. Those people that are feeling excluded won't want to be a part of a bigger thing. Period.

A Part Of

I want as many people to feel like they belong to a community as best as I can. I too, also want to feel included and have access to communities that I want to learn from.

I can tell you from the experiences I have had, many online communities are welcoming and inclusive. Yes, there are those we all know about that aren't so good at being inclusive and accessible to everyone. We have the power to change that though.

A great example is the Ionic Discord community. I started learning Ionic a few months ago, joined the community, and it is a very welcoming and inclusive community. I haven't been too engaging there of late, but from my brief interactions it is a terrific community. That spills over to the GitHub side and the Discourse forums as well.

Summary

Making folks, part of instead of apart from helps everyone in the long run. If you have control over your communities, make sure they are as accessible and as inclusive as they can be. If you don't have control, help make those communities accessible and inclusive.

Accessibility starts with "access" and inclusive contains "us".

Photo by Tim Mossholder on Unsplash

Staying on the Course

Todd Libby — Sat, 03 Jun 2023 20:01:44 +0000

This comes from a place of learning and constructive comments and discussion are welcome. Let's keep it to the level that I am sort of "getting my feet wet" in the understanding of all things to do with each position and that I don't have the full length and breadth of knowledge some of you may have. Keep it civil in the comments, thanks.

My latest adventure has me transitioning out of the accessibility auditing and remediation space and trying my hand at either developer relations or developer experience. Two fields I know of that have a lot of great people who speak at a lot of events on a wide range of topics.

But in the final stages of a career that I have had that has lasted a quarter of a century, it's not as easy at it seems. There are a lot of things I don't know or understand yet about the two spaces I am looking to move to, I am sure. I am halfway there according to a lot of terrific people I know though.

Advocacy

I've advocated for accessibility and making things accessible for disabled people for a long time now and advocacy I get it. I understand it. That is the part that is done. I know how to work (for the most part) social media channels to spread that advocacy.

Talking about it is half the battle. Getting people to understand and adopt or adapt is the other half. I have had relatively good success over the years in adapting or people adopting.

Terminology

What is Developer Relations? Developer Experience? Is it the same? Is it two separate entities?

Let's break this into pieces.

What is Developer Relations?

That, to me, is getting a product or a brand out there and setting up the collaboration between community and company.

What is Developer Experience?

To me, that is the events of bringing community and company together and the experience developer have with the brand or product.

Is it the same? Is it two separate entities?

To me, it is both. Confused? I'll try to explain.

With all the underlying things that happens in both spaces that I may not know about, I think Developer Relations ("DevRel" going forward) is under the umbrella of Developer Experience ("DX" going forward). It appears to me that there are more moving parts in DX rather than DevRel.

Kurt Kemple has a great article on their website about this which I wholeheartedly agree with.

I'm still learning, so that is the path I am taking. The learning path to something better.

The Search Commences

My 20 years of job searches concluded before the last position of an average from a spreadsheet I kept of 4 jobs from 2,643 resumes. If that was a batting average in baseball, that would be .0012 and that is the worst. that's a tenth of a percent success rate for me.

So far, in my search for something outside of development/accessibility, I am 0 for 20 for DevRel or DX job applications. I knew it would be rough because the job market is rough. People are getting laid off at record paces and companies are getting rid of people for people that aren't asking for as much money. The job market sucks.

It's not a good time to be looking. But I see a lot of people more so now changing roles or finding new jobs, which is promising. Maybe I can too. I got 10-12 good years left in me.

The moral of this? Don't give up and stay the course. You'll find your job too if you're looking.

Goals

I've set three goals for the rest of 2023. Those are:

Find a role in DevRel or DX,
Get back to my programming roots,
Find a role with a company I have had my eye on now since January.

Set your goals and obtain them. I believe in myself and you should believe in yourself as well. You can do this and so can I. Even at 52 years old.

The Age Thing

It sticks with me, ageism, companies looking for younger people, and on and on. I've managed to self-teach everything I know, as well as learn from many countless people who are amazing.

I also know I bring value and an intangible. Accessibility. So there should be a role somewhere where I can use that intangible. What is your intangible? Ask yourself that question. What is your thing you're known for?

The age thing doesn't scare me but it does concern me. As us grey beards advanced and the finish line of retirement draws closer, I keep telling myself, "One more. There's one more role out there waiting for you to take it and succeed".

I hope so. I may be 52 in years, but having come out of burnout and back into the coding and the programming and the learning and experimenting in the past two months, I feel like I'm 16 again.

Whether You're New or Not...

Stay the course. If you're in a position that you love and the company you work for treats you good, hold on, but always be looking behind you. Your job doesn't love you, and as we have seen recently, neither do the decision-makers. You, as am I, are replaceable at any given time.

If you're looking around for a home, find one that your gut tells you is it, is the one (for now). A lot of people follow the money, but listen to your gut. I wish I had a time or two in the past.

"If you're going through Hell, keep going".

Not sure where that originated, there is debate. Churchill, others? But it is apropos to what we do in tech. We get done with a company, we keep going. We go through hell at a job, we keep going until we find a good place to work. I believe there are some of these companies out there. One is the one I have my eye on for a role there this year.

Summary

I jotted these things down as a reminder to myself that it's just not all about hammering away at a keyboard or spending countless hours moving pixels in Figma. It's not all about scrums and waterfalls, sprints or all-hands brainstorming meetings. It's about staying the course and making sure we are taking care of ourselves.

I'm looking back on 25 years and am a little amazed how I navigated my career. When you look back, as we all do, look back and smile knowing you succeeded. I do for the most part. The majority of my time has been contracting and working for myself. Those times I did work in a company and a team were amazing and some were not so much.

I've seen a lot of failure on my end and success as you will too. I've worked under some amazing people and then I have worked under some people whom I wonder if they accidentally tripped and fell into the role they are in and wonder what dumb luck it must be to fail upwards. That's tech.

All I know is this. I hope to obtain the final three goals I have for this year and then assess in 2024 where I am at, if anywhere.

Stop and take a look around and see where you're at. If you're succeeding, stay the course. If not, then reach inside and stay the course. You'll get there. I hope I will.

Photo by Dan Meyers on Unsplash

Ionic and Vue, Part Two (File Structure)

Todd Libby — Tue, 25 Apr 2023 00:00:00 +0000

It has been a bit, but following up on the first part of this series, I'm going to be diving into file structure, so pitter patter, let's get at 'er!

File Structure

NOTE: This is an introductory overview and this section is from the generated files and folders from running the ionic start command. There are more folders and more comprehensive ways to set things up. This is my experience through the Ionic CLI.

This also takes into consideration you have familiarity with the node_modules folder and test folder if you're testing with Jest and/or Cypress. I will be going over the testing stuff later on in this series.

src

This folder is where the bulk of the work will be done to create your application. This folder is where much of the work, and frankly nearly all of the work will be done in.

router

The router folder is where all the routes are kept, added, and each route has its View component with route name. So the index.ts file will point to the HomePage.vue file. The route points to the HomePage view.

The Home route is defined as the default path.

import HomePage from '../views/HomePage.vue'

theme

This is the folder that holds the stylesheets for your project. You can find out more about theming from the Ionic docs here.

Global theming for the project can be defined here, Ionic has such names as success, danger, warning, and more for colors for different elements in the UI.

views

The views folder is what is render for what page. HomePage.vue is rendered when the Home route is defined in the index.ts file. The same would be for ContactPage.vue, AboutPage.vue, and others.

The home page code looks something like this:

<template>
  <ion-page>
    <ion-header :translucent="true">
      <ion-toolbar>
        <ion-title>Blank</ion-title>
      </ion-toolbar>
    </ion-header>

    <ion-content :fullscreen="true">
      <ion-header collapse="condense">
        <ion-toolbar>
          <ion-title size="large">Blank</ion-title>
        </ion-toolbar>
      </ion-header>

      <div id="container">
        <strong>Ready to create an app?</strong>
        <p>Start with Ionic
          <a
          target="_blank"
          rel="noopener noreferrer"
          href="https://ionicframework.com/docs/components">
          UI Components
          </a>
        </p>
      </div>
    </ion-content>
  </ion-page>
</template>

<script setup lang="ts">
import { 
  IonContent, 
  IonHeader, 
  IonPage, 
  IonTitle, 
  IonToolbar 
} from '@ionic/vue';
</script>

<style scoped>
#container {
  text-align: center;
  position: absolute;
  left: 0;
  right: 0;
  top: 50%;
  transform: translateY(-50%);
}

#container strong {
  font-size: 20px;
  line-height: 26px;
}

#container p {
  font-size: 16px;
  line-height: 22px;
  color: #8c8c8c;
  margin: 0;
}

#container a {
  text-decoration: none;
}
</style>

I won't go into the specifics here until another installment of this series, but it won't be too long before I dive into that part.

Next Steps

Again, this was a very high-level overview of the file structure of the Ionic/Vue application and the major parts of the folder structure.

I'll get more into the deeper parts of the template files, router, and more later in the series.