CodeSpud RSS Feed

View Transitions vs. My Old CSS Habit: What Actually Changes

Mon, 17 Aug 2026 08:29:00 GMT

I’ve made CSS transitions for years. This article shows you what changes when the browser does the coordinating instead. Also where we are with ViewTransition in ReactJs.

Almost every state change animation on the web runs on the same trick. Add a class, wait for the browser to notice, remove the class when the animations should end transitionend, or on simpler work that uses setTimeout set to whatever duration makes sense in the CSS. This is the pattern most front-end developers have leaned on for years, myself included, and it works well enough.

But the code always felt wrong to me. You end up doing most of the job by hand, coordinating a start state and an end state while the browser waits on the sidelines. So when <ViewTransition> kept showing up in React’s release notes, I wanted to actually sit down with it, instead of nodding along at another shiny component name.

The old way, and why it always felt fragile
What the browser does differently
React wraps it, with real constraints
Building the same toggle two ways

The old way, and why it always felt fragile

Here’s the pattern we are going to work with:

function Card({ children }) {
  const [open, setOpen] = useState(false);
  const [animating, setAnimating] = useState(false);

  function toggle() {
    setAnimating(true);
    setOpen((o) => !o);
  }

  return (
    <div
      className={`card ${open ? "card--open" : ""} ${animating ? "card--animating" : ""}`}
      onTransitionEnd={() => setAnimating(false)}
      onClick={toggle}
    >
      {children}
    </div>
  );
}

.card {
  max-height: 60px;
  overflow: hidden;
  transition: max-height 300ms ease;
}
.card--open {
  max-height: 400px;
}

Nothing here is new. The code before is not technically wrong it’s just you’re the one keeping three things in sync.

There’s the logical open flag. There’s a separate animating flag, we keep track on so the code knows when the transition is running. And there’s a CSS class name that has to match a selector we added in a separate file.

Miss the onTransitionEnd call, and the animation runs forever, breaking other interactions on the page. One bad pattern in some code I’ve seen is separate timing for CSS and one for JavacScript. Forget updating one and you get a bug that’s not easy find in reviews.

The bigger limitation is scope, though. CSS transitions animate properties changing on an element that already exists.

CSS transitions can’t animate one element being swapped for a completely different one. They definitely can’t animate a whole page turning into a different page, because there’s no shared element left for the browser to transition between. For that gap, people reached for react-transition-group or framer-motion, which solves the mounting problem well but add a dependency and a second API on top of the CSS you already know.

What the browser does differently

The View Transitions API skips the class-juggling by working a level up, at the whole-DOM-snapshot level instead of the single-property level. You hand the browser a callback that updates the DOM, and it takes care of the rest:

document.startViewTransition(() => {
  updateTheDOMSomehow();
});

Before that callback runs, the browser takes a screenshot of the current page. After it runs, it takes a second screenshot of the new state. Then it builds a small pseudo-element tree, ::view-transition-old() and ::view-transition-new(), and cross-fades between the two images by default, since it already has both snapshots sitting right there.

No transitionend listener required. The browser owns the whole lifecycle, and it cleans up the pseudo-elements the moment it’s done.

sequenceDiagram
    participant JS as Your callback
    participant Browser
    Browser->>Browser: snapshot "old" state
    JS->>Browser: mutate the DOM
    Browser->>Browser: snapshot "new" state
    Browser->>Browser: build ::view-transition-old/new
    Browser->>Browser: cross-fade (or your CSS animation)

You can still write real CSS if the default cross-fade comes out boring. The pseudo-elements are just elements, so you target ::view-transition-old(root) and ::view-transition-new(root) with your own @keyframes, and the browser runs those instead of its default fade.

What you’re not doing anymore is manually tracking which state you’re leaving and which state you’re entering, since the browser already has both.

This used to be a Chrome-only party trick, which is probably why a lot of older tutorials still target it. That’s changed quite a bit lately. Current support data puts single-document View Transitions at roughly 90% global usage, with Safari on board since version 18 and Firefox shipping it too.

There’s a second half to the platform API, not included (yet) on React code. Cross-document transitions animate across a full page navigation rather than inside a single-page app. Opting in takes one line of CSS, an @view-transition at-rule with navigation: auto, declared on both the page you’re leaving and the page you’re arriving at.

Two events, pagereveal and pageswap, fire on the way in and the way out, so the transition can be adjusted based on which page is which. Support here is a step behind the single-document API, though. Caniuse puts cross-document transitions at roughly 86% support: Chrome, Edge, and Safari 18.2+ all ship it, but Firefox still only has it partially implemented. For a blog like this one, still generated the old-fashioned multi-page way for most routes, that’s the half of the API that matters most, and the one to feature-detect before you use it.

React wraps it, with real constraints

React’s <ViewTransition> is a declarative wrapper over that browser API. That is putting it simply but its true.

As of the stable React 19.2 release in October 2025, <ViewTransition> did not ship. The component’s own reference page still lists it as Canary and Experimental channel only, months later, as of this writing. Plenty of tutorials online will show it to you like it’s a settled API. It isn’t yet, so treat any production use of it as an experiment you’re opting into on purpose, not a feature you can quietly reach for.

That said, the design is worth understanding regardless of channel. The raw browser API is imperative, since you call startViewTransition() yourself and hand it a DOM-mutation callback. React is declarative, so React’s version flips that around: you wrap the JSX you want animated, and React decides, during a transition, which wrapped boundaries actually need one.

import { ViewTransition, startTransition } from "react";

function Card({ open, children }) {
  return (
    <ViewTransition>
      <div className={open ? "card--open" : "card"}>{children}</div>
    </ViewTransition>
  );
}

There are three caveats you need to remember:

<ViewTransition> has to be the outermost thing a component returns, not wrapped by a <div> or any other DOM element above it, or React can’t attach the enter and exit animations correctly.
It only activates for state changes wrapped in startTransition(), useDeferredValue(), or a resolving <Suspense> boundary, so a plain setState call animates nothing at all.
If two <ViewTransition> elements share the same name, expecting a shared-element morph between them, only one may be mounted at a time or React crashes.

That last constraint makes sense once you remember it’s tracking identity across a delete-and-insert, not just a style change. React also gives you a way to vary the animation by why a transition happened, not merely that one happened, through addTransitionType:

<ViewTransition
  enter={{
    "navigation-forward": "slide-left",
    "navigation-back": "slide-right",
    default: "auto",
  }}
>
  <Page />
</ViewTransition>

startTransition(() => {
  addTransitionType("navigation-forward");
  navigate("/next");
});

That’s the bit the raw browser API doesn’t hand you for free: a forward navigation and a back navigation can now animate in opposite directions, from a single component, without you threading a direction flag through props yourself.

The 19.2 release notes are clear that work is still in progress. One change batches Suspense boundaries during server-side rendering specifically so content streaming in close together reveals as one animation instead of several chained ones. It’s framed plainly as prep work, not a finished feature, which matches everything else about this component’s status right now.

Building the same toggle two ways

You see the difference when you put both techniques side by side.

The CSS version uses class name for “open,” a second class name for “animating,” and an event handler to unwind that second one.
The View Transition version has one wrapper and a trigger.

function Card({ children }) {
  const [open, setOpen] = useState(false);

  function toggle() {
    startTransition(() => setOpen((o) => !o));
  }

  return (
    <ViewTransition>
      <div className={open ? "card--open" : "card"} onClick={toggle}>
        {children}
      </div>
    </ViewTransition>
  );
}

In the ViewTransition code above, the animating flag is gone. There’s nothing animation related to track, because the browser’s own transition object resolves when the animation finishes, and React never asks you to babysit it.

Just a gentle reminder about accessibility, we still need to set up an override for users who enabled “prefer reduced motion”. The browser does not include it when you enable view transitions:

@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

What surprised me most, going through this, is how little of the hard part actually changed. Coordinating a shared-element morph between a list item and its detail view was always going to require matching identity across two separate renders. It was the same with react-transition-group, and it’s still true here.

<ViewTransition name="..."> just names that identity explicitly, instead of you inferring it from a key prop and hoping the DOM diff cooperated. The name is a kind of contract to the browser: these two elements are the same thing, so animate between them accordingly.

Wrapping up

There’s nothing wrong about the old CSS pattern. For one element changing one or two properties, it’s still the least code one could write, and I’ll probably keep using that. See my codepen for samples.

It becomes more complex if the work involves more than one element, a full page swap, or shared indentity between what’s leaving the page and what’s arriving. That’s exactly the gap the View Transitions API is made for, by working at the snapshot level instead of the property level.

React’s <ViewTransition> makes that native capability feel at home in a component tree, which is genuinely nice. Can’t wait for a stable channel, until then, I’ll be watching the release notes.

Happy coding!

My Drafts Folder Is a Graveyard, and a WIP Limit Fixed It, So Far

Tue, 11 Aug 2026 08:29:00 GMT

Every idea for this blog starts the same way. I pin a note in Google Keep, or I scribble a line in the notebook that lives on my desk, and that’s it. There’s no formal next step after that. Nothing enforces the “idea” into “task.” It just sits there next to a dozen other notes until I think its worth doing or I forget why I wrote it down.

That gap is the problem, and it’s a lot like a parking lot with three spaces and noone to attend to it. A sign says the limit is three cars.

Nobody’s watching, so cars just don’t leave. I’ll come back to what happens once you hire the attendant.

Where the mess actually starts
What a WIP limit is supposed to fix
Making the limit cost something

Where the mess actually starts

The drafts folder isn’t really the problem. It’s a symptom of a missing one step further upstream, at the exact moment an idea shows up.

I get an idea in the shower, or reading someone else’s post, or debugging something that turns out to be interesting for some reason. I write it down in Keep or the notebook, and I feel like I did something productive.

I didn’t.

I moved the idea from my head to a slightly more durable piece of paper, and that’s all it did. Nothing in that step asks whether I’ll ever act on it, or when, or what “acting on it” would even look like.

Getting Things Done splits capture and clarify into two separate stages on purpose: write everything down first with zero evaluation, then come back and turn each vague item into one concrete next action, the way “Bank” becomes “call the bank about the loan.” My system has the first half and skips the second completely.

Experts say unfinished thoughts eat at your focus and hurt you. Sophie Leroy has spent 17 years studying attention at the University of Washington. She calls this attention residue: part of your focus stays attached to an unfinished task even while you’re doing something else entirely, and it gets worse the more unresolved the task feels. A note in Keep with no next action attached is about as unresolved as a task can get.

It’s not costing me time to sit there. It’s costing me a sliver of attention multiplied by how many I have unresolved, every single day, whether I’m looking at it or not.

What a WIP limit is supposed to fix

The standard fix for my unresolved pile is a Personal Kanban, a method built by Jim Benson around two rules. Visualize your work. Limit how much of it can be “in progress” at once.

Benson’s advice is to start at three, and his reasoning isn’t about resilience: three stickies are easy to see, and large to avoid arguments. Below that limit, a fourth idea simply isn’t allowed until something already in progress ships or gets cut. That’s the parking lot with an attendant, in theory: the lot fills up, and the next car waits for a space.

Visualizing helped a little: my first idea of moving all 36 in one place was good. Instead of scattered across two apps and a notebook. I can concentrate on acting on them.

Here’s where my system fell apart. I drew the board but I was not disciplined enough to enforce it. I look at a sticky and either work on it or put it back so I can get back to it later instead of decisively cutting it. That was the issue.

Cars don’t leave a lot because a sign asks nicely; they leave because someone eventually tows the ones that overstayed. My drafts folder had no tow truck, so 36 cars parked there and stayed.

That’s the piece most Personal Kanban explainers skip. The visualization is the easy 20%. Actually enforcing the limit, the part that requires you to give something up before you can start something new, is the other 80%. What it needs is a mechanism, not a whiteboard.

Making the limit cost something

The mechanism I landed on borrows from a tool I already use everyday: git. Before I’m allowed to open a fourth draft, I have to remove one of the three already in “Doing”, and removing one means one of two things. Either it ships (finished, moved to Done, same as any normal task), or I kill it, and killing it means writing an obituary.

Killing a draft looks like this:

git mv drafts/ts7-post.md archive/ts7-post.md
git commit -m "RIP: Microsoft shipped the real writeup before I finished mine"

One line moves the file out of the way. The other line is the part that actually costs something.

That’s the whole mechanism, laid out as a flowchart:

flowchart TD
    A["Doing column is full<br/>3 drafts at the limit"] --> B["New idea shows up<br/>no open slot"]
    B --> C["Pick one to remove<br/>to make room"]
    C --> D["Finish it<br/>ships normally to Done"]
    C --> E["Kill it<br/>git mv to archive/<br/>commit says why"]
    D --> F["Slot opens<br/>new idea can start"]
    E --> F

The RIP is the part doing the actual work, and there’s a reason a public commit message succeeds where a private whiteboard sign failed.

Kahneman and Tversky laid the groundwork for this back in 1979, in a paper that eventually won Kahneman a Nobel Prize: “losses loom larger than gains.” Their actual finding was that most people turn down a fair coin flip for equal stakes, even though it’s break-even on average, because losing feels worse than winning the same amount feels good. If offered $20 on heads or -$20 on tails, most people say no. This is called Loss Aversion.

Deleting a draft silently is a loss you are OK with it most of the time, since nothing marks the moment it happened. Writing git commit -m "RIP: ..." turns the same event into a loss you have to name out loud, in a log you can see anytime. That small, deliberate discomfort is the tow truck that pulls the car who overstayed its welcome.

This step is what makes the three-item limit something I actually respect instead of something I quietly work around.

I recommend wrapping the commands in a bash script or git alias. Easier you make the action the more you will use the step.

Here’s a git alias definition:

git config --global alias.abandon '!f() { local msg="${2:-abandoned $1}"; git mv "drafts/$1" "archive/$1" && git commit -m "RIP: $msg"; }; f "$@"'

Usage:

git abandon some-draft.md "draft angle is thin"

Caveat: Although I have tested this git alias extensively. Make sure to test it on a non-critical code you currently have first. It works on bash on a Mac, Linux might support it too. I would check in WSL2 in windows.

Don’t be tempted to extend the script to recursively run on all contents of a folder. The single draft triage makes it deliberate and makes the step hurt more. The “loss” we are looking for that makes system work.

What’s on the board right now

Three things: this post, a TypeScript piece I still believe in, and a build-tooling draft I give 50/50 surviving the week. One other got the git abandon treatment while I was writing this, with an honest one-line reason.

What makes the trick work is that quitting something finally costs me something I can see.

Cheers!

Accessibility Law World Map

Mon, 10 Aug 2026 10:00:00 GMT

Not for legal advice. Study aide for CPACC exam

An interactive map showing which accessibility instruments apply in which jurisdiction, seeded from Domain III of the CPACC Content Outline. Select a country on the map or a row in the table to see what’s recorded against it. A jurisdiction also inherits everything recorded against its parent (Ontario through Canada, French Guiana through France).

An unmarked country means the dataset has no entry for it, not that no accessibility law exists there.

Data

data.json is the only file meant to be edited routinely: jurisdictions, instruments, and a verifiedOn date marking when the tool last checked the claim against its source, never when the law itself was enacted. Each entry is tagged cpacc-outline (transcribed, unchecked) or primary (checked against the statute or ratification record, with a required source URL).

The basemap (geometry.json) is generated once from Natural Earth 1:110m data via world-atlas, public domain, and never hand-edited.

Notes

There’s no build step and no validation on deploy, so a malformed data.json goes straight to the public URL. A few deliberate omissions from the CPACC seed list: the US signed but never ratified the CRPD, so it isn’t recorded as applying; the UK’s EU Charter of Fundamental Rights entry doesn’t survive Brexit; and Ontario’s dataset entry is the 2001 Ontarians with Disabilities Act, not the better-known 2005 AODA.

Links

Top 5 Git Commands You Should Know for a Better Dev Workflow

Thu, 06 Aug 2026 08:29:00 GMT

My entire git workflow runs on two commands.

git stash when I need to get out of the way.
git checkout when I need to get somewhere else.

No aliases, no muscle-memory shortcuts, no clever bisect story about the regression I hunted down in fifteen minutes. Just stash and checkout for years, because they cover almost everything a normal day asks for.

But “almost” is doing a lot of work in that sentence.

The five commands below are what I’ve started reaching for instead, because each accomplishes tasks I had to manually do in some hacky way.

All of these commands shipped in git for years. You can call each with --help for more comprehensive information.

Consider this a shortlist for anyone else who’s been getting by on two verbs when git actually offers a whole vocabulary.

git switch
git restore
git worktree
git bisect
git reflog

git switch

git checkout does three unrelated jobs: switch branches, restore files, and detach HEAD for a look around.

Git 2.23 split that pile in two, and git switch got the branch-switching half (detaching HEAD came along with it, since it’s a special case of switching).

git switch main
git switch -c fix/leaky-modal

The difference from checkout is that switch only touches branches, so it refuses to guess when you type a filename instead of a branch name, which is exactly the ambiguity that used to eat an afternoon. git switch -- even swaps back to your previous branch, the same trick as cd --.

switch won’t guess what you meant, and after typing it often I’ve come to prefer that certainty. Old habits still work, since checkout isn’t going anywhere, but switch is the one I reach for now.

Use case

Jumping to main to review a teammate’s PR without losing your place on your own branch
Creating a new branch straight from a ticket number, before touching a single file
Bouncing back to whatever you were just on with git switch -, the same trick as cd -

git switch -   # use case 3: bounce back to whatever you were just on

git restore

git restore took the other half of checkout’s job: pulling a file back to how it looked in the index or in some earlier commit.

git restore --staged app.js
git restore --source=HEAD~2 app.js

Where this works best is with --staged flag. It unstages a file without touching your working copy, which used to mean memorizing git reset HEAD -- <file> and hoping you got the argument order right.

git restore operates on three distinct locations in your repository: the Source (where the clean content is pulled from), the Staging Area (index), and the Working Tree (your local files).By controlling —staged and —worktree, you determine which destination gets modified, while —source (-s) dictates where the snapshot is pulled from.

git restore reads like what it does. reset and checkout sounds alien for new users, not for anyone who wasn’t already fluent in git’s plumbing.

Unlike checkout, restore focuses strictly on files, eliminating the risk of accidentally switching branches.

Use case

Undoing edits to a file you weren’t supposed to touch, back to how HEAD has it
Unstaging a file you git added by mistake, without losing the edits sitting in it
Pulling one file back from two commits ago, just to compare an old approach

git restore app.js   # use case 1: undo edits to a file you weren't supposed to touch

git worktree

git worktree is the one that would have saved me the most stashes.

It checks out a second branch into its own folder, fully independent of whatever’s happening in your main one.

git worktree add ../hotfix main

No more stashing a half-finished feature just to hop over and fix something urgent on main (as long as main isn’t the branch you’re currently sitting on, since git refuses to check the same branch out twice). Both branches sit on disk at once, each with its own working tree, so you can build one while testing the other in a separate terminal tab. Run git worktree remove ../hotfix when the fix ships, and the extra folder disappears with it, without any cleanup ritual.

Use case

Fixing something urgent on main without stashing the feature you’re mid-way through
Checking out a teammate’s branch to test their PR, while your own work stays untouched
Running a slow test suite on one branch while you keep coding on another

git worktree add ../review teammate-feature   # use case 2: check out a teammate's PR branch
git worktree list                             # use case 3: keep tabs on trees while one runs tests

It’s also having a moment among people running coding agents, since switching branches mid-session breaks an AI agent’s context, and worktree lets you avoid that collision entirely, and that’s a workflow stash was never built for. The mention of AI is a whole other story we will not tackle here.

git bisect

git bisect finds the commit that broke something, using binary search instead of your eyeballs.

git bisect start
git bisect bad
git bisect good v1.4.0

Confused? git bisect is simply Git running this exact game of “higher or lower” for you. Instead of guessing commit hashes by hand, Git checks out the code at the midpoint, lets you test it, and waits for your answer.

The coolest part of git bisect is that if you have an automated script or unit test that detects the bug (returning 0 for success and non-zero for failure), you don’t even have to test it manually. One gotcha to watch for: if a commit can’t be tested for reasons unrelated to the bug (e.g. it doesn’t build), have your script exit with code 125 instead of a generic non-zero. That tells git bisect to skip the commit rather than mark it “bad,” which would otherwise throw off the search.

Use case

Finding which commit introduced a flaky test, somewhere across weeks of history
Tracking down the exact release that broke a performance benchmark
Locating the merge that quietly reintroduced a bug someone had already fixed once

git bisect run ./benchmark.sh                 # use case 2: automate the hunt for a broken benchmark
git bisect start --first-parent HEAD v1.4.0   # use case 3: focus on the merge that reintroduced a bug

git reflog

git reflog is the safety net under everything else on this list.

git reflog
git reset --hard HEAD@{2}

Every time HEAD moves, whether from a commit, a checkout, a rebase, or a reset you immediately regretted, git writes it down. Nothing is actually gone until git’s garbage collector runs, and that default window is 90 days for anything still reachable, 30 for anything that isn’t.

So the branch you just force-pushed over, or the commit reset --hard seemed to delete, is usually still sitting in your local reflog, waiting for you to point back at it and push again. It’s worth running once, cold, before you ever need it, the same way you’d want to know where the fire extinguisher is before there’s a fire.

Use case

Recovering a branch you just deleted with git branch -D, one keystroke too fast
Undoing a reset --hard that wiped out committed work you hadn’t pushed anywhere
Getting back a commit that seems to have vanished after a rebase went sideways

git reflog                             # reference your safety net
-----
9e8b7c (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: commit: redesign
a7e23c85 HEAD@{1}: commit: new post
1d768e5c HEAD@{2}: branch: deleted recovered-branch
abc1234  HEAD@{3}: commit: redesign 1
8df55c2b HEAD@{4}: commit: fix resolution post
4e284f5c HEAD@{5}: commit: cleanup
...

git branch recovered-branch HEAD@{2}   # use case 1: recover a branch deleted with git branch -D
git cherry-pick abc1234                # use case 3: get back a commit lost after a bad rebase

A habit, not a full workflow

None of this makes stash or checkout obsolete.

I still reach for both most days, and I probably always will. What’s changed is that they’re no longer the only tools on the bench: switch and restore for the everyday moves, worktree for when two branches need to exist at once, bisect for the bug I can’t just eyeball, reflog for the moment I do something I can’t undo any other way.

Pick one from this list and use it on purpose this week.

Start with whichever one solves a problem you already have. If you keep stashing to switch branches, that’s worktree. If you keep losing work to a bad reset --hard, that’s reflog. The rest will follow once one of them earns your trust.

Happy coding!

Four Things Every CMS Image Field Needs

Tue, 04 Aug 2026 08:29:00 GMT

Most CMS image fields do exactly one job.

They take a file, then hand you a single box to type an alt attribute into. That’s fine for one photo on one page, but it falls apart the moment the same photo gets reused as a hero here and a thumbnail there, because a single field can’t hold two different jobs at once.

Three real media libraries make the pattern easy to spot.

Three separate text fields, one saved value each, no per-placement override.

One Description field doing alt text’s job, same everywhere the asset appears.

A hotspot for cropping, but still just one alt text box underneath it.

For the previous examples, the model might look like this,

{
  "asset": "photo-042.jpg",
  "alt": "Team standup, April 2026",
  "description": "Company X development team. Sign below says 'April 2026'"
}

There’s nothing wrong with the JSON model, but for most use cases it’s not enough.

Here’s what I’d want added into the metadata every time an image is uploaded.

Additional metadata that makes an image an “asset”

Alt text that travels with the placement
A field that asks what the image is for, before what to call it
Focal points, not fixed crops
Lazy loading and reserved space, by default

Alt text that travels with the placement

Most media libraries store exactly one alt text per asset, saved once when the file goes in.

That is wrong, because the same image plays a different role every time it gets reused. A product photo can be informative on a listing page and purely decorative as a background texture on a landing page three templates over.

The W3C’s guidance on text alternatives asks for an alternative that serves an equivalent purpose, and purpose is a property of the placement, not the file. The practical fix: store a sensible default on the asset, then let each placement override it.

flowchart TD
    A[Image asset] -->|default alt| B["Team standup, April 2026"]
    A --> C[Used as: blog post hero]
    A --> D[Used as: about-page thumbnail]
    C -->|override: decorative| E["alt is empty"]
    D -->|override: informative| F["Five of us at the whiteboard"]

One asset, one default, two placements that override it, because the image’s job changes, not the file.

That turns alt text from a property of a file into something that describes the relationship between the image and everything around it.

A field that asks what the image is for, before what to call it

As mentioned earlier, most apps show an input for alt text and nothing else. Nothing tells the editor what to describe, so most either skip it or type “image of a person smiling,” which helps no one.

Let’s change it: ask the role first. Decorative? Functional? Informative? The W3C decision tree walks through exactly that triage. Most CMS platforms skip “functional” entirely. In those cases, the UI can be as simple as a “decorative?” checkbox, unchecked by default.

flowchart TD
    A[Upload image] --> B{What is this image for?}
    B -->|Decorative| C[Lock alt to empty, show why]
    B -->|Functional| D[Ask: what action does it trigger?]
    B -->|Informative| E[Ask: what one fact does it add?]

The role picked up top decides what the field asks next. No more blank box, no more guessing.

Pick decorative and the field locks to an empty alt with a short note explaining why.
Pick functional and it asks for the action the image triggers, not its appearance.
Pick informative and it asks for the one fact the image adds that the surrounding text doesn’t already say.

The upload form becomes a two-second decision instead of a blank input that quietly punishes whoever fills it in last.

Focal points, not fixed crops

A photo gets uploaded, and can be used everywhere in the application: a square avatar, a wide hero, a tall card on mobile.

A single manual crop only helps the ratio it was cut for, so the next template either squeezes the subject out of frame or drags a designer back in with scissors.

A “focal point” fixes this at the source. Sanity’s image pipeline stores a hotspot on the image once, then its URL builder crops every requested ratio around that point automatically, with no per-template manual work required (Storyblok ships the same pattern natively; Contentful gets there via a marketplace app, though you still write the crop logic yourself).

flowchart TD
    A["Photo + hotspot (x, y)"] --> B[Square avatar]
    A --> C[Wide hero, 16:9]
    A --> D[Tall mobile card]

Same file, same hotspot, three crops that keeps what is important in frame.

It’s a small piece of metadata, but it’s the difference between an image library that scales with new templates and one that generates a support ticket every time somebody adds a layout.

Lazy loading and reserved space, by default

An <img> tag with no loading attribute and no dimensions does two things wrong at once.

It competes with everything else on the page for bandwidth the instant the page loads.
It leaves no space reserved for itself, so the layout jumps the moment it finally arrives.

Native lazy loading fixes the first problem. Setting loading="lazy" tells the browser to defer offscreen images until they’re actually needed, a single attribute and no library required.

The standard setup has one exception. Whatever loads first (above the fold), often the hero, should stay eager, sometimes with fetchpriority="high", because lazy-loading the Largest Contentful Paint candidate only delays the page’s most important image.

Declaring width and height, or a CSS aspect-ratio, fixes the second problem, because the browser can reserve the right box before a single byte of the image arrives.


<img src="children-playing.png" width="500" height="350" loading="lazy" alt="Kids playing tag on the street" />

flowchart TD
    A[img rendered by template] --> B{Above the fold?}
    B -->|Yes, LCP candidate| C["loading=eager, fetchpriority=high"]
    B -->|No| D[loading=lazy]
    C --> E[width/height or aspect-ratio reserved]
    D --> E

One branch for the hero, one for everything else. Both still reserve their space.

Both belong in whatever template renders the image, generated automatically from data the CMS already has instead of leaving it the browser to fill in later when image is loaded which is a step too late.

What a boring image field buys you

None of these five properties take much code once a platform already has the underlying primitive, a hotspot API, an image CDN, a role-aware form. The harder version is building that primitive yourself, from a blank content model.

The checklist

a default alt with a per-placement override
a role-first prompt
a focal point
lazy loading with reserved space

The image metadata we want

{
  "asset": "photo-042.jpg",
  "altDefault": "Team standup, April 2026",
  "hotspot": { "x": 0.52, "y": 0.38 },
  "variants": ["400w", "800w", "1200w", "1600w"],
  "loading": "lazy",
  "placements": {
    "blog-hero": { "role": "decorative", "alt": "" },
    "about-page-thumbnail": { "role": "informative", "alt": "Our team of five working at the whiteboard" }
  }
}

That’s the all the metadata: four suggestions from this post, one small schema. Just slightly more than the usual filename and alt text.

What they give you is an image pipeline that doesn’t depend on every editor remembering every rule on every upload, because the rules live in the field instead of in someone’s memory.

Happy building!

Typographic Hierarchy Playground

Sun, 26 Jul 2026 10:00:00 GMT

Drag four sliders and watch where your eye lands first.

Visual hierarchy has many levers — layout, color, imagery, motion. This demo isolates the typographic ones. Four sliders control font size, weight, spacing, and contrast; a live preview stage re-renders on every change, so the effect of each lever is visible rather than described.

Every value derives from one base. The headline is a multiple of the body size, subhead and CTA weights are offsets from the headline weight, and the spacing slider drives line-height, block gaps, and button padding together. Pushing a slider doesn’t just scale one thing — it widens or narrows the gap between elements, which is what hierarchy actually is.

Presets

Each preset jumps to the layout it belongs to and explains what it’s demonstrating:

Clear Hierarchy — every lever pulls the same direction; one obvious reading path.
Editorial — the restrained middle ground most documentation sites converge on.
Flat Hierarchy — nearly uniform blocks. No entry point, so the eye searches. Correct for legal text, wrong for an article.
Bold & Cramped — weight still leads, but near-zero spacing collapses the structure.
Low-Contrast Whisper — decent hierarchy hiding a contrast failure. It’s labeled as a mistake: at that setting the body copy fails WCAG AA and reads closer to invisible than subtle.
Size Only — weight and contrast left neutral. It works, but less confidently.
Everything Maxed — every lever at its ceiling. Nothing is emphasized once everything shouts.

The same blocks under three settings — the only variables are size, weight, spacing and contrast

The point of the “bad” presets is that most of them aren’t bad — they’re mismatched. Flat hierarchy is the right answer for a spec sheet and the wrong one for a blog post. Only the low-contrast preset is unambiguously broken, and it’s marked as such.

Layouts changes with Presets

A single article layout would only prove that big headlines beat small ones. Instead the stage swaps between six scenes, each one a place the setting in question actually shows up in production:

Blog article — headline, subhead, body, CTA
Legal / T&Cs list — dense reference text with no single entry point
Notification card — a heavy label winning attention in a tiny footprint
Product update with disclaimer and timestamp — deliberately de-emphasized metadata
Editorial pull-quote — large, light type as its own device
Marketing hero — eyebrow, headline, subhead, dual CTAs

Notes

Contrast is the one lever doing two jobs: it pulls the eye and keeps text legible. That’s why it’s the only slider whose extreme is called out as an accessibility failure rather than a stylistic choice — the same setting that makes a disclaimer feel appropriately quiet, pushed a little further, makes it unreadable on a phone in sunlight.

Built with React and Vite, styled with Tailwind, deployed to GitHub Pages on push to main via GitHub Actions.

Final screen

Here’s the final output. Previous iterations had was text heavy - made the page too busy. The preview screen should be the star. Now we only disclose the information you need for the current state. The levers show explanations on hover or focus.

Playground final design

Links

10 TypeScript Patterns That Make Code Explain Itself

Sat, 25 Jul 2026 08:29:00 GMT

Comments rot. Types don’t - the compiler checks them on every build.

The best comment you’ll ever write is the one you skip, because the code and the already said it. Comments describe intent once, then sit there. Nobody re-checks a comment when the code around it changes six months later. A type gets no such luxury: the compiler re-verifies it on every build. A lying type gets caught. A lying comment just keeps lying, quietly, for as long as nobody notices.

Here are two versions of the same function: one documented by a comment above it, the other by the function definition.

// callback fires with the new value; the type depends on which key changed
function on(eventName, callback) {
   //...
}

Versus,

function on<Key extends keyof Type>(
     eventName: `${Key}Changed`, 
     callback: (value: Type[Key]) => void 
   ) {
   //...
}

Both try to say the same thing. The latter breaks the build the moment it stops being true, because it is checked by something other than a human remembering to update it.

That’s the argument I am presenting in this post. Not “add more types.” Plenty of heavily typed code is still unreadable: all any, as casts, interfaces named Props2. This is narrower: ten specific patterns that turn a signature into something a teammate can read cold, six months out, without opening the implementation, and trust.

Most of these shipped in TypeScript within the last four years, which means plenty of frontend codebases haven’t picked them up yet, not from resistance, just because a feature landing in a release note doesn’t automatically show up in a team’s habits. Some are old TypeScript wearing a sharper technique, not new syntax at all. What ties all ten together is that each one moves a fact a reader needs out of a sentence and into something the compiler is willing to enforce.

1. `satisfies`: keep the specific type, not just the general one

Define a config object and you want TypeScript to check it against a shape like Record<string, RouteConfig>. The old move, a type annotation, works, but it throws away information. Every property on routes now reads as RouteConfig, even though TypeScript knew a second ago that routes.home was specifically { path: "/", exact: true }.

TypeScript 4.9 (November 15, 2022) added satisfies to fix this. It checks an expression against a type without changing the expression’s own inferred type:

type RouteConfig = { path: string; exact?: boolean };

const routes = {
  home: { path: "/", exact: true },
  about: { path: "/about" },
} satisfies Record<string, RouteConfig>;

routes.home.exact; // still known to be `true`, not `boolean | undefined`

Read that signature and you know two things at once: this object matches Record<string, RouteConfig>, and each entry keeps its own literal shape. Hover over routes.home.exact in your editor and it shows true. The annotated version would show boolean | undefined and send you back up to the object literal to check what was actually there: the exact round trip a self-documenting signature is meant to remove. It’s become the default choice for theme objects and default-options objects, anywhere a value needs validating without losing its specifics.

The routes example leaves the key set open: any string key is allowed, as long as its value matches RouteConfig. Just as often, you want the opposite: a closed, specific set of keys, with each value still keeping its literal type. satisfies does both at once:

type IconName = "home" | "settings" | "profile";

const icons = {
  home: { size: 24, viewBox: "0 0 24 24" },
  settings: { size: 20, viewBox: "0 0 20 20" },
  profile: { size: 24, viewBox: "0 0 24 24" },
} satisfies Record<IconName, { size: number; viewBox: string }>;

icons.settings.size; // still known to be `20`, not widened to `number`

// const broken = {
//   home: { size: 24, viewBox: "0 0 24 24" },
//   banner: { size: 32, viewBox: "0 0 32 32" }, // error: "banner" isn't in IconName
// } satisfies Record<IconName, { size: number; viewBox: string }>;

The code above reads as icons can only have the three keys IconName allows (add a banner icon without updating the union and the object literal itself fails to compile¹), and each entry still reports its own literal size, not a widened number. A plain type annotation on icons would have gotten the closed key set but lost the literals; the looser Record<string, ...> from the first example gets the literals but not the closed set. satisfies is the only one of the three that keeps both.

2. `const` type parameters

Pass an array or object into a generic function, and TypeScript widens it: ["a", "b"] becomes string[], not the tuple ["a", "b"]. For years the workaround was as const at every call site, a small ritual that works but adds noise the reader has to filter out.

TypeScript 5.0 (March 16, 2023) moved that behavior into the function definition with a const modifier on the type parameter:

function getNamesExactly<const T extends { names: readonly string[] }>(arg: T) {
  return arg.names;
}

getNamesExactly({ names: ["Milo", "Otis"] });
// return type: readonly ["Milo", "Otis"] — no `as const` at the call site

Whatever you pass keeps its literal shape, guaranteed by the function definition rather than by every caller remembering . It shows up in small custom hooks constantly. A useToggle that should return the precise tuple [boolean, () => void], not a loosely typed array, benefits from this.

3. Discriminated unions with exhaustive checks: a state machine in the type

Loading states are the classic frontend mess: { loading: boolean, data?: T, error?: string }, where loading: true and error: "oops" can both be true at once and nothing complains about it.

A discriminated union makes the states mutually exclusive and names each one:

type FetchState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: string };

function render(state: FetchState<User>) {
  switch (state.status) {
    case "idle": return null;
    case "loading": return "Loading…";
    case "success": return state.data.name; // `data` only exists here
    case "error": return state.error;       // `error` only exists here
    default: {
      const _exhaustive: never = state;     // compile error if a case is missing
      return _exhaustive;
    }
  }
}

The state goes like this:

---
title: Fetch State
---
stateDiagram-v2
  [*] --> idle
  idle --> loading: fetch()
  loading --> success: resolves
  loading --> error: rejects
  success --> loading: refetch()
  error --> loading: retry()

Discriminated unions aren’t new. What makes them documentation, not just structure, is the never check in the default branch. It turns “can loading and error both be true?” from a question raised in a pull request into a question the compiler already answered. Add a fifth state and forget to handle it, and the build breaks at that exact call site. No comment thread does that automatically.

4. `NoInfer`: say which part of the signature is fixed

Generic functions sometimes infer from the wrong argument. Picture a function that picks a default from a known set:

function pickDefault<T>(options: T[], fallback: T): T {
  return options.includes(fallback) ? fallback : options[0];
}

pickDefault(["a", "b"], "c"); // `T` widens to "a" | "b" | "c" — `fallback` shouldn't drive this

TypeScript 5.4 (March 6, 2024) added NoInfer<T> to mark an argument as ineligible for inference:

function pickDefault<T>(options: T[], fallback: NoInfer<T>): T {
  return options.includes(fallback) ? fallback : options[0];
}

pickDefault(["a", "b"], "c"); // now a type error: "c" isn't in "a" | "b"

The feature is small, but it makes the signature honest: options decides what T is, fallback just has to match it. That distinction used to live only in the author’s head, which is exactly how a useReducer helper’s initial-state type quietly gets widened by whatever the reducer’s action union includes. The bug shows up as broken autocomplete three files from the actual cause, and takes real effort to trace back.

5. `using` declarations

Anything needing teardown (a subscription, an AbortController, a mutex) usually ends up in a try/finally block, cleanup logic physically far from setup. TypeScript 5.2 (August 24, 2023) added using declarations, implementing the TC39 Explicit Resource Management proposal:

function subscribeToResize(el: HTMLElement, onResize: () => void) {
  const observer = new ResizeObserver(onResize);
  observer.observe(el);

  using _disposable = {
    [Symbol.dispose]: () => observer.disconnect(),
  };
  // scope ends, disconnect() runs automatically — no finally block needed
}

using sits right next to the resource it disposes of. Compare that to the usual React effect pattern (addEventListener at the top of useEffect, removeEventListener twenty lines later in the cleanup function it returns), where someone reading the code has to hold both ends in their head to confirm they match. using collapses that distance to zero, and it applies just as directly to a plain addEventListener/removeEventListener pair as it does to a ResizeObserver:

function onOutsideClick(el: HTMLElement, onOutside: () => void) {
  const handleClick = (e: MouseEvent) => {
    if (!el.contains(e.target as Node)) onOutside();
  };

  document.addEventListener("click", handleClick);

  using _disposable = {
    [Symbol.dispose]: () => document.removeEventListener("click", handleClick),
  };
  // scope ends, removeEventListener runs with the exact same handler reference —
  // no risk of the add/remove pair drifting out of sync
}

The listener that gets removed is guaranteed to be the same reference that got added, because they’re declared four lines apart instead of on opposite ends of a component. That’s the actual bug using prevents here: a removeEventListener call with a handler that’s been re-created since the matching addEventListener, which silently leaves the old listener attached forever. One setup note before you reach for it: Symbol.dispose isn’t in TypeScript’s default lib, so this won’t compile until your tsconfig.json’s lib array includes "esnext.disposable" (or the broader "esnext"). A self-documenting snippet that fails to build on paste isn’t documenting anything. It’s still early in frontend code specifically, but as more browser and Node APIs pick up Symbol.dispose, expect it to spread past the toy examples.

6. Branded types

TypeScript’s structural typing is usually a feature: two objects with the same shape are the same type. For IDs, that’s a liability. UserId and OrderId can. be both string underneath, so nothing stops you passing one where the other belongs. Branded types fixes that by attaching a fake, compile-time-only tag.

type Brand<T, B extends string> = T & { readonly __brand: B };

type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;

function cancelOrder(id: OrderId) { /* ... */ }

declare const someUserId: UserId;
cancelOrder(someUserId); // error: UserId isn't assignable to OrderId

Read function cancelOrder(id: OrderId) and you know exactly which flavor of string is expected, no comment required. The compiler backs that reading up. It targets one of the most common frontend bug classes there is: a cart reducer that takes a productId where a variantId belongs, both valid strings, no runtime error until the wrong item vanishes from someone’s order. The __brand tag never exists at runtime. It’s erased on compile, so the safety is free.

The same trick fixes a nastier, security-flavored version of the same problem: telling a sanitized string apart from a raw one. dangerouslySetInnerHTML doesn’t care whether the string you hand it has been through a sanitizer. It renders whatever it gets, which is exactly how stored XSS ends up in a React app. Brand the output of your sanitizer, and the type system refuses anything that hasn’t been through it:

type SafeHtml = Brand<string, "SafeHtml">;

declare function sanitize(raw: string): SafeHtml;

function render(html: SafeHtml) {
  return { __html: html };
}

const userComment = "<img src=x onerror=alert(1)>";
render(userComment);          // error: string isn't assignable to SafeHtml
render(sanitize(userComment)); // fine — sanitize() is the only way to produce a SafeHtml

Nobody has to leave a comment reading // make sure this is sanitized first above render. The signature already refuses to compile without it.

7. Template literal types

String-shaped values (event names, route paths, CSS custom properties) are usually just string, which throws away a pattern a reader could otherwise see at a glance. Template literal types let the type carry that pattern. The TypeScript Handbook builds a typed event API this way:

type PropEventSource<Type> = {
  on<Key extends string & keyof Type>(
    eventName: `${Key}Changed`,
    callback: (newValue: Type[Key]) => void
  ): void;
};

declare function makeWatchedObject<Type>(obj: Type): Type & PropEventSource<Type>;

const person = makeWatchedObject({ firstName: "Saoirse", age: 26 });

person.on("firstNameChanged", (name) => name.toUpperCase()); // `name` is `string`
person.on("firstName", () => {});                            // error: not a valid event name

The signature of on documents every valid event name (firstNameChanged, ageChanged) and rejects typos before the code runs. Nobody keeps a comment listing valid events; the type generates the list. The same cross-multiplication trick shows up in community Tailwind tooling, not the framework’s own bundled types: projects like tailwindcss-classnames generate a template-literal union of every valid utility class from a project’s config, so an invalid class string becomes a type error instead of a silent no-op in the browser. For more worked examples of the same trick (role-gated event unions, chaining it with Uppercase/Lowercase string manipulation types), see Exploring TypeScript Template Literal Types (James Milner, April 21, 2021).

8. Generic components without `React.FC`: let the signature describe what it accepts

React.FC handles generics badly, so the React TypeScript Cheatsheet, the community’s de facto reference for this stuff, recommends skipping it in favor of a plain generic function instead:

type DropdownProps<T> = {
  items: T[];
  onSelect: (item: T) => void;
  labelFor: (item: T) => string;
};

function Dropdown<T,>({ items, onSelect, labelFor }: DropdownProps<T>) {
  return (
    <select onChange={(e) => onSelect(items[Number(e.target.value)])}>
      {items.map((item, i) => (
        <option key={i} value={i}>{labelFor(item)}</option>
      ))}
    </select>
  );
}

(The trailing comma after T isn’t a typo: in a .tsx file, <T> alone reads as a JSX tag, so the comma disambiguates it.) Call <Dropdown items={users} onSelect={...} labelFor={...} /> and TypeScript infers T as User for that call, then holds every prop to it. Compare that to the usual fallback when generics feel like too much ceremony: typing items as any[], which compiles but tells a new teammate nothing about what the component supports. Read the generic signature once, and you know Dropdown works with any item type, not just whichever one an earlier version hardcoded.

9. `ComponentPropsWithoutRef`

Wrapping a native element is common: a custom Button around <button>. It’s tempting to grab all its props with ComponentProps<'button'>. But that type includes a ref prop, implying the wrapper forwards it. If it doesn’t, that’s a silent lie in the signature: a caller passes ref, expects DOM access, and gets nothing, because the wrapper never spread it down. The React TypeScript Cheatsheet recommends ComponentPropsWithoutRef for exactly this reason:

type ButtonProps = React.ComponentPropsWithoutRef<"button"> & {
  variant?: "primary" | "secondary";
};

function Button({ variant = "primary", ...rest }: ButtonProps) {
  return <button className={`btn-${variant}`} {...rest} />;
}

If Button later grows a real forwardRef, the type swaps to ComponentPropsWithRef. That one-word change is the whole changelog entry. The props type tells the truth about ref support without a sentence of prose, and it tells that truth at every call site at once, which a comment on the component definition alone never could.

10. Type predicates

TypeScript narrows types automatically inside an if block, but that narrowing doesn’t survive a function call by default.

type User = { id: string; email: string };
type MaybeUser = User | null | undefined;

function greet(u: MaybeUser) {
  if (u != null && typeof u.email === "string") {
    console.log(u); // u is User
    return;
  }

  console.log(u); // u is MaybeUser 
}

TypeScript forgets what it just verified. Pull the check into isValidUser(x) and a type predicate return type the type gets narrowed down:

type User = { id: string; email: string };
type MaybeUser = User | null | undefined;

function isValidUser(u: MaybeUser): u is User {
  return u != null && typeof u.email === "string";
}

function greet(u: MaybeUser) {
  if (isValidUser(u)) {
    console.log(u); // u is User
    return;
  }

  console.log(u); // u is { null | undefined }
}

The u is User return type is a documented promise: call this, get true back, and the compiler treats u as User from there. A plain boolean can’t make that promise. And the same signature composes free with Array.prototype.filter, so users.filter(isValidUser) narrows the whole array to User[] in one line. That’s where this pattern earns its keep most in frontend code: validating a list of maybe-null form entries or API results before rendering them.

Wrapping up

None of these patterns replaces comments outright. Types document shape and contract: what a value can be, what a function accepts, what states exist. They say nothing about why: why this endpoint retries three times and not five, why this component exists instead of reusing an older one, why one edge case matters to one particular customer. That’s still a comment’s job, and a good comment explaining a business reason is worth keeping right where it is.

What these ten patterns do is narrow the space where a comment is your only option. Each one pushes a fact out of a sentence that can drift and into a signature the compiler checks on every build. The compiler doesn’t get tired and doesn’t skip a re-check because the deadline is close. That’s the actual advantage over code comments.

satisfies performs the same excess-property check on object literals that a normal type annotation would. TypeScript’s own team has discussed this exact mechanic (whether an unlisted key like "banner" should error) in microsoft/TypeScript#52999.↩↩

Stop Writing Novels in Your Gallery's Alt Text

Thu, 16 Jul 2026 08:29:00 GMT

How to write alt text for image galleries, and when to reach for captions or long descriptions instead.

A photography portfolio has forty images. Someone decides each one deserves justice, so every thumbnail gets a 60-word description of light and mood. It feels generous. It’s a tax.

A screen reader reads a page top to bottom. The user weighs each item, then decides to skip it or not. So forty rich descriptions become forty small essays the user has to sit through before they reach anything they can act on. Sighted visitors scan the grid in two seconds. The assistive-tech user gets the audiobook. That isn’t equal access.

The instinct is a good one. You wanted no one left out. But equal access means equal speed, not extra words.

More is not better. Both alt text and galleries have rules, and long descriptions have a home that’s rarely the alt attribute.

What an image gallery is, and why we reach for one

An image gallery is a set of related images shown together as a group: a grid of thumbnails, a swipeable carousel, a masonry wall, a lightbox you click into. The point isn’t any single picture. It’s the collection.

Galleries earn their keep when one image can’t carry the load: a photographer shows a body of work, not a headshot, a shop shows a product from six angles, a listing shows every room, a recipe shows each step. The images are the content, and browsing them is the task: scan the set, compare a few, open the one that matters.

A gallery exists so people can move through images and choose. Anything that slows that down (a paragraph of alt text on every thumbnail included) fights the reason you built it.

What alt text is for

Ask why the image is here, not what it looks like. The W3C alt decision tree runs the same check: does the image carry meaning the page would lose without it, is it a link or button, or is it decoration? WCAG 1.1.1 asks for a text alternative that serves an equivalent purpose, not a transcript of pixels.

That sorts images into roles. Decorative images get an empty alt so assistive tech skips them; the W3C says so plainly: use alt="". A clickable thumbnail is functional, so its alt names the action. An informative image gets one line for the fact it adds.

Keep that line short. WCAG sets no character limit, but NN/g’s guide to writing alt text says hold it to about a sentence, put the key words first, and cut the rest. Need a paragraph? The alt attribute is the wrong box.

Why galleries make it worse

A mouse gives random access: you point at the one image you want. A screen reader is sequential. NN/g makes the point in “Alt Text: Not Always Needed”: when alt text is useless for common tasks, “images bring confusion, not clarity.” Multiply that by forty and you get a novel no one chose to open.

Most sites err the other way. The WebAIM Million 2025 report found 18.5% of home-page images had no alt text, and about a third had missing, questionable, or repeated alternatives. So both sins are common: nothing, or far too much. Galleries pull you toward too much.

Rules for an accessible gallery

A gallery is a structure, not a pile of <img> tags. Structure is where most galleries fail.

Group the images. The W3C Groups of Images tutorial shows the pattern: wrap the set in a <figure>, caption the whole group, and give each item its own short alt and caption.

<figure role="group" aria-labelledby="gallery-cap">
  <figcaption id="gallery-cap">Baler, three mornings in the rainy season.</figcaption>

  <figure>
    <img src="day1.jpg" alt="Grey surf under a low, flat sky.">
    <figcaption>Day one. Overcast.</figcaption>
  </figure>

  <figure>
    <img src="day2.jpg" alt="Sun breaking through cloud onto the break.">
    <figcaption>Day two. Clearing.</figcaption>
  </figure>
</figure>

The alt stays short and carries the one visual fact. Mood and date live in the visible <figcaption>, where everyone reads them.

Treat clickable thumbnails as controls. A thumbnail that opens a lightbox is functional, so its alt names the destination (the W3C’s Functional Images guidance is clear on this). The full image gets the description, because that’s what the user is about to open.

<a href="sunrise-full.jpg" class="thumb">
  <img src="sunrise-thumb.jpg" alt="View full image: Sunrise over Baler">
</a>

Make it work without a mouse. Every thumbnail link must take keyboard focus, the focus ring must stay visible, and a lightbox must trap focus while open, return it on close, and close on Escape (the ARIA dialog pattern spells this out). A lightbox built from non-focusable <div>s locks keyboard and screen reader users out.

Don’t repeat yourself. If the caption already says “Sunrise over Baler,” empty the alt. Saying it twice just makes the user hear it twice.

Alternatives to alt text

The alt attribute is one tool. For anything past a sentence, reach for these instead.

Visible captions

<figcaption> is read by assistive tech and seen by everyone, yet most teams still default to a hidden alt. Let the caption carry the description and it does what an overstuffed alt can’t: it shows that description to sighted users too. When the caption covers the image, empty the alt. One source of truth.

Page copy

Often the strongest move is to write the thing in the body. The W3C Complex Images tutorial notes that long descriptions also help people with low vision, cognitive differences, and limited subject knowledge, none of whom reach text trapped in an attribute.

A linked long description

When an image really needs a paragraph (a detailed diagram, an annotated map), give it a short alt that names it, then put the full description on the page and tie the two together with <figure>/<figcaption>.

`aria-describedby` for prose

For a plain-text description, link it by id:

<img src="peacock.jpg"
     alt="Male peacock head"
     aria-describedby="peacock-desc">
<p id="peacock-desc">
  The male is metallic blue on the crown, with a fan-shaped crest of
  bare-shafted feathers tipped in blue-green. A white stripe sits above
  the eye and a white crescent below it.
</p>

One catch the W3C flags: aria-describedby flattens its target into one run of text. Screen readers drop the headings, lists, and tables inside it. Use it for prose, not structured content.

Skip autopilot AI alt text

AI auto describers have their place, but think long and hard before you reach for one. Auto-describers drop a paragraph on every image: the pile-up this whole post is trying to prevent. They describe pixels, not purpose, and they can’t know why you chose the image. Accessibility vendor Silktide reports that in its own testing, screen reader users can spot AI-written alt text: technically accurate and practically useless. Draft with these tools if you must, then edit hard.

The checklist

Decorative image: empty alt (alt="").
Clickable thumbnail: alt names the action. Describe the image where it opens, not on the thumbnail.
Informative image: one short, front-loaded sentence, or empty alt if a caption already covers it.
Description longer than a sentence: move it to a caption, page copy, or a linked description.
Wrap the set in <figure>, caption the group, let each item caption itself.
Unplug the mouse and tab through. Focus stays visible. The lightbox opens, traps focus, and closes on Escape.

Accessibility is counted in tasks finished, not words written. Write less in the alt attribute. Build more into the page.

References

An alt Decision Tree (W3C WAI)
Groups of Images (W3C WAI)
Understanding SC 1.1.1 Non-text Content (W3C WCAG 2.2)
Alt Text: Not Always Needed (Nielsen Norman Group)
How to Write Good Alt Text (Nielsen Norman Group)
The Downsides of AI Alt Text (Silktide)

Research, Plan, Execute, Learn: The Agent Loop I Wish Someone Had Drawn Me First

Fri, 10 Jul 2026 08:29:00 GMT

“What goes into the agent before it runs decides what comes out.” That’s a lesson I keep relearning.

A confession: give me a coding agent and a task, and I want to type the task and hit go. Research and planning feel like chores. There’s a wire running straight from “I have an idea” to “build it,” and I take it almost every time.

That wire is the red dashes in the picture up top. It feels fast. It rarely is.

Four phases make agent-assisted coding work: Research, Plan, Execute, Learn. The phase everyone drops is the one that pays off most, and it pays off because it compounds: Learn feeds each session’s lesson back into the agent, so every task you finish makes the next one cheaper. Skip it and you’re stuck re-explaining the same things every morning. None of the rest depends on your tool either. It works in a terminal, an editor, or a browser tab.

The shortcut nobody admits to

Agents are eager. Give one a task and it starts producing. That’s the appeal, and the trap. Producing something and producing the right thing are two different events.

People who get good results build a process around the agent instead of firing prompts at it. Better prompts alone don’t do it. Anthropic’s guidance says it plainly: explore first, then plan, then code, so you don’t solve the wrong problem. Tyler Burleigh calls the same shape Research, Plan, Implement, Review. The Tweag handbook starts with exploration too.

Four names, one idea. Split the thinking from the typing. Then close the loop.

1. Research: read before you write

Research is the cheapest phase, and the first I skip. It’s just this: before the agent changes anything, make it read.

Point it at the real files. Have it trace how the current code works. Ask what you’d ask a senior engineer in their second week: how does auth work, where do sessions live, what’s the pattern for a new endpoint. You don’t want code yet. You want the agent’s context filled with your codebase so it stops guessing.

When an agent doesn’t know your code, it fills the gap with the average of every codebase it has seen. That average produces the subtly-wrong output. Research swaps the average for your specifics.

One guardrail: research sprawls. Tell an agent to “look into” something and it reads two hundred files and chokes. Scope it. “Read src/auth and the session middleware” beats “understand the app.” If your tool has a separate research context, use it, so the reading doesn’t crowd out the work.

2. Plan: a plan is a contract, not a vibe

Once the agent has read enough, make it write a plan before code. On the page, where you can argue with it.

A good plan names the files it will touch, the shape of the change, what’s out of scope, and how you’ll know it worked. That last part carries the weight. A plan that ends with “here’s how we verify it” is a contract. A plan that ends with “then I’ll implement it” is a vibe.

I treat the plan as the real work. Get it right and the code is mechanical. Get it wrong and no clever code saves you. You get a finished-looking solution to the wrong problem, which beats a broken one at hiding.

A skeleton I reuse:

## Goal
One sentence. What does "done" mean?

## Files to change
- src/foo.ts — add X
- src/foo.test.ts — cover the logged-out case
- src/good.example.ts - if doing similar job give it an example

## Out of scope
- Don't touch the billing flow
- No new dependencies without asking

## Verification
- `npm test` passes, including the new logged-out case
- Manual: hit /api/foo while signed out, expect 401

One section tells the agent what not to do. Agents drift toward the easiest thing to build. Boundaries on the plan stop the drift before it starts.

3. Execute: let it check its own work

Execute is the fun part, the glowing node we all rush. It holds the one habit that matters most: give the agent a check it can run, and never take “done” at face value.

An agent will tell you it’s finished, and sound sure. That sureness is generated text, not a status report. Anthropic’s docs name it the ”trust-then-verify gap”: the model writes a plausible implementation, declares success, and the edge cases quietly fail. In one documented run, an agent declared success on 19 of 45 tasks whose hidden tests still failed (42%), because it ran only the visible tests and never checked the rest. The model isn’t lying. “Looks done” is just part of what it writes, pass or fail.

So close the loop. Hand it a check it runs itself: tests, a build, a linter, a script that diffs output. Now it works, runs the check, reads the failure, and fixes it, instead of handing you a guess. Ask for evidence, not the adjective:

Implement the plan. Write a test for the logged-out case.
Run the suite and paste the actual output. Don't tell me it passed — show me.

Sometimes I add a Steps section when I want things done in order, with the check built in beforehand, like this:

## Steps
1. Create unit tests for X first
2. Implement X - make sure unit test passes
3. ...

A second failure earns its own line: invented dependencies. A 2025 USENIX Security study found the coding models it tested recommended packages that don’t exist about one in five times on average (near 21% for open-source models, closer to 5% for commercial ones), and the fake names repeat. That gap spawned an attack called “slopsquatting”: someone registers the invented name, ships malware, and waits for the next agent to invent it again. When your agent reaches for a package you’ve never heard of, check that it’s real before you install it. Compiling isn’t the same as safe.

Verification lives inside Execute, not after it.

4. Learn: the phase everyone skips

Learn is the phase missing from most versions of this loop, and it’s the one that matters most. After the work ships, feed the lesson back.

Every session teaches you how the agent behaves in your code. It grabs the wrong test helper. It forgets you use ES modules. It rebuilds a utility you already have. Most people notice, sigh, fix it by hand, and let the lesson evaporate. Next session, same fix.

Learn is where you write the correction somewhere the agent reads every time: a rules file, a CLAUDE.md, a conventions doc, whatever loads at the start of a session. A few lines do it:

# Conventions
- Use ES modules (import/export), never require()
- Reuse `formatMoney()` from src/util — don't roll your own
- Tests: no mocks past the system boundary

Only this phase compounds. Research, Plan, and Execute improve this task. Learn improves every task, because you’re teaching the agent your codebase instead of re-explaining it each morning. Skip it and you stay on the treadmill, making the same three fixes forever.

One caveat: don’t let the rules file swell. A bloated doc is one the agent ignores, because the rule that matters hides under twenty that don’t. For each line, ask the question I took from the docs: would cutting this make the agent mess up? If not, cut it. Learn means adding the lessons that count and pruning the rest.

The whole loop in one picture

---
title: Research, Plan, Execute and Learn loop
---
flowchart TD
    R[Research<br/>read before you write] --> P[Plan<br/>a contract, not a vibe]
    P --> E[Execute<br/>verify, don't trust]
    E --> L[Learn<br/>write the lesson down]
    E -."done" is not evidence.-> E
    L -.feeds the next task.-> R

The dashed line from Learn back to Research is the whole game. It’s a loop that tightens each lap rather than a pipeline with an end, because every lap leaves a rule that shortens the next Research phase.

The straight red wire from the picture, idea straight to Execute, is still there. It always will be. For a one-line typo, taking it is right. The skill is knowing when the task is big enough that the shortcut becomes the long way around.

Wrapping up

None of this is tool-specific, and none of it is new. It’s the discipline good engineers already use on themselves. The agent just makes skipping it cost you faster. The loop is what turns a fast demo into something you’d sign your name to.

Now excuse me. I have a rules file to prune. (Spoiler: it’s too long. It’s always too long.)

Happy building.

The ts-jest to Vitest Switch Is Lower-Risk Than You Think

Fri, 10 Jul 2026 04:29:00 GMT

Every frontend team has the ticket. “Evaluate moving off ts-jest.” It rots in the backlog for a year. Nobody picks it up, because everyone assumes a test-runner swap means rewriting hundreds of files.

It doesn’t. Vitest ships a Jest-compatible API on purpose, so the switch stays cheap. The official migration guide is short, and most of it covers edge cases you may never hit. The common path is one config file, a find-and-replace, and a green run. The risk you picture is bigger than the risk that’s there. The reward, faster tests, is the part you keep ignoring.

Why ts-jest got slow

Start with the pain, since it’s the reason to move.

ts-jest is a Jest transformer. On every run it hands each file to the TypeScript compiler to type-check and transpile. That work is correct and thorough and slow. The compiler resolves types across your whole project before one assertion fires.

The usual fix proves the point. You reach for isolatedModules: true, which skips type-checking and compiles each file alone. On our own codebase, turning it on in tsconfig cut a full-suite run from 16 minutes to about 3. But look at what you did. You switched off the type-checking that justified ts-jest’s cost, and you gave up features like const enum. So a tuned ts-jest setup runs no type-checking in tests and still trails the alternative. That is the bottleneck.

Vitest attacks it differently. It reuses Vite’s pipeline, which strips types with esbuild. esbuild is written in Go and transpiles TypeScript far faster than the TypeScript compiler — benchmarks put it anywhere from several times to tens of times quicker, depending on the project. It strips types instead of understanding them. You add no separate transform, no Babel preset. TypeScript works because the build tool already reads it.

flowchart LR
  subgraph tsjest["ts-jest run"]
    A[Test file .ts] --> B[TypeScript compiler]
    B --> C[Type-check + transpile]
    C --> D[Jest executes test]
  end
  subgraph vitest["Vitest run"]
    E[Test file .ts] --> F[esbuild strips types]
    F --> G[Vitest executes test]
  end

One pipeline does less, and it skips the costly part.

It’s compatible on purpose

Teams treat Vitest as a foreign framework. It isn’t.

The API matches Jest. describe, it, test, expect, beforeEach, afterEach — same names, same shapes. Matchers like toBe, toEqual, and toHaveBeenCalledWith carry over. Set one flag, globals: true, and tests that call describe and expect without imports keep running. The globals setting exists so you skip adding an import to every file on day one.

That flag is why this is find-and-replace, not a rewrite. Your test bodies mostly hold. The plumbing around them moves.

What actually changes

Three things move. None is scary.

First, the config. You write a small vitest.config.ts. If you build with Vite, you extend what you have.

// vitest.config.ts
import { defineConfig } from 'vitest/config'
 
export default defineConfig({
  test: {
    globals: true,        // keep Jest-style describe/expect without imports
    environment: 'jsdom', // for component tests; omit for pure Node code
  },
})

Second, jest becomes vi. Vitest names the mocking object vi. This is most of your diff, and it’s mechanical.

// before (ts-jest / Jest)
jest.mock('./api')
const spy = jest.fn()
jest.useFakeTimers()
jest.spyOn(obj, 'method')
 
// after (Vitest)
import { vi } from 'vitest'
vi.mock('./api')
const spy = vi.fn()
vi.useFakeTimers()
vi.spyOn(obj, 'method')

Find jest., replace with vi., add the import or skip it with globals: true. A codemod clears a large suite in one sitting.

Third, a few named quirks. The guide lists them. jest.requireActual becomes vi.importActual. jest.setTimeout(5000) becomes vi.setConfig({ testTimeout: 5000 }). The jest.Mock type becomes an imported Mock from vitest.

Run it in an afternoon

flowchart TD
  A[Install vitest + remove ts-jest] --> B[Add vitest.config.ts with globals: true]
  B --> C[Find/replace jest. with vi.]
  C --> D[Swap package.json test script to vitest]
  D --> E[Run the suite]
  E --> F{All green?}
  F -->|Yes| G[Done]
  F -->|No| H[Fix named gotchas from the guide]
  H --> E

Install Vitest and drop ts-jest and its presets. Add the config. Replace jest. with vi.. Point the test script at vitest. Run it. Fix the short list of documented differences below.

The failure mode isn’t “my tests are broken forever.” It’s a green run after a handful of named fixes.

The Gotchas Worth Knowing

A few differences bite if you don’t know them. Two cause silently wrong tests, not loud errors — so here’s the exact shape.

mockReset: Jest empties the implementation. Vitest restores the original you passed to vi.fn(impl).

const fn = vi.fn(() => 'real')
fn.mockReset()
fn()            // Vitest → 'real'   |   Jest → undefined

Module mock factories: In Jest the factory returns the default export. In Vitest it must return an object with each export named, including default.
```
// Jest
jest.mock('./greet', () => 'hello')

// Vitest
vi.mock('./greet', () => ({ default: 'hello' }))
```
Timers & legacy callbacks: Vitest drops Jest’s legacy fake timers and the done callback. Rewrite those as async/await or a Promise.
Version floor: Vitest 4 needs Vite 6 and Node 20 or newer, per the migration guide. Check your runtime first.

Each is a line in a checklist. Keep the guide open during the swap and clear them as they appear.

The bottom line

The reason to move is speed. ts-jest either type-checks and crawls, or skips it and still trails esbuild. esbuild strips types in Go, not JavaScript — on a large suite that’s the difference between a coffee break and a glance. The reason you can move is compatibility: Vitest copied Jest’s API, so your tests survive the trip.

The ticket is smaller than its reputation. You rename jest to vi, add one config file, and work a short list of gotchas. Do it on a quiet afternoon. Then keep the faster feedback loop all year.

Your Alt Text Is Not the Problem — Your Images Are

Sun, 05 Jul 2026 08:29:00 GMT

The mistake I kept making

A confession: early in my career, my images shipped with no alt text at all. If an image mattered, I gave it a visible caption and moved on (I thought alt was a box the SEO people cared about). Screen reader users got silence, or file names — “hero underscore final underscore v three dot jaypeg.”

A caption doesn’t substitute. It describes the image for everyone, but leaves the <img> itself unnamed, and it can’t say whether that image is a link, a chart, or wallpaper. I didn’t know that then. I’m not sure I’d heard of a screen reader.

The usual penance, once you learn better, is to overcorrect: describe everything, decorative swooshes included. That’s the opposite failure. The W3C Images Tutorial says decorative images should get a null alternative — alt="" — so assistive technology skips them. Silence where there should be words, then words where there should be silence.

The lesson took years to sink in. The hard part of image accessibility isn’t writing the description. It’s deciding whether one should exist and what job it must do. Wording comes last. Classification comes first. Most of us skip to the last step.

The question that fixes most alt text

Before you touch the alt attribute, ask: what does this image do on this page?

Not “what does it show”. A photo of a woman smiling at a laptop shows that. What it does might be nothing (stock decoration), navigation (it links to her profile), or information (the article is about her).

Same pixels. Three alt texts. One is empty.

WCAG Success Criterion 1.1.1 requires text alternatives that serve “the equivalent purpose” of the content. Purpose, not appearance. The spec has said so since WCAG 1.0 in 1999. We still write alt text that describes what marketing exported from Figma.

The three types of alt text: decorative, functional, informative

The WAI Images Tutorial sorts images into categories. Three cover almost everything you’ll ship: decorative, functional, informative.

Decorative — visual polish, no information. Empty alt, move on:

<!-- A wave divider between page sections -->
<img src="wave-divider.svg" alt="">

alt="" tells screen readers to skip it. Omitting the attribute is worse — MDN warns some screen readers then announce the file name. That’s how users end up hearing “wave hyphen divider dot ess vee gee”.

Functional — the image is a control. Describe the action, not the picture:

<!-- Bad: describes the pixels -->
<a href="/print"><img src="printer.svg" alt="An icon of a printer"></a>

<!-- Good: describes the job -->
<a href="/print"><img src="printer.svg" alt="Print this page"></a>

The alt text becomes the link’s name. “An icon of a printer” tells users what your designer drew. “Print this page” tells them what Enter does. Only one helps mid-task.

Informative — the image carries meaning the text doesn’t. Convey it, briefly:

<p>Attach the strap using the D-ring on the left side.</p>
<img src="strap-dring.jpg"
     alt="The strap threaded through the D-ring, folded back and clipped">

The alt completes the instruction. It doesn’t repeat the paragraph, and it doesn’t start with “Image of” — the screen reader announces that already.

A fourth case: complex images — charts, infographics — where a short alt can’t hold the data. Give a short alt plus a long description nearby:

<figure>
  <img src="q2-signups.png"
       alt="Bar chart of Q2 signups by month. Full data follows.">
  <figcaption>
    Q2 signups: April 1,240 · May 1,610 · June 2,380
  </figcaption>                                                                                                                      
</figure>

The alt names the chart; the figcaption carries the numbers.

A self-test from MDN: read the alt text aloud with the paragraph before it. If the pair conveys what a sighted reader gets, stop. If it repeats or leaves a hole, keep editing.

The alt text decision tree

The W3C’s alt decision tree formalizes this. I run a simplified version on every <img>:

flowchart TD
    A["New <img>. What does it DO?"] --> B{Is it purely
decoration?}
    B -- Yes --> C["alt=''
(empty, not missing)"]
    B -- No --> D{Is it inside a link
or button?}
    D -- Yes --> E["Describe the ACTION
alt='Print this page'"]
    D -- No --> F{Does it carry info
the text doesn't?}
    F -- No --> C
    F -- Yes --> G{Too complex for
a sentence?}
    G -- No --> H["Short alt conveying
the meaning"]
    G -- Yes --> I["Short alt + long description
(figure, table, or link)"]

No box says “describe what the image looks like”. Appearance matters only when appearance is the information — a painting on a gallery site, a rash on a medical page, a mockup in a design critique.

Why AI-generated alt text fails

In 2026, every CMS and editor plugin will generate alt text for you. The models describe pixels well. I use them. But the first three branches of the tree above have nothing to do with pixels.

Is the image decorative? Depends on the page. Functional? Depends on the markup around it. Does it add information? Depends on the text. A model looking at a cropped file sees none of that. It answers the one question it can — “what’s in this picture?” — which is the last question that matters, and often the wrong one.

Researchers have documented the failure. Silktide found that screen reader users can tell when alt text is AI-generated: accurate descriptions that convey no purpose or function. The American Foundation for the Blind puts it plainly: description without intent isn’t access.

Picture a CMS plugin writing alt="A person holding a credit card near a laptop" for a checkout help page. Accurate. Useless. The image is a button opening the payment FAQ. Screen reader users get stock-photo narration and no hint the thing is clickable. Arguably worse than no alt at all, because it sounds finished.

My rule: AI drafts wording on informative images after I classify them. It never decides the role. That’s a design decision, and it belongs to someone who can see the whole page (in every sense).

Missing alt text by the numbers (WebAIM 2026)

WCAG has required text alternatives since 1999, so you might expect the problem solved. The 2026 WebAIM Million report — an automated audit of the top million home pages — found:

16.2% of home page images lack alternative text (about 10.8 per page)
45% of those sit inside links — links with no name
Home pages average 66.6 images, nearly double eight years ago
Missing alt text stays among the six error types making up 96% of detected failures, unchanged for seven years

The second bullet is the bad one. A missing alt on decoration is noise. A missing alt on a linked image is a door with no handle — the screen reader announces a raw URL, or nothing. Half our missing-alt problem is the highest-stakes category with the easiest fix.

We ship more images than ever and classify fewer. The tools improved. The thinking didn’t.

Describe less, decide more

Alt text quality is decided before you write a word. Classify first: decorative, functional, informative, complex. The decision tree makes the decision for you. Wording is the easy 20%.

Next PR with images: don’t ask “does this have alt text?“. Ask “does this alt text know what the image is for?“. The first is a checkbox. The second is accessibility. Otherwise you’re hanging masterpieces in the gallery and labeling them IMG_4032.JPG.

Happy (inclusive) building!

Unplug Your Mouse - One Year On, Accessibility Widgets Still Don't Work

Sat, 27 Jun 2026 08:29:00 GMT

The European Accessibility Act turns one tomorrow. It took force on 28 June 2025. For many teams it was the first hard deadline they had ever faced for this work: e-commerce, banking, transport, ticketing, and telecom, across all 27 EU countries.

A year on, the same reflex persists, and it still doesn’t work. A team bolts an accessibility widget into the corner of the page: a floating icon that swears it fixes accessibility in one click. It does not. Here is why, and here is what I do instead.

Accessibility widgets (often called “overlays”) are plugins installed on websites to add functionality via overlay buttons. They frequently promise compliance with regulations (such as WCAG or EAA) with a single line of code. - www.hintogroup.eu

Most accessibility lives in your markup and your CSS, not in a script you paste before </body>. A widget can recolor text or grow the font. It won’t build a focus order your page never had. It can’t teach a <div onclick> to behave like a <button />.

The Nielsen Norman Group has said this for years: accessibility is a mindset, not a checklist, and a bolted-on widget is not enough. The only real test is to put disabled users in front of the design. So drop the sticker. The best test costs nothing but a little pride.

Unplug your mouse

Testing keyboard accessibility starts the same way every time: pull the mouse out. Use your own site with the keyboard. Tab forward, Shift+Tab back, Enter and Space to act, Esc to close.

You will find the broken parts in a minute. A modal you can tab into but never out of. A dropdown the keyboard skips. A “button” that ignores Enter because it is a <span> in costume. The mouse hid all of it.

This is no fringe group. Some people drive the keyboard because their hands need it, some because a screen reader drives it for them, some because it is faster. Marieke McCloskey set the three rules a decade ago, and they still hold: keep focus visible, let the Tab key reach every control, and let users skip past long menus.

This is the check I run as I tab:

flowchart TD
    A[Press Tab] --> B{Can I see where focus landed?}
    B -- No --> F[Fail: focus indicator missing or hidden]
    B -- Yes --> C{Did focus reach every control in a sane order?}
    C -- No --> G[Fail: unreachable or illogical focus order]
    C -- Yes --> D{Can I activate it with Enter or Space?}
    D -- No --> H[Fail: not a real interactive element]
    D -- Yes --> E{Can I get back out? No keyboard trap?}
    E -- No --> I[Fail: keyboard trap]
    E -- Yes --> J[Pass this element]

Three of those boxes catch most of what I find. None need a widget. They need markup.

The dull CSS that does the work

WCAG 2.2 shipped on 5 October 2023 and added nine new criteria. Most are boring, deliberately. They turn good intentions into numbers you can check.

Focus first

This is still the worst line of CSS on the web:

/* Please don't. This blinds every keyboard user. */
:focus {
  outline: none;
}

People strip the ring because it looks untidy on a mouse click. Don’t delete it: show it to the people who need it. The :focus-visible pseudo-class fires only when the browser judges a ring would help, which means keyboard use and not a stray click (MDN).

/* Quiet for mouse clicks, loud for keyboard users. */
:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

Keyboard users get a clear ring. Mouse users see nothing on click. Nobody is stranded. WCAG 2.2 even put numbers on it: Focus Appearance wants a ring large and sharp enough to spot, and Focus Not Obscured bars a sticky header from hiding it.

Now hit targets. Target Size (Minimum) asks for at least 24 by 24 CSS pixels, or enough space that a 24px circle on each does not touch its neighbor. This is for everyone who has missed a tiny close button.

/* Small icon button? Give it a real target. */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

Twenty-four pixels is the floor, not the goal. I go bigger for the main action. But it is a number, and a number is something a team can ship.

Use the element, not the costume

Using the right HTML element is the cheapest win there is, older than any guideline. A real <button> takes focus, fires on Enter and Space, names itself to a screen reader, and joins the tab order for free. A <div> in costume gives you none of that until you wire up tabindex, key handlers, and an ARIA role by hand. You will miss one.

// A costume. Skips the tab order, ignores Enter, silent to screen readers.
<div className="btn" onClick={save}>Save</div>

// The real thing. Keyboard, focus, and semantics included.
<button type="button" className="btn" onClick={save}>Save</button>

Same pixels. Worlds apart for anyone off the mouse. I have deleted many clever components by swapping in the plain element that already worked.

Why this beats the fine

The EAA carries real penalties, and within days of the deadline French groups sent legal notices to big retailers. The fines are a good reason to care. They are not my reason.

My reason is, for example, a potential buyer who will reach a checkout screen. She drove the page by keyboard, reached the “Pay” button, pressed Enter, and nothing happened. It was a <div>. She tabbed back, tried again, then quietly closed the tab. No error, no fine, no record. Just a sale that never happened and a person told, without a word, that the site was not built for her.

That is what the widget hides. Roughly one in five people lives with a disability, and many more are neurodiverse. Build for them and the work pays everyone back: the parent holding a baby and a phone, the commuter in glare, the person whose trackpad just died. A focus ring helps the power user. A 24-pixel target helps every thumb. Here the edge case makes the center better.

One in five people lives with a disability - cdc.gov

The widget swears it skips all this. It can not. Your keyboard shows you the truth in a minute, and three lines of CSS fix most of what it shows.

Start tomorrow morning

The Act turning one is a fine nudge. Unplug the mouse, tab through your top page, and note what breaks. Remove outline: none in :focus selectors. If you must touch outline, use :focus-visible so the ring still appears for the people who rely on it. Give your small buttons 24 real pixels. Replace one fake button with a real one. Small, dull, and it stays fixed. That beats a sticker.

Happy (inclusive) building!

Automating Accessibility Audits With AI

Sat, 28 Jun 2025 10:30:00 GMT

“Standards evolve, user needs are wildly diverse, and manual audits can feel like searching for a semicolon in a haystack.”

Let’s be honest: accessibility is one of those things that everyone agrees is important, but somehow always ends up on the “we’ll get to it later” list. (Right next to “refactor that one function” and “actually read the WCAG guidelines.”) But here’s the thing: the web is for everyone. Or at least, it should be.

Accessibility: Not Just a Checkbox

If you’re a developer or DevOps engineer, you know the drill. New features, tight deadlines, and somewhere in the mix, a vague hope that your site works for everyone—including folks with disabilities and neurodivergent users. But accessibility isn’t just a legal checkbox or a last-minute scramble. It’s about building digital experiences that don’t leave anyone behind.

And yes, it’s tricky. Standards evolve, user needs are wildly diverse, and manual audits can feel like searching for a semicolon in a haystack. (Spoiler: it’s always missing.)

Enter AI: Your New Accessibility Sidekick

Manual audits are thorough, but let’s face it—they’re slow, expensive, and often get pushed to the end of the sprint. That means:

Real user issues slip through the cracks.
Fixes get more expensive the longer you wait.
Teams get frustrated, and so do users.

Automating accessibility audits brings some real superpowers:

Continuous feedback: Catch issues early and often, not just before launch.
Scalability: Big sites and frequent updates? No sweat.
Empowerment: Developers, designers, and content creators get actionable insights—no PhD in accessibility required.

AI: Not Just for Chatbots and Cat Memes

Traditional tools like axe-core or Lighthouse are great at catching the obvious stuff—missing alt text, color contrast fails, or headings that are more lost than your car keys. But nuance? Context? The wild variety of user needs? That’s where generative AI and large language models (LLMs) step in.

By understanding content, intent, and user journeys, AI can:

Flag ambiguous or misleading link text (like the classic “click here”—about as helpful as a screen door on a submarine)
Suggest more descriptive alt text for images
Detect cognitive overload in layouts or copy (because nobody likes a wall of text)
Simulate diverse user experiences, including those of neurodivergent users

Tools That Actually Help (And Don’t Just Add More Tabs)

1. Microsoft Accessibility Insights + Copilot

Accessibility Insights for Web is a browser extension for Chrome and Edge that helps you test and fix accessibility issues in web applications. It now teams up with GitHub Copilot, so you get AI-powered suggestions for fixing accessibility issues right in your codebase.

What it’s used for:

Automated and guided accessibility testing: Run quick or comprehensive checks and get step-by-step guidance to resolve issues.
Visualizing and fixing issues in real time: Instantly see accessibility problems highlighted on your site and learn how to fix them.
Getting AI-powered code suggestions for accessibility: Use Copilot to receive smart recommendations and code fixes as you develop.

How to integrate Accessibility Insights and Copilot in your workflow:

Install Accessibility Insights for Web as a browser extension in Chrome or Edge. Get it here. Docs.
Review the issues found by Accessibility Insights. Each issue comes with detailed guidance and links to relevant documentation. How to interpret results.
Open your code editor (e.g., VS Code) with GitHub Copilot enabled. Install Copilot. As you address flagged issues, Copilot can suggest code changes—such as adding ARIA attributes, improving semantic HTML, or fixing color contrast. Copilot guides.
Use Copilot’s inline suggestions to quickly implement recommended fixes. You can ask Copilot for accessibility-specific help (e.g., “Add accessible label to this button”) or let it auto-complete as you code. For example, in TypeScript/React:

// Before
<button>Submit</button>

// Copilot suggestion for accessibility
<button aria-label="Submit form">Submit</button>

Re-run Accessibility Insights in your browser to verify that the issues are resolved. Repeat the process for continuous improvement.
Integrate both tools into your CI/CD pipeline by using Accessibility Insights CLI and Copilot’s code review features, ensuring accessibility checks and fixes are part of every pull request. See CLI usage.

This workflow helps you catch, fix, and prevent accessibility issues early—making accessibility a seamless part of your development process.

2. Google Lighthouse + Gemini

Google Lighthouse is an open-source tool for auditing web page quality, including accessibility. When paired with Gemini, Google’s large language model, it can:

Summarize accessibility issues in plain English
Suggest improvements tailored to your site’s content and audience
Predict the impact of changes on real users

What it’s used for:

Quickly assess your site’s accessibility with automated reports and scoring, helping you spot and prioritize issues. (Adapted from Lighthouse docs)
Get plain-language explanations and actionable recommendations for each issue, powered by AI.
Integrate with Chrome DevTools or your CI/CD pipeline for seamless, repeatable checks.

How to integrate Google Lighthouse and Gemini in your workflow:

Install Google Lighthouse as a browser extension or use it directly in Chrome DevTools. For more, see the official docs.
Run an audit and review the Lighthouse report. Each finding comes with explanations and links to best practices. Accessibility audits with Lighthouse.
Bring in Gemini (or your favorite LLM) for deeper insights: Copy the Lighthouse report or specific issues and ask Gemini to break them down, explain, or suggest improvements tailored to your site’s content and audience. Gemini overview.
Put the AI’s advice into action. For instance, Gemini might spot a vague button label and suggest something more descriptive in your React code:

// Before
<button>Click here</button>

// Gemini’s suggestion for clarity (adapted from accessibility best practices)
<button aria-label="Download report">Download</button>

Run Lighthouse again to see if your fixes did the trick and if your accessibility score is climbing. Keep iterating for steady progress.
Level up your workflow by automating audits in CI/CD. Use Lighthouse CI to run checks on every deployment or pull request, and let Gemini help you interpret the results. Lighthouse CI docs.

Feature descriptions and workflow steps paraphrased and adapted from Lighthouse documentation, Lighthouse CI docs, and Gemini overview.

This workflow lets you combine automated audits with AI-powered explanations, making accessibility improvements more practical and less mysterious.

3. Axe by Deque

Axe is a suite of accessibility testing tools built on the open-source axe-core library. Here’s what’s in the toolbox:

Axe DevTools: Browser extensions for automated and guided accessibility testing
Axe Auditor: Manual testing for full WCAG coverage
Axe Monitor: Continuous monitoring and reporting
Axe-core API: Integrate accessibility checks into your automated test suites

What it’s used for:

Run quick automated scans or deep-dive manual audits, so you’re covered for both fast checks and full compliance reviews.
Keep tabs on your site’s accessibility over time and make sure you’re always in line with the latest standards.
Build accessibility checks right into your development and deployment pipelines for peace of mind.

Feature list and descriptions paraphrased and adapted from Axe documentation and axe-core GitHub.

Workflow: AI-Driven Accessibility in Action

Curious how all these tools and AI-powered features come together in practice? Here’s a quick overview of what a modern, automated accessibility workflow can look like. The following steps show how you can integrate accessibility checks, AI review, and team collaboration into your development process—making accessibility a seamless part of building and shipping great web experiences:

Continuous Integration: Set up your CI pipeline to run automated accessibility checks on every pull request using tools like axe-core, Accessibility Insights, or Lighthouse.
AI Review: Use Copilot or Gemini to review flagged issues, generate code suggestions, and explain the impact. See Copilot coding agent with MCP.
Team Collaboration: Share AI-generated reports with designers, developers, and content creators for holistic improvements.
User Testing: Simulate diverse user journeys with AI to uncover edge cases and cognitive barriers (because everyone deserves a smooth ride).

Looking Ahead: The Human + AI Partnership

AI is not a silver bullet (if only!). Some issues—like the emotional tone of content or the lived experience of neurodivergent users—still need a human touch. But by automating the repetitive and technical parts of accessibility, AI frees up your team to focus on what matters most: creating delightful, inclusive experiences for everyone.

Wrap-Up

The future of web accessibility is bright—and a little more automated. By embracing AI-powered audits, we can build a web that’s not just compliant, but truly welcoming to all. As you explore these tools, remember: accessibility is a journey, not a checkbox. Let AI handle the heavy lifting, and let your team’s creativity and empathy shine.

Happy coding, and happy (inclusive) building!

“Accessibility allows us to tap into everyone’s potential.”

— Debra Ruh

Ten Common Typescript Discriminated Union Examples

Sat, 08 Feb 2025 07:07:00 GMT

In this post we explore the marvelous world of Discriminated Unions in TypeScript.

Discriminated Unions are a way to combine types that have a common discriminant (usually a literal property) so that TypeScript can narrow down which type it’s dealing with. Let’s explore the 10 patterns that make these unions your coding sidekick!

If you’re like me and learn better with sample code, then I won’t go into explaining what Discriminated Unions are anymore—let’s get straight to some examples.

1. Basic Discriminated Union

	type Circle = { kind: "circle"; radius: number };
	type Square = { kind: "square"; side: number };
	type Shape = Circle | Square;
	
	function getArea(shape: Shape): number {
	  switch (shape.kind) {
	    case "circle":
	      return Math.PI * shape.radius ** 2;
	    case "square":
	      return shape.side * shape.side;
	  }
	}

This pattern shows the simple yet powerful use of a common property (kind) to determine how to process each shape. This is the most common pattern for using Discriminated Unions. When your object has a common property that helps “discriminate” the “shape” of the object. Other common properties used are “type”, “status”, “responseType” etc.

2. Exhaustiveness Checking


	function assertNever(x: never): never {
	  throw new Error("Unexpected object: " + x);
	}
	
	function getArea(shape: Shape): number {
	  switch (shape.kind) {
	    case "circle":
	      return Math.PI * shape.radius ** 2;
	    case "square":
	      return shape.side ** 2;
	    default:
	      return assertNever(shape); // Compiler will remind you if a new type is forgotten.
	  }
	}

This example ensures every case is handled. The assertNever function throws an exception if you introduce a new type that you have not defined. Use this pattern to safeguard against “oops” moments and future-proof your code as your union grows.

3. Handling Different API Responses


	type APISuccess = { kind: "success"; data: any };
	type APIError = { kind: "error"; errorCode: number; message: string };
	type APIResponse = APISuccess | APIError;
	
	function handleResponse(response: APIResponse): string {
	  switch (response.kind) {
	    case "success":
	      return "Data: " + JSON.stringify(response.data);
	    case "error":
	      return `Error ${response.errorCode}: ${response.message}`;
	  }
	}

By using a discriminant (kind), this pattern cleanly separates successful responses from errors. Imagine it as the Avengers assembling to tackle any API threat—each with its own special move!

4. Handling Success and Failure


	type Success<T> = { status: "success"; data: T };
	type Failure = { status: "failure"; error: string };
	type Result<T> = Success<T> | Failure;
	
	interface ChatResponse extends ApiResponse {}
	
	function MyComponent(props: Readonly<IMyComponentProps>) {
		const [result, setResult] = useState<Result<ChatResponse>>({ status: "failure", error: "" });
		
		function fetchData(): void {
		  // Simulating an API call ...
		}
		
		function handleFetchResult(response: Result<ChatResponse>) {		
			setResult({ ...response });
		}
		
		if (result.status === "success") {
		    return <SuccessfulFetchView data={result.data} />;
		}
		
		return <FailedFetchView error={result.error} />;
	}

*Here we use Discriminated Unions to elegantly handle both success and error outcomes and render the appropriate view.

5. Representing UI States


	type LoadingState = { status: "loading" };
	type LoadedState<T> = { status: "loaded"; data: T };
	type ErrorState = { status: "error"; message: string };
	
	type UIState<T> = LoadingState | LoadedState<T> | ErrorState;
	
	function getMessageText<T>(state: UIState<T>): string {
	  switch (state.status) {
	    case "loading":
	      return "Loading...";
	    case "loaded":
	      return `Data: ${JSON.stringify(state.data)}`;
	    case "error":
	      return `Error: ${state.message}`;
	  }
	}

This pattern leverages discriminated unions to manage different UI states. It’s like switching between your favorite streaming channels—each state brings a different vibe to the screen!

6. Navigating Nested Data Structures


	type TreeNode = { type: "node"; value: number; children: TreeNode[] };
	type LeafNode = { type: "leaf"; value: number };
	
	type Tree = TreeNode | LeafNode;
	
	function sumTree(tree: Tree): number {
	  if (tree.type === "leaf") {
	    return tree.value;
	  } else {
	    return tree.value + tree.children.reduce((sum, child) => sum + sumTree(child), 0);
	  }
	}

This pattern shows how discriminated unions can power recursive data structures, like summing values in a tree. (Pattern adapted from the TypeScript Handbook.)

7. Managing Different Events


	type ClickEvent = { type: "click"; x: number; y: number };
	type KeyPressEvent = { type: "keypress"; key: string };
	type Event = ClickEvent | KeyPressEvent;
	
	function handleEvent(event: Event): void {
	  switch (event.type) {
	    case "click":
	      console.log(`Clicked at (${event.x}, ${event.y})`);
	      break;
	    case "keypress":
	      console.log(`Key pressed: ${event.key}`);
	      break;
	  }
	}

Discriminated unions here allow you to handle different events with precision. (Pattern adapted from the TypeScript Handbook.) It’s like having a remote control that instantly switches channels—only, in this case, you’re switching event handlers!

8. Representing Validation States


	type ValidForm = { status: "valid"; values: Record<string, any> };
	type InvalidForm = { status: "invalid"; errors: Record<string, string> };
	
	type FormState = ValidForm | InvalidForm;
	
	function processForm(state: FormState): string {
	  switch (state.status) {
	    case "valid":
	      return "Processing form with values: " + JSON.stringify(state.values);
	    case "invalid":
	      return "Errors: " + JSON.stringify(state.errors);
	  }
	}

This pattern utilizes discriminated unions to clearly represent whether a form is valid or not. It’s like having a Hogwarts sorting hat that instantly tells you if your form is magical (valid) or a muggle (invalid)!

9. Handling Multiple Plugin Types


	interface BasePlugin {
	  type: string;
	}
	
	interface LoggerPlugin extends BasePlugin {
	  type: "logger";
	  logLevel: "debug" | "info" | "warn" | "error";
	}
	
	interface AuthPlugin extends BasePlugin {
	  type: "auth";
	  provider: string;
	}
	
	type Plugin = LoggerPlugin | AuthPlugin;
	
	function initializePlugin(plugin: Plugin): void {
	  switch (plugin.type) {
	    case "logger":
	      console.log(`Logger initialized with level ${plugin.logLevel}`);
	      break;
	    case "auth":
	      console.log(`Auth plugin using ${plugin.provider}`);
	      break;
	  }
	}

Here, discriminated unions help manage various plugin types within an architecture. Think of it as assembling your own tech-savvy Justice League where every plugin has a specific role to play!

10. Streamlining Command Execution


	type CreateCommand = { type: "create"; payload: User };
	type UpdateCommand = { type: "update"; id: number; payload: User };
	type DeleteCommand = { type: "delete"; id: number };
	
	type Command = CreateCommand | UpdateCommand | DeleteCommand;
	
	function execute(command: Command): DbResponse {
	  switch (command.type) {
	    case "create":
	      return db.query(sql, {payload: command.payload }); 
	    case "update":
	      return db.query(sql, {id: command.id, payload: command.payload }); 	
	    case "delete":
	      return db.query(sql, {id: command.id}); 	
	  }
	}

*In this pattern, discriminated unions simplify the handling of different commands, ensuring that each command is executed correctly. It’s akin to having a Swiss Army knife of commands, ready to take on any task with precision! *

When to use Discriminated Unions

Do you have multiple related types that share common fields?
Do the types have a clear “kind” or “type” discriminator?
Do you need type safety in switch or if-else checks?

If you answered yes to all the questions, use a Discriminated Union. If you answered no to any of the questions, you may need to consider a different pattern.

Wrap-Up

Discriminated unions are another TypeScript feature to help you write robust, maintainable code. By clearly defining each possible state or variant, you can avoid runtime errors and make your code self-documenting, just like a well-curated 80’s playlist. As you experiment with these patterns, explore further resources like the TypeScript Handbook on Advanced Types and TypeScript Deep Dive to continue your journey.

Happy coding!

Using Container Queries to Make a News Layout

Fri, 24 Feb 2023 08:07:00 GMT

When I hear media query I think about a bottle filled with liquids that don’t mix (e.g. oil and water). The content(water/oil) will assume the shape and size of the container (bottle). I will not bore you with “science-sy” stuff but some predetermined properties of these liquids define how they exist inside the bottle. Oil is lighter than water so it floats etc. But ultimately they are governed by their single container. You can’t make the oil shaped as a globe float inside of the region of water occupies. What if you have a glass sphere to contain the oil? Then made it so it is suspended inside the bottle? That is what container queries do for CSS. Container queries become the smaller glass container inside the bottle. Then your content can then follow the rules of that smaller container instead of depending on the rules of one bottle. This will allow you more flexibility in styling layouts.

Container queries enable you to apply styles to an element based on the size of the element’s container. If, for example, a container has less space available in the surrounding context, you can hide certain elements or use smaller fonts.

MDN: Css Container queries

For years, developers like me have asked for a better way of styling website elements, especially on where or how they are contained in a site. Media queries have their uses but they don’t help much if you want to make reusable independent components. Media queries are better suited for setting up page layouts. The dream is to have a UI element - drop it anywhere on the site and it reconfigures itself based on where and how the container is configured. Because you are using the container dimensions and not the viewport you can more accurately bake in the styling of a reusable element based on what available space the parent element has and not how wide the browser viewport is showing. Imagine the glass sphere in the bottle analogy earlier. Oil is the UI element and the glass sphere is the parent container. The UI element will not care how the rest of the page is configured. Only on how its parent is configured. To achieve this in the past developers resorted to JavaScript. You know how I hate adding more scripts to a page. Sometimes the convenience does not justify the added library size.

This is where container queries come in. They are the solution we’ve been asking for all along.

Some technical explanations and code patterns in this post are based on the MDN documentation on CSS Container Queries.

How to do container queries

There are two steps to doing container queries.

Make a wrapper element and setup container property
Define styles in container query

1. Make a wrapper element and setup `container` property

To start using container queries, we first define a container or wrapper element with a container type.

.section-container {
  container: my-container / inline-size;
}

In the CSS above, we are using the shorthand way of defining a container. The first value is the name we want to identify the container query the second value is the container type. It is equivalent to the CSS below.

.section-container {
  container-name: my-container;
  container-type: inline-size;
}

2. Define styles in container query

A container query is similar to that a media query.


@container my-container (min-width: 800px) {
  // style here
}

These are the very minimum things you need to learn to use container queries. There are other things to know container units - I will leave that for a later post.

The experiment

To understand container queries better I did made an experiment. My idea was to create a news layout where the content is a bunch of cards with the same markup and content. Depending on how the container is configured the news cards will show in different ways.

I made a wireframe with the following:

Full-width hero card on top
A medium-sized news card
A news list with multiple content
A grid with multiple contents

I’ve configured the cards in the wireframe to show in different styles. For the full-width top section “stage”, I want the card to show as a hero element. In the medium “stage”, the card would look like a wide news card. With the news list stage, I placed multiple cards that will show as a text list with no images. In the final grid “stage”, I wanted to show a news grid with multiple cards.

Also not to forget, on smaller screens(e.g. mobile) all the cards will show as one column card grid.

Remember that all these cards have the same markup. Imagine you have a server-side rendered(SSR) endpoint that returns an array of cards with similar markup sorted by descending date(e.g news post). Then you just drop all this content in different containers until you fill the layout. No need to cherry pick the data and render to different locations.

Check the pen here for a demo.

What I learned

Doing the experiment I learned a few things. It is easy to start using container query after you get through the initial confusion in learning to think in containers. Once you get used to thinking in container queries you’ll be amazed. I was thinking it would be great if we had this a decade ago when we were building our layout editor.😀

You are not limited to querying width. If we use container-type: size we can use the container height when defining a container query block. Using height opens up more possibilities when doing layouts. For example, I made the news list text wall by using the height of the container to tell the news card to only render the text and hide the images. In some way, I made my news cards smarter. Before the container query era, I had to do some complicated CSS class combinations to achieve the same thing or worse yet use JavaScript.


.stage {
  container-name: stage;
  container-type: size;
}

@container stage (width > 768px) and (height = 1000px) {
  .card {
    width: calc(100% / 3);
  }
}

Wrapping up

Container queries are another great tool in a web developer’s toolbelt. I would recommend spending some time learning the basics and how it interacts with layout-specific CSS like flexbox and grids. I would also suggest spending time learning the differences between container types and how to use container units.

Cheers!

Automatically generate skip buttons to improve accessibility

Fri, 17 Feb 2023 12:07:00 GMT

Another common accessibility tool is the skip button. It comes in different forms. It would sometimes be smartly included in the design or hidden until needed. Whatever form skip buttons allow users to bypass sections of content to make it easier to navigate websites. Adding ways to bypass content is part of the WCAG accessibility guidelines: Bypass blocks.

Problem

I recently got a complaint from a screen reader user that some UI/widget on a client site was terrible to navigate through. Widely used screen readers like JAWS, NVDA or Voiceover have a feature to navigate based on common semantic tags like headings (h1, h2, h3, etc.) or links. In the case of the broken UI control, it has quite a lot of headings and links in the content. So when the screen reader tried to use the navigation shortcut for headings. It still included the headings in the UI control.

Solution

To fix the issue we had two options. One(1) is to re-work the widget to remove the headings and use links instead. This required quite a bit of refactoring and testing. The effort is not worth the benefit. The second(2) option is to add skip buttons. We opted for the second option.

Now when the screen reader or keyboard user navigates through the widget they will first encounter the skip button which they can activate to jump to the next section or ignore to continue through the widget. For the previous solution, we hard-coded the skip buttons as part of the design.

The demo below shows code to generate skip buttons. The way it works is the developer provides a list of tags and selectors you want to skip. These can be blocks of content or sections that are quite difficult to navigate through like navigation, forms, etc.

let nodesToSkip = document.querySelectorAll( " header .demo-header, aside .links, section" );

Next, the code loops thru these sections and adds skip buttons. When the button is focused and activated( using the Enter key ), the focus jumps to the next section or focusable element. When you navigate to the last section there is no skip button cause there is no section to jump to next.

In this demo, I opted to focus on sections but it is easy to tweak the code to focus on the next focusable element like a button or input control instead. As a bonus, whenever a section has a heading(h2) or title, the generated button text will use the heading/title text to further improve recognition.

Wrapping up

Skip buttons are a powerful tool for improving accessibility. They provide greater control over users’ experience navigating through websites. Feel free to reuse the code provided to generate skip buttons in your projects. Your users and customers will thank you.

CSS Snippets I Use 90% of The Time - Part 2

Thu, 09 Feb 2023 12:22:00 GMT

This is part 2 of CSS snippets I used 90% of the time post.

As promised this is second part of CSS styles I commonly used with my projects. If you are going to think of a rule I’d say this is my 80/20 rule for CSS. I have a common set patterns when designing and building sites. The rest depends on what the client needs.

The list this time are of interactive and UI elements used on of my recent projects.

Centering an element in a box

There are a lot ways to center an element but in 8 out 10 projects I use only two styles when I need to center an element in a box. I keep two styles because it depends on the circumstance.

Using flex

I use this if I can use display:flex mostly because flexbox is well “flexible”. Most of the time I need to center more than one item so wrapping is a concern. Flexbox is very good with this.

// source CSS Tricks
.parent {
   display: flex;
   justify-content: center;
   align-items: center;

   // define dimensions of the box
   width: 100vw;
   height: 100vh;
} 

.child {
   //...
}

<div class="parent">
   <div class="centered-child"> Child element </div>
</div>

This will center an element inside the box. Another good thing about using this technique is your element is in the normal document flow except when adding order property to child elements. If you are concerned with accessibility this is very important to remember. Using order to arrange flex elements is discouraged because they break the reading order of the elements.

Absolute positioning

I use this next style if I can’t use flexbox and/or I need dynamic element like a modal. Another reason I might use this style is if I can’t touch the parent style since the all the positioning style is in the child element.

// Source CSS Tricks
.parent {
  position: relative;
}

.modal {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);

  //...
}

<div class="parent">
  <div class="modal">
    This is a modal
  </div>
</div>

Overlay

Overlays are another UI pattern I use a lot. They are great for preventing mouse input where you don’t want it, giving contrast to an element, and goes great with modals. Before I needed to use javascript to add the overlay as we want to know when the modal is visible in the parent. I accomplish that by adding a .has-modal class in the parent when modal is visible.

<div class="parent has-modal">
  <div class="modal">
    This is a modal
  </div>
</div>

.parent {
  position: relative;
}

.modal {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);

  //...
}

// overlay
.parent.has-modal:before  {
  content: ' ';
  position: absolute;
  top: 0;
  left: 0;
  width: 100vw;
  height: 100vh;
  background-color: rgba(0,0,0,0.3);
}

Now we can do away with that and use :has selector.

<div class="parent">
  <div class="modal">
    This is a modal
  </div>
</div>

// overlay
.parent:has(.modal):before  {
  content: ' ';
  position: absolute;
  top: 0;
  left: 0;
  width: 100vw;
  height: 100vh;
  background-color: rgba(0,0,0,0.3);
}

Check out the demo to see the styles in action.

Note that the overlay only prevents mouse input to the elements underneath the overlay. It will not stop keyboard users from tabbing into elements. This is not good for accessibility. We can fix this looping through the elements that need to be ignored and add inert.

//e.g

let focusableElements = Array.from(document.querySelectorAll(':not(.modal) a, :not(.modal) button, input, :not(.modal) [contentEditable],:not(.modal)  [tabindex]:not([tabindex=-1])'));

focusableElements.forEach(el => {
el.setAttribute('inert','');
});

Truncate text

There will be times you want to truncate a large amount of text. It could be to improve a design and optimize the space or just to indicate you have more information and you want to signal the user to dig some more. Whatever reason its good to have a handy CSS class you can use to do the truncation for you.

Below is the markup we are going to use for truncation classes.

 <div class="truncate-demo">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum laoreet a nisi quis lacinia. Pellentesque sit amet mauris ac nunc pellentesque dignissim a at quam. Aliquam pulvinar nulla sit amet ligula malesuada luctus a et mauris. Maecenas in mauris massa. Proin sit amet tellus a ipsum hendrerit varius. Sed eleifend odio vitae magna gravida mollis. Aenean massa ipsum, vehicula in enim gravida, tempus tempus arcu. Nullam porta nisi vitae sem fringilla, ut tristique neque dapibus. Cras commodo nunc non elit lobortis, at pretium elit efficitur. Etiam condimentum varius rutrum.</div>

.truncate-demo {
  width: 100%;
  border: 2px solid #d3d3d3;
  padding: 8px;
}

One-line truncation

For one line truncation, the trick is use the CSS property text-overflow. Whether its one-line or multiline, you need to first set the boundaries of the text container, in the case of a onle truncate its the width of the container. After that set make sure nothing bleeds out of the container by setting overflow:hidden.


.one-line {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

.truncate-demo {
  width: 100%;
  border: 2px solid #d3d3d3;
  padding: 8px;
}

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum laoreet a nisi quis lacinia. Pellentesque sit amet mauris ac nunc pellentesque dignissim a at quam. Aliquam pulvinar nulla sit amet ligula malesuada luctus a et mauris. Maecenas in mauris massa. Proin sit amet tellus a ipsum hendrerit varius. Sed eleifend odio vitae magna gravida mollis. Aenean massa ipsum, vehicula in enim gravida, tempus tempus arcu. Nullam porta nisi vitae sem fringilla, ut tristique neque dapibus. Cras commodo nunc non elit lobortis, at pretium elit efficitur. Etiam condimentum varius rutrum.

Multiline truncation

For multiline truncation its a bit different but the same principle. For this we need to use line clamping.

.three-line {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow: hidden;
}

Fullscreen background image

Fullscreen background images have been a constant mainstay in my projects. The trend started in the late 2000s, popularized by Apple’s website featuring the Iphone. Nowadays, most websites especially those in marketing, creative or business websites will have a fullscreen image background or a large image style as “above the fold”. Be careful with this depending on the image you may impact the speed at which your site loads.


body {
  background-image: url("path/to/background.png");
  background-size: cover;
  background-repeat: no-repeat;
  background-position: center center;
  height: 100vh;
  margin: 0;
  padding: 0;
}

The key part here that enables fullscreen images is background-size:cover. Setting cover to background-size resizes your image to “cover” most of the container without stretching or skewing the image.

Wrapping up

Having a quick reference for common frontend work is a good way to improve your workflow. Hope these list of CSS styles will be of use to you. I recommend installing a snippet library so its available when you need it.

Five common Javascript mistakes I am guilty of

Thu, 02 Feb 2023 07:07:00 GMT

Errors in code are normal. That is why we have a whole branch of the IT industry dedicated to quality assurance and testing. Javascript is the easiest programming language to learn, but it is also the easiest to get wrong. Javascript is a very forgiving programming language. As a result, Javascript code can be prone to errors.

In this post, I will list some of the mistakes I’ve encountered coding in Javascript.

Misunderstanding "const"

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable—just that the variable identifier cannot be reassigned.

MDN

One mistake I keep repeating is forgetting that defining an object with const does not prevent the contents from mutation. Const only prevents the variable from being reassigned.

  const i = 1
  const myObject = {a: 1, b: 2}
  const myArray = [0, 1, 2, 3]

  i = i + 1 // TypeError: Assignment to constant variable 

  myObject.a = myObject.a + 1 // {a: 2, b: 2};
  myObject = {a: 2} // TypeError: Assignment to constant variable

  myArray[0] = 2 // [2, 1, 2, 3]
  myArray = [2,3] // TypeError: Assignment to constant variable

This means you can update the contents of an object or array. This is legal because we are not acting on the reference. This is more confusing than problematic. As you can just change the declaration with let.

Rather than keep making this mistake and avoid confusion, I use let to define variables all the time even for magic values. I think const is not worth the confusion it causes.

Strict vs Loose Equality

As a javascript developer, I have learned to always use strict equality (===). Most javascript programmers will tell you to follow that rule. If you come from a C-based language like C# or C++, you are probably more familiar with double equals(==) than strict equality. I am guilty of this mistake, especially when switching the coding context between the frontend(Javascript) and the backend(C#). The mistake is easily remedied but hard to trace especially in a massive codebase. The difference is that (loose) equality (== and !=) will try to force type conversion when comparing two values. Sometimes this is not what we want.


let foo = 1;
let bar = '1';

foo == bar // true
foo != bar // false

This is not the case for strict equality(=== and !==). Strict equality checks will never apply type conversion and test the two values directly. If two values are not of the same data type the test fails.


let foo = 1;
let bar = '1';
let der = 1;

foo === bar // false
foo !== bar // true

foo === der // true
foo !== der // false

As I mentioned in the beginning always use strict equality, unless you have a good reason to use loose equality. An example of that is if you are pulling data from some source and just want to know that a value exists without testing the data type. You can use loose equality in those cases, but be careful and make sure you know what you’re doing.

Example

Here’s an example component I made in React where I had an issue with equality.


function AwesomeComponent(props) {
  const [buyOption, setBuyOption] = React.useState(0);

  function onChange(e) {
    setBuyOption(e.target.value);
  }

  return <React.Fragment>
  <label>
    <input name="buyJeansStyle" type="radio" value={0} checked={buyOption === 0} onChange={onChange}> Style 1
  </label>
  <label>
    <input name="buyJeansStyle" type="radio" value={1} checked={buyOption === 1} onChange={onChange}> Style 2
  </label>
  </React.Fragment>
}

At first glance, everything works fine. Then I tested the result, I found I can’t change my choice. Clicking on a radio button did not set the button. I tried everything I can think of to fix the component. I refactored a few times but to no avail. It took me forever to find the issue. I finally realized that the issue is the equality test for the checked prop on the radio buttons. I was acting on the assumption that the values assigned, value=0 and value=1, are integers when the state is set, but I was mistaken. The event handler was setting the string version of the values. Meaning e.target.value where strings, ‘0’ and ‘1’, and not the integer equivalents. So strict equality was always false for both checks causing the bug. Here is where the loose equality check is a better option.

  <label>
    <input name="buyJeansStyle" type="radio" value={0} checked={buyOption == 0} onChange={onChange}> Style 1
  </label>
  <label>
    <input name="buyJeansStyle" type="radio" value={1} checked={buyOption == 1} onChange={onChange}> Style 2
  </label>

Now the component works but to follow the “always use strict equality” rule I refactored again by casting the event value into an integer value.


  function onChange(e) {
    setBuyOption(parseInt(e.target.value));
  }

Both fixes accomplish the same thing. Your choice will depend if you need to keep the resulting value in a specific data type or not.

Assignment vs Equality

I feel foolish whenever I commit this next error.

Like the difference between loose equality and strict equality operators, the difference between assignment and equality is a single equal (=) sign. Thus it is easy to mistake using the former when you meant to use the latter. Take for example the following code.



  let results = [
    { loanAmount: 1000, interest: 0.02 ... }
    { loanAmount: 40000, interest: 0.05 ... }
    { loanAmount: 1000, interest: 0.03 ... }
    { loanAmount: 10300, interest: 0.09 ... }
    //...
  ];

  let loansBelowAThousandCount = results.filter( item => item.loanAmount = 1000 ).length;

Without knowing all the contents in results, you can guess what the code wants to accomplish. I wanted to get the number of loans with loanAmount equal to 1000. I assume I would get a number less than the results count but instead got the same number as the results array every time. Looking at this simple code there will be some who would immediately find the issue. Do you see my error?

I mistakenly use the assignment operator instead of the equality test. Inspecting the array from results.filter( item => item.loanAmount = 1000 ), I get the same items but with the loanAmount equal to 1000.


results.filter( item => item.loanAmount = 1000 ) 
/*
[
    { loanAmount: 1000, interest: 0.02  ... }
    { loanAmount: 1000, interest: 0.05 ... }
    { loanAmount: 1000, interest: 0.03  ... }
    { loanAmount: 1000, interest: 0.09 ... }
    //...
  ];
*/

Once I’ve verified the issue I corrected the code below.


let newArray = myArray.filter( item => item.a == 1 ); // or better yet `===`

Since I know the loanAmount is always a number I can get away with the loose equality check.

It is a very simple mistake to recognize but if it is in a big codebase with a lot of moving parts, it is quite difficult to see.

For ... in vs For ... of

If you want to loop through an array you may be familiar with this pattern.

let myArray = [0, 10, 31, 20];

for(let i=0; i < myArray.length; i++) {
  let item = myArray[i];
  console.log(item);
}

// 0 
// 10 
// 31
// 20

What I hate about the structure above is that i is only used to get the array value. If variable i has some other purpose on the loop it would have been fine but with this pattern it’s overkill. There are better ways to loop through an array like Array.forEach etc.

For...of is the fairly new iterator control structure we can use to replace the for(;;) loop. Using for...of we can refactor the code above.


for(let item of myArray) {
  console.log(item);
}

// 0 
// 10 
// 31
// 20

I like this structure because it’s more readable. I can automatically read that in every iteration of the loop, I get a new “item” until the loop gets to the end of the array. It’s a great pattern. Eslint has a rule that recommends it over the old for(;;) pattern.

Sometimes I make a mistake and confuse the for...in loop instead of for..of. For..in is similar for..of but instead of the values of an array it returns the keys or index of an array item.


for(let item in myArray) {
  console.log(item);
}

// 0 
// 1 
// 2
// 3

I have made this mistake a few times so I made myself a mnemonic so I don’t forget.

Remember ‘Key IN the value OF’.

for..IN returns “key”/index of an array item and for..OF returns the value.

Event handlers and proper use of "this"

Here’s another error I keep committing when working on Javascript. The this keyword like many programming languages hold special meaning. It represents the current context the code is acting on. In Javascript, most values are objects even functions.


class MessageClicker {
  constructor(elem, message) {
    this.message = message;

    elem.addEventListener('click', this.onClick);
  }
  onClick() {
    alert(this.message);
  }
}

let fragment = document.createDocumentFragment();
let button = fragment.appendChild(document.createElement('button'));
button.textContent = 'click me';

let messageMe = new MessageClicker(button, 'This is an awesome class');

document.body.appendChild(button);

In the example above, I have a class MessageClicker that accepts a DOM element and a string message. An alert opens up with the provided string. When I tested I get the alert but with an undefined message. The issue is in the onClick event handler.


  onClick() {
    alert(this.message);
  }

The this keyword refers to the object but not all the time. Like our example, when contained in a callback function this is actually undefined. We can fix this in a few ways. One way is to bind the function when we attach it to the element.

  constructor(elem, message) {
    this.message = message;
    elem.addEventListener('click', this.onClick.bind(this));
  }
  onClick(){ /* ... */ }

The other way is to use arrow functions. In arrow functions, this keeps the value of the enclosing context. In our example it’s the class MessageClicker.

class MessageClicker {
  constructor(elem, message) {
    this.message = message;

    elem.addEventListener('click', this.onClick);
  }
  onClick = () => {
    alert(this.message);
  }
}
/* ... */

Wrapping up

These are just some of the errors I come across with when working with Javascript. Mostly the mistakes are caused by confusion around certain concepts like the this context and the meaning of const. Most of these are easy to fix. My take is avoid the confusion and use more familiar syntax. If you think its worth using then I recommend trying to dig deeper before introducing any new keyword or convention in to your code. Cheers!

CSS Snippets I Use 90% of The Time - Part 1

Sat, 28 Jan 2023 08:37:00 GMT

I have snippets of code I return to whenever I find patterns in a design. It is one of those efficiency hacks I’ve adopted as a programmer. I have quite a collection. Gathered working on websites in different industries. Although the size and theme of these websites vary, I can still count on some basic UI patterns. I condensed them into tried and tested snippets I use often.

In this post, I am sharing some of these CSS snippets.

1. Golden ratio font settings

The first thing I learned as a web developer is that how you define the text styles tells the reader the hierarchy of the information presented on a page. For that reason one of the very first things a web developer defines in CSS is the font styles.

@import url('https://fonts.googleapis.com/css?family=Poppins:400');

body {
  background: white;
  font-family: 'Poppins', sans-serif;
  font-weight: 400;
  font-size: 16px;
  line-height: 1.75;
  color: #000000;
}

p {margin-bottom: 1rem;}

h1, h2, h2, h4, h5 {
  margin: 3rem 0 1.38rem;
  font-family: 'Poppins', sans-serif;
  font-weight: 400;
  line-height: 1.3;
}

h1 {
  margin-top: 0;
  font-size: 11.089rem;
}

h2 {font-size: 6.854rem;}

h2 {font-size: 4.236rem;}

h4 {font-size: 2.618rem;}

h5 {font-size: 1.618rem;}

small, .text_small {font-size: 0.618rem;}

Here we’ve defined all the important semantic tags concerning the text. The font sizes are defined according to the Golden Ratio. The golden ratio, is also known as the golden section or divine proportion. In mathematics, it is defined as approximately equal to 1.618. In aesthetics, the golden ratio is known as a basis for beauty. You can apply this in typography when you are figuring out the font size of a body text and its header. For example, if your body font size is 16px, multiply it by 1.618 to get the heading font size. I use the “Poppins” font here as an example. Change the font depending on your needs.

 <h5>Heading title</h5>
 <p>Nunc velit leo, pellentesque a velit pretium, hendrerit tempor tortor. 
  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas massa 
  lectus, venenatis non elit sed, egestas gravida lacus. Etiam porta congue 
  est, sed bibendum purus feugiat eu. Integer at vulputate tellus, tristique 
  tempor lectus. Nam nisl enim, viverra egestas bibendum eget, aliquet id 
  eros. Pellentesque habitant morbi tristique senectus et netus et malesuada 
 </p>

Heading title

Nunc velit leo, pellentesque a velit pretium, hendrerit tempor tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas massa lectus, venenatis non elit sed, egestas gravida lacus. Etiam porta congue est, sed bibendum purus feugiat eu. Integer at vulputate tellus, tristique tempor lectus. Nam nisl enim, viverra egestas bibendum eget, aliquet id eros. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris venenatis erat et dui commodo, id tempus ante porttitor. Integer eget sapien accumsan, sodales ante ac, mattis nulla.

The golden ratio here is the typographic scale that dictates font sizes within your visual text hierarchy. The golden ratio might not fit your design but it’s a good starting point. My suggestion is to start with these and then adjust them to match your needs. I recently discovered layoutgridcalculator’s typography tool. It’s very versatile with options to define the scale ratio and the number of steps in the scale. You can even generate the CSS once you’re happy with your settings. Check it out if you’re not quite sure where to start.

2. Horizontal list

I always use list tags for accessibility. The bad thing about lists is that by default they are rendered vertically. For some designs, you will need to render these lists in a row. Start with the markup below and stick these CSS into your stylesheet and add .horizontal-list class to turn any list into a horizontal list.

list item 1
list item 2
list item 3
list item 4


  .horizontal-list {
    list-style: none;
    padding: 0;
    margin: 0;
  }

  .horizontal-list li{
    display: inline-block;
    padding: 4px;
    margin: 4px 0 0;
    border: 1px solid #ddd;
  }


  <ul class="horizontal-list">
    <li>
        sample item 1
    </li>
    <li>
        sample item 2
    </li>
    <li>
        sample item 3
    </li>
    <li>
        sample item 4
    </li>
  </ul>

list item 1
list item 2
list item 3
list item 4

I used this a lot, especially for navigation. You can replace the text with anchor tags or buttons. If you have a lot of items this style will also wrap nicely.

list item 1
list item 2
list item 3
list item 4
list item 4
list item 4
list item 4
list item 4
list item 4
list item 4

It is good to remember that this is not the only way to style a list. It has not failed me so far so I am sticking with it.

3. Breadcrumbs

The horizontal list earlier is the basis for another common web UI pattern. The breadcrumb is a great navigation tool, especially for sites with a lot of content. You tackle it as a list with a divider symbol, usually, a chevron pointed to a child page.


  <nav class="breadcrumbs">
    <ul class="horizontal-list">
      <li>
          <a href="#">parent item 1</a>
      </li>
      <li>
          <a href="#">parent item 2</a>
      </li>
      <li>
          <a href="#">parent item 3</a>
      </li>
      <li>
          current page title
      </li>
    </ul>
  </nav>


 .breadcrumbs li:not(:last-child)::after {
    display: inline-block;
    content: '>';
    padding: 0 5px;
 }

It’s important to note that you need to add the “horizontal list” style with the breadcrumb CSS here.

Accessibility work might take you into situations where you need to expose text to screenreaders but hide it from sighted users. One use case is when you need image buttons without text.


.screenreader-only {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}


    <ul class="horizontal-list icon-buttons">
      <li>
          <button><span>✖</span></button>
      </li>
      <li>
          <button><span>💾</span></button>
      </li>
    </ul>

Here we have a list of icon buttons. The output can be understood by sighted users but is next to useless for screen reader users. We need descriptive text to tell screen reader users the buttons’ purpose.

To remedy this we change the markup a bit to include the button text. Wrap the text in span with screenreader-only class.


    <ul class="horizontal-list icon-buttons">
      <li>
          <button><span>✖</span><span class="screenreader-only"> Delete</span></button>
      </li>
      <li>
          <button><span>💾</span><span class="screenreader-only"> Save</span></button>
      </li>
    </ul>

Now when a screen reader focuses on one of the buttons it will announce the included text.

Use a screen reader to test the widget below.

5. Disabled area

Here is a style commonly used but rarely thought about. I for one only remember adding disabled styles when I actually need it. The use case is you want to disable an area to prevent interaction. On form controls (input, textarea, buttons etc.) you can accomplish this by using the [disabled=true] parameter. But for non-form controls like a table or big wall of text. There is no markup or attribute to aid with this.

Example


<div class="wall-of-text">
Fusce porta pellentesque molestie. Praesent sit amet tempus enim, in convallis risus. Vivamus id urna augue. Quisque laoreet fringilla lorem vitae posuere. Integer non ex molestie, maximus ex non, tristique enim. Pellentesque dapibus ultrices elit, eget ornare risus. Etiam eget ullamcorper nunc, sed ultricies enim. Quisque vehicula sit amet enim eu imperdiet. Aenean dignissim purus nisi, ultricies accumsan tortor finibus et. Duis dictum orci vitae convallis bibendum.
</div>

Another reason to disable a section of your page is to tell the user the difference between different states like when a toggle controls some content.


  .disabled, [disabled] {
    opacity: 0.5;
    pointer-events: none;
  }

Read agreement

Fusce porta pellentesque molestie. Praesent sit amet tempus enim, in convallis risus. Vivamus id urna augue. Quisque laoreet fringilla lorem vitae posuere. Integer non ex molestie, maximus ex non, tristique enim. Pellentesque dapibus ultrices elit, eget ornare risus. Etiam eget ullamcorper nunc, sed ultricies enim. Quisque vehicula sit amet enim eu imperdiet. Aenean dignissim purus nisi, ultricies accumsan tortor finibus et. Duis dictum orci vitae convallis bibendum. Agree Disagree

Update: Most browsers now support inert attribute. It works similarly to pointer-events: none that prevents triggering or receiving any events on the element. Note that, unlike form controls that change the style when disabled attribute is set, there is no visible indication when inert is set. It is the developer’s responsibility to define if needed.


[inert] {
  opacity: 0.5;
}

Wrapping up

These styles may not be as glamorous as grid layouts or flip cards but equally important when building a website. There are more styles to share in future posts.

Top three things to do for better keyboard and screenreader navigation

Fri, 20 Jan 2023 08:07:00 GMT

Improving accessibility is an exercise in empathy. We put ourselves in other people’s shoes and imagine how we can do a specific task. Tasks like going up a flight of stairs, knowing when to cross a street, or how to consume a website. Knowing the difficulties people encounter when using your website/application, can aid us in designing better experiences for our users.

One of the areas UX designers and developers alike fail to give attention to is keyboard navigation. Keyboard navigation is important because you may have users that depend on the keyboard or screenreaders to read your website. If your site is hard to navigate for these users, they might just quit your site all together and move on.

Here are my top three tips for better keyboard and screen reader navigation

1. Use headings and landmarks

I mentioned before in five steps to improve accessibility. One of the simplest thing you can do to improve accessibility is to use semantic tags like headings and landmarks to mark up your HTML. Headings and landmark tags not only help tell the screen reader about the information hierarchy on your page but also helps in navigation. This technique benefits screenreader users.

Headings provide a straightforward way of distinguishing information hierarchy on a page. The first heading (<h1 />) is commonly the title of the page which tells the reader what the site or page is about. After that, you organize the supporting information into sub-topics titled <h2/> and so on.

Best practices for headings and landmarks are based on W3C WAI Tutorials and MDN.

Headings

Page regions or landmarks divide the content into meaningful areas. For example, the <header /> will contain navigation links and the name of a website, and the <main /> tag will wrap the “main” content of the page.

Region tags

header
footer
aside
nav
main
section

We can also use ARIA roles

Landmark roles

banner
complementary
main
navigation
region
and more.

Screen readers are capable of traversing a page through headings and landmarks. Using certain shortcuts, assistive technologies can jump from one heading to another. Some screenreaders can even list all the headings and landmarks on a page and then give the user a choice to jump to a specific heading or landmark.

2. Add skip links

The worst part about navigating a page with the keyboard (e.g. Tab) is having to go through a lot of page real estate. For example, you would need to go through the main navigation, aside elements, tag lists, and call-to-action buttons before you can get to the main content. It can be exhausting for your users to do that every time. My Tab key finger (if that is a thing) already hurts just thinking about it. It wastes your users’ time when they can already be reading your awesome content. To remedy this add skip links to your markup. Skip links can be part of your design or hidden until needed. These elements allow the user to jump to a specific topic or area on your page. Saving them so much pain.

Here’s a simple “skip to main content” link you can incorporate to your site.

Skip link pattern adapted from WebAIM: Skip navigation links.

.skip-to-main-content {
  // hide by default but readable to screenreaders 
  width: 1px;
  height: 1px;
  position: absolute;
  top: -999px;
  left: 50%;
  transform: translateX(-50%);
  transitio: top 0.35s;

  &:focus{
    // show in to view when focused 
    top: 0;
    height: auto;
  }
}

<body>
<a href="#main-content" class="skip-to-main-content">Skip to main content</a>
...

<article>
  <h1 id="main-content"> </h1>
</article>
</body>

The key here is to make the skip link the very top element in the markup so that it gets focused first. The link scrolls the page to the area marked by id=main-content.

3. Minimize key presses

If you have a user interface/design that requires a lot of traversals and you can’t use skip links, modify the key handling used for navigation.

Tables are a common pattern to present information for a related group of data. Take, for example, the wireframe above, we have columns for data and a column for action buttons. The easiest we can do is just mark up the HTML so that the focusable elements like buttons can be “tabbed” into. In the previous image, we marked the element the user needs to interact with. If you use the Tab key, it will take you 8 key presses before a user reaches the Delete button. I call 8 key presses the traversal index (T index for short) to activate the Delete button.

Before we go further, note I just coined the term, traversal index. Not sure if there’s a proper term for that.

Anyhow, the table still looks fine with three controls(checkbox, delete and save button) and a few rows. But when you’ve add more focusable elements or when the number of table rows increases, the traversal index will grow quite large.

We want to reduce the T index to make your keyboard(/screen reader) users happy. Now check out the sample below,

In this table, we’ve added event handlers to use Arrow Up and Arrow Down keys to navigate between table rows. Once a row is focused(indicated by grey background color), the user can then use the Tab key to navigate between the items within the row. With this simple change, we’ve reduced the T index to 4. Sparing your users from carpal tunnel syndrome.

It is important to note that since this is not a common navigation convention for tables, you need to notify the user about the extended navigation before or when the table is focused.

For example,

Instruction: Use arrow keys to navigate rows and Tab(/Shift+Tab) key to move between items in a row.

Here’s another,

The wireframe shows three sections (header, table, and links). The header has only one link and the table has four(4) rows with one(1) focusable element per row. To navigate from the header to the “links” section, we will need to press the Tab key six(6) times. The problematic step here is we spend a lot of time focusing on the table rows before arriving at the Links section.

We can improve the keyboard navigation by keeping the “tab” stops on the three sections initially. One way of doing this is to prevent your table contents from getting focused until needed. For instance, adding inert attribute to the <tbody /> wrapper will prevent the table contents from getting focused. This change reduces the T index to 3.

The second part of this technique is to assign a special key( or keys) to enable navigation inside the table. For example, same with the previous table navigation handler, when the table is focused pressing Arrow down or Arrow up keys will focus one of the rows. Then you can navigate vertically or horizontally inside the table after. We can then continue through the table rows or press Escape key to exit the table.

You might think that the additional navigation is complex. It won’t be - it really depends on your implementation. It will take quite a bit of coding but the other side of the equation is a better way of navigating your page.

Another option we can do here to improve the T index is to assign a key combination(/s) to each section. For example, assign / + l to jump straight to the links section. This will keep the default navigation behavior but still provide the user a means to avoid extraneous key presses.

Again, the key for both techniques is to inform the user of the special keyboard navigation.

Wrapping up

Improve keyboard accessibility further by making sure to;

use headings and landmarks;
add skip links when necessary and;
reduce the number of keypresses to navigate a page/section

Reference

Newbie's Guide to Learning Vue.js

Sat, 14 Jan 2023 07:07:00 GMT

Every time I want to learn something new I try to plan first. A very quick to-do list related to the subject. I know there’s a lot of great guides out there about Vue.js. But I still like making my little todo list. It keeps me focused.

To start, I went to Vue.js’ documentation page. I scanned all the topics provided. I looked for the least amount of concepts to get a sense of Vue.js - enough to start a simple application. Then, I grew my knowledge gradually. I’ve outlined these initial concepts in this post.

If you’re like me, one that is practically new to Vue.js, or if you worked on Vue.js before but interested in a refresher, or are just interested in reading on the topic, continue to read on.

Vue.js learning plan

To be honest I got lost quite early because of topics I am not familiar with. Topics like the difference between Options API and Composition API. If you don’t know what that is either, then you were me at the beginning. Vue.js documentation on API Preference should explain the difference between API styles.

To simplify, I restricted my study to just using the Options API. Feel free to try whichever API style you prefer. I found I readily applied the same concepts using Composition API once I understood it. So don’t worry about having to learn both in the beginning.

1. How to create a Vue Application

To start off, the first thing any developer wants to learn is how to make a simple application. Like most front-end frameworks nowadays, there are two ways to start creating an application. The first option is hosting an HTML page with the library CDN loaded and one is to build an application using build setup. Choose whichever way you want to start with. What’s important is you get started early to practice.

HTML page loading Vue CDN

<script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>

Build setup with NodeJS

> npm init vue@latest

2. Working with Templates

Vue.js has templates to define the structure of a simple application. Templates are written in HTML(or HTML-like syntax) and can include special library-specific directives and expressions to render data.

<span>Message: {{ msg }}</span>
<p>{{ rawHtml }}</p>

3. Vue.js Directives

While working with templates, you will come across directives. Directives appear as element attributes specific to Vue.js. They are prefixed with v- syntax like the example below. Directives extend templates with logic and additional functionality. The example below the directive v-for loops thru the items and render the text for each item inside the div.

<div v-for="item in items">
  {{ item.text }}
</div>

4. Data handling and methods

Vue.js components have a data object that holds the component’s state, and methods that can be used to manipulate the state. In my opinion, the ability to manage and manipulate data is what makes front-end frameworks interesting. It’s the difference between a simple HTML page and a dynamic site.

State management

State management is an advance topic related to data and how it drives your application. You can use the data object and other techniques to manage the state of the application. For simple cases that is enough. For more complex applications we should be using state management libraries. These libraries are Vue.js’ answer to the flux pattern libraries ubiquitous to React.js projects.

Pinia
Vuex

Some articles I’ve read - recommends using Pinia over Vuex.

5. Computed Properties

Computed properties are calculated based on other data or properties on a page. The contrived example below illustrates what computed properties are used for. The values are automatically “calculated” from the source property, store.fruits. When the source property changes the computed value also changes without additional code.


export default {
  data() {
    return {
      store: {
        fruits: [
          'apple',
          'mango',
          'banana',
          //...
        ]
      }
    }
  },
  computed: {
    hasMangoToSell() {
      return this.store.fruits.indexOf('mango') !== -1 ? 'Yes' : 'No'
    }
    //...
  }
}


<dl>
  <dt>Has mango to sell?</dt>
  <dd>{{ hasMangoToSell }}</dd>
  ...
</dl>

The hasMangoToSell computed property above is “computed” from the data object property store.

6. Handling events

Event handling is the essence of front-end interactivity. Vue.js allows you to handle events, such as button clicks, form inputs, and more. These events could either be inline or method handlers.

Inline handlers executed code is defined inside a @<event name here>="" attribute. Like so:

data() {
  return {
    count: 0
  }
}

<button @click="counter++">Increment</button>
<p>There are {{ counter }} sheep jumping over the fence</p>

Method handlers on the other hand are defined from the application object itself under the methods prop.


data() {
  return {
    counter: 0
  }
},
methods: {
  increment() {
    this.counter++;
  }
}

<button @click="increment">Increment</button>
<p>There are {{ counter }} sheep jumping over the fence</p>

Wrapping up

There are other concepts a Vue.js developer needs to learn of course. I think you will encounter those topics while running through the topics in this list. Advanced topics like components, watchers, and hooks. Feel free to add that to your own learning plan. I am thinking to cover those topics when I start building more complex applications.

After the list above I plan to explore more advanced topics and start building a project. It is important to practice by building small projects, experimenting with different features, and following tutorials. I think that is still the best way to learn.

Bonus

Aside from the excellent documentation on Vue.js’ website. I found their tutorial page really helpful too. If you like learning ala-FreecodeCamp-style, you can appreciate a similar experience. Same with FreecodeCamp, you are presented with topics on the language accompanied with code problems to solve. I recommend checking it out.

My progress so far

Below is my where I am in terms of my efforts learning Vue.js.

Learn Vue.js essential concepts (partial)
Debugging a VueJS application
Create a blog application using Vue.js
Learn Vue-Router
Build for Production

Fix accessibility using focus-within

Sun, 08 Jan 2023 01:07:00 GMT

A few issues I found recently for clients were related to accessibility. A few perfectly working user interfaces were not keyboard accessible. Not because they are custom controls nor because the controls were not tabable. But, because the keyboard experience did not match the mouse-only interactions. These user interfaces are confusing, to say the least.

I solved these issues by using the :focus-within psuedo-selector.

I listed a few of them and the solutions.

Table row with hidden buttons

Here the developer added an effect that shows the buttons when hovered. The markup is accessible to screen readers but does not look correct for sighted persons that use the keyboard. Accessibility is not just for screenreaders. Sighted people need to make sense of the page too.

Checkbox	Name	Job description	Controls
	John Doe	rocket scientist
	Adam smith	economist
	Jose	novelist


  <table tabindex="0">
    <thead>
      <tr>
        <th>
          <div class="sr-only">Checkbox</div>
        </th>
        <th>Name</th>
        <th>Job description</th>
        <th>
          <div class="sr-only">Controls</div>
        </th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><input type="checkbox" value="1" name="user"></td>
        <td>John Doe</td>
        <td>rocket scientist</td>
        <td>
          <button class="delete" aria-label="delete">❌</button>
          <button class="save" aria-label="save">💾</button>
        </td>
      </tr>
      ...
    </tbody>
  </table>

Using the mouse, the table above works perfectly well. There is color highlighting and the buttons become visible when the mouse is over a table row.

If you navigate the table using the keyboard, the experience is not what you will expect. Firstly, you don’t see the highlight color when focused on a row. The worst of it is you will be able to go through all the focusable elements using the keyboard - including the invisible buttons. This is confusing for sighted people using the keyboard.

Let’s check the style code below. The buttons are invisible by default(opacity: 0). When the mouse is over the row (:hover), it gets a background color and buttons become visible(opacity: 100%).

// SCSS

tbody tr {
  button {
    opacity: 0;
  }

  /**
  * Show buttons on hover
  */
  &:hover {
    background-color: #ffd57e;
    button {
      opacity: 100%;
    }
  }
}

Solution

We can use javascript and add an event handler on the focusable elements that gets triggered whenever any element on the row is focused. With that we can set a class (.has-focused-element) that applies the same style above.


const els = document.querySelectorAll('tr input[type=checkbox], tr button');

els.forEach(el => document.addEventListener('focus', onFocus));

// etc...

// SCSS

tbody tr {
  // ...

  /**
  * Show buttons on hover
  */
  &:hover,
  &.has-focused-element {
    background-color: #ffd57e;
    button {
      opacity: 100%;
    }
  }
}

The changes above will work but uneccessary. We should try to solve any style problems inside the CSS first before reaching for Javascript.

Another solution is to use :focus-within where the :hover psuedo-selector is defined.

The :focus-within CSS pseudo-class matches an element if the element or any of its descendants are focused. In other words, it represents an element that is itself matched by the :focus pseudo-class or has a descendant that is matched by :focus. (This includes descendants in shadow trees.) - MDN

“Focus-within” psuedo selector can match elements that has elements that gets focused. In this case, we have the checkbox and button elements. When these elements gets focus, we can apply the same style as if we hovered the pointer on the table row. This will work without adding a line of javascript.

// SCSS

tbody tr {
  button {
    opacity: 0;
  }

  /**
  * Show buttons on hover and when an element is focused inside the row
  */
  &:hover,
  &:focus-within {
    background-color: #ffd57e;
    button {
      opacity: 100%;
    }
  }
}

Solution in action

Here’s the same table using :focus-within,

Checkbox	Name	Job description	Controls
	John Doe	rocket scientist
	Adam smith	economist
	Jose	novelist

A user can navigate through the focusable elements in the row and see the “hover” effect.

Card with like(♥) button

Here’s another user interface with a hover effect but no keyboard focus effect. Hovering over any part of the card applies a heart icon on top of the image indicating to the user that they can make the image their favorite. This card UI is part of an image gallery.

♥

Works when using the mouse but when navigating using the keyboard - again the user experience fails. It lacks a good keyboard experience. When you tab through the card, the button gets focused - which is fine - but it’s not the effect we wanted.


<div class="card">
    <img src="https://images.unsplash.com/photo-1671026423293-7adf6a6abd13?crop=entropy&cs=tinysrgb&fm=jpg&ixid=MnwzMjM4NDZ8MHwxfHJhbmRvbXx8fHx8fHx8fDE2NzMwNTEwNzE&ixlib=rb-4.0.3&q=80" alt="">
    <span>♥</span>
    <div class="button-group">
      <button class="like">♥</button>
    </div>
  </div>
</div>

// scss

.card {
  
  // ...
  
  &:hover {
    img {
      opacity: 70%;
      background-color: #000;
    }

    span {
      opacity: 100%;
    }

    button {
      opacity: 0;
    }
  }

  // ...
}

I know some will ask why can we not just add tabindex=0 on the card and add a :focus style. Yeah that could work. But, we would end up with two focus steps(one for the card and the heart (♥) button) instead of just the button. We don’t want that.

Solution

Again :focus-within to the rescue. We go back to the style code and look for :hover styling.

// scss
/**
  * Make heart cover image visible when button is focused
  */
  &:hover,
  &:focus-within {
    img {
      opacity: 70%;
      background-color: #000;
    }

    span {
      opacity: 100%;
    }

    button {
      opacity: 0;
    }
  }

The changes above should apply the same experience for both mouse and keyboard users.

As a rule, we also want to add an outline when the card is focused using the keyboard. Similar to what we get when we focus any interactive control with the keyboard.

// scss
.card {
  // ...
  
  &:focus-within {
    outline: 4px dashed #333;
    outline-offset: 2px;
  }

  //...
}

Solution in action

Use the Tab key to navigate through the card. When the button gets focused the card activates the hover effect we defined earlier. Now both hover and focus events show the same effect.

♥

Apply effects when buttons are hovered

In this example we have an image with a color swatch control. When you hover over any of the colors, the corresponding color value is blended with the image. This works correctly with the mouse but with the keyboard. We want to be able to get the same effect on the image when any of the buttons gets focused using the keyboard.

  <div class="picker">
    <div class="picker-group">
      <button class="picker-item" style="--selected-color: #912424"><span class="sr-only">red</span></button>
      <button class="picker-item" style="--selected-color: #3566b2"><span class="sr-only">blue</span></button>
      <button class="picker-item" style="--selected-color: #226642"><span class="sr-only">green</span></button>
    </div>
  </div>

// scss
.picker {

  // ...
  
  background-image: url(https://images.unsplash.com/photo-1552944150-6dd1180e5999?crop=entropy&cs=tinysrgb&fm=jpg&ixid=MnwzMjM4NDZ8MHwxfHJhbmRvbXx8fHx8fHx8fDE2NzMwNTkzNzg&ixlib=rb-4.0.3&q=80);
  background-color: var(--selected-color);

  // ...

  &:hover {
    // blend image with color when button is hovered or focused
    background-blend-mode: hard-light;
  }

  // ...
}

For this one we have some scripting to setup the hover(mouseover) effect. We try set the CSS variable --selected-color as the picker background color.


const picker = document.querySelector(".picker");
const buttons = document.querySelectorAll(".picker-item");

function onHighlight(e) {
  const target = e.currentTarget;
  picker.style = target.style.cssText;
}

function onRemoveColor() {
  picker.style = "";
}

buttons.forEach((button) => {
  button.addEventListener("mouseover", onHighlight);
});

picker.addEventListener("mouseout", onRemoveColor);

This is how it looks. My blog software does not run javascript so the UI below only shows a snapshot of one of the button focused. I will include a Codepen demo later in this page so you can interact with it.

Again the issue here is that the interface does not work well with the keyboard for sighted people. It’s screen reader friendly but the experience is lacking when not using the mouse.

This is a bit more complicated so we leverage :focus-within in conjunction with a focus event handler to set the color and blend style when using the keyboard.

// SCSS

.picker {
  // ...

  &:hover,
  &:focus-within {
    // blend image with color when button is hovered or focused
    background-blend-mode: hard-light;
  }
}

// ...

buttons.forEach((button) => {
  button.addEventListener("mouseover", onHighlight);
  button.addEventListener("focus", onHighlight); // trigger highlight script when buttons are focused
});

//...

Using the solution above, we get a better experience without a lot of extra code. See the solution in action in the Codepen below.

Full solution

Here are all three solutions in action. Check out the final code to understand the solutions in their entirety.

Wrapping up

Sometimes as web developers, it is great to work on problems that improve the user experience for a variety of people. For all the tools in our disposal its really great to know that adding a single psuedo-selector like :focus-within could be so useful. Without it, we might have ended up with some complicated solutions or worst case have to start from scratch.

Reference

React Custom button: a study on accessibility

Mon, 19 Dec 2022 01:07:00 GMT

React and accessibility

I love ReactJs. I learned late in my career as there were not a lot of opportunities to do so. Most of the shops I worked at back then were jQuery-and-a-prayer operations, and there’s a whole separate post in how long it took to unwind that habit. But I digress, that’s a story for another day.

When I finally found a suitable situation to explore ReactJs for a previous employer, I jumped on it and picked it up quickly. It was weird in the beginning but it became quite natural in the end. Now I mainly work with ReactJS in most of my projects.

One of the great things about working with ReactJs is working with JSX. ReactJS does not understand JSX - we achieve this with Babel. Babel transpiles JSX into something ReactJS can understand. Anyhow, JSX is almost like HTML with some differences, and because it looks like HTML markup it becomes really easy to learn.

But, and it’s a big but, making it easy to learn does not save developers from issues related to accessibility. Some patterns that are perfectly valid in ReactJS aren’t necessarily accessible.

For example, when using labels in forms


return (<>
  <label htmlFor="firstName">First Name </label>
  {
    isEditing  
    ? <input type="text" id="firstName" name="firstName" />
    : data.FirstName
  }
</>);

When not editing, the input element identified id=firstName is not available. So the browser will ignore the label but still render it. This is confusing to screenreaders. The markup above looks contrived but you will be surprised how often I see this. We can easily fix this by keeping the input element available to the browser but hidden to the user when not editing.


return (<>
  <label htmlFor="firstName">First Name </label>
  <input type="text" id="firstName" name="firstName" value={data.firstName} disabled={!isEditing} />
</>);

The outcome is similar to the former but the current markup is more accessible. Screenreader-friendly, in short.

I wanted to understand how best to tackle accessibility for custom components in React. With some rudimentary understanding of ReactJS, I proceeded with my education with a custom button. I know I’ve always said to always use semantic tags when possible, and that is still true. But to understand what a button should have to make it accessible, learning to make a custom button seemed like a good exercise before building anything more complex. Not just what ARIA attributes to put in but what I should be looking for when working with React and keeping it accessible. Things like styling and visual feedback when buttons are activated etc.

Custom Button

I started with a simple ReactJS component. A span wrapper element with an onclick event.


  function CustomButton ({ onClick, children, ...restProps }) {
    return <span onClick={onClick} {...restProps}>{children}</span>;
  }

  // usage

  const onClick = () => alert('button clicked');
  return <CustomButton onClick={onClick}>Click me</CustomButton>;

To simplify, we will assume that the button will always have text, passed as a children prop.

The markup for the component above has issues. Firstly, since it’s a span it needs some styling to make it look like a button. It really depends on how you want to render a button but for our purpose, I will stick to a classic raised button style.

Button styling

We add some css to handle hover and clicked event styling.

/* SCSS */

.custom-button {
  display: inline-flex;
  justify-content: center;
  background-color: #f1f2f3;
  min-width: 140px;
  box-shadow: inset -3px -3px 6px 0 rgba(#000, 0.15),
    1px 1px 2px 0 rgba(#000, 0.15), 2px 2px 4px 0 rgba(#000, 0.15);
  padding: 0.35rem 0.5rem;
  border-radius: 10px;

  &:active {
    box-shadow: inset 3px 3px 6px 0 rgba(#000, 0.15),
      -1px -1px 2px 0 rgba(#000, 0.15), -2px -2px 4px 0 rgba(#000, 0.15);
  }

  &:focus-visible, &:hover {
    outline: 4px dashed orange;
  }
}

Selectors

The :active selector is applied when the button is clicked, while :hover applies when the mouse is over the button. Finally, :focus-visible will ensure that the button gets a visible outline when the button is navigated to using the keyboard.

Our custom button looks like a proper button now with drop shadow and on press styling. When I click the button it writes “button clicked”. For a button to be accessible it should be keyboard accessible. Let’s try navigating to the button using Tab (and Shift + Tab) key in the Codepen demo below.

As you can see, we are unable to focus the button. Next problem in our custom button we need to tackle is making it operable using the keyboard.

Keyboard accessible

The WCAG guideline 2.1: Keyboard criterion requires interactive content(such as a button) to be operable using the keyboard. This is for users that can not use a mouse like people who are blind or with issues that make them prefer the keyboard. Simply, anything you can operate with a mouse should be available for a keyboard user too.

Tabindex

We need to be able to navigate to the button. What we need is to add tabindex so that it becomes focusable.


function CustomButton({ onClick, children, ...restProps }) {
  return (
    <span 
      className="custom-button" 
      tabIndex={0} 
      onClick={onClick} 
      {...restProps}>
        {children}
    </span>
  );
}

Cool! 😎 Now it’s focusable. Next, press Enter key to trigger the button. If you notice nothing happened, that is because we lack a keyboard event handler!

Keydown handler

We need a KeyDown handler that runs the same operation as if it was clicked like a native button. And like how a native button works we trigger the designated action with Enter and Spacebar keys.


function CustomButton({ onClick, children, ...restProps }) {
  const onKeyDown = (e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      onClick(e);
    }
  }

  return (
    <span 
      className="custom-button" 
      tabIndex={0} 
      onClick={onClick} 
      onKeyDown={onKeyDown} 
      {...restProps}>
        {children}
    </span>
  );
}

Let’s see how it works so far — use the Tab key to navigate and activate the button:

Keydown styling

Nice, the action is activated with either the Enter or Spacebar key. There is another issue. None of the previous styles we added earlier will apply when we activate the custom button using the keyboard. We don’t have a selector for that so we need to use class selectors.

Since this is a state of the button, we need to provide code so that the component can track it internally.


function CustomButton({ onClick, children, ...restProps }) {
  const [isPressed, setIsPressed] = React.useState(false);

    const onKeyDown = (e) => {
      if (e.key === "Enter" || e.key === " ") {
        onClick(e);
        setIsPressed(true); // when pressed
      }
    };

    const onKeyUp = (e) => {
      if (e.key === "Enter" || e.key === " ") {
        setIsPressed(false); // when keyboard released a key
      }
    };

    // ...
}

We need to tell the button when to apply the “button pressed” styling. We accomplish that by setting a className, custom-button-pressed. We can recycle the :active styling defined earlier.

.custom-button {
  
  //...*

  &:active,
  &-pressed {
    box-shadow: inset 3px 3px 6px 0 rgba(#000, 0.15),
      -1px -1px 2px 0 rgba(#000, 0.15), -2px -2px 4px 0 rgba(#000, 0.15);
  }

}

Next, we apply/remove the class name whenever the state changes.


  // ...

  let classNames = "custom-button";
  if (isPressed) {
    classNames += " custom-button-pressed";
  }

  return (
    <span
      className={classNames}
      tabIndex={0}
      onClick={onClick}
      onKeyDown={onKeyDown}
      onKeyUp={onKeyUp}
      {...restProps}
    >
      {children}
    </span>
  );

Voila, the button style when activated with the keyboard works.

Our custom button is looking great! To recap, we styled the button and made it operable with both the mouse and the keyboard. It looks shippable, right?

Not yet.

If you use a screen reader now, you will notice that the custom button is treated as a clickable div - NOT a button. Since we only made the span look and act like a button, the browser does not tell the screen reader that we’ve made a button. It still thinks this is a clickable div. We add markup to tell the browser what to expect.

Role=button

To tell the browser that we have a button we assign it a role of button — simple enough, right?

ARIA roles provide semantic meaning to content, allowing screen readers and other tools to present and support interaction with object in a way that is consistent with user expectations of that type of object. — MDN: WAI-ARIA Roles

I mentioned before we should be using semantic tags. The browser readily understands the behavior and information about semantic elements telling assistive technologies(like a screenreader) what to expect. This is already baked into the semantic element. We can just use it straight away. On the other hand, our custom button needs our help providing that information to the browser. Setting the role turns our custom button into a semantic button element for click, keyboard, and screen-reader purposes. It still won’t behave like a native button for form submission or the disabled attribute — that needs aria-disabled and a bit more work — but that’s outside what we’re tackling here.

Test the next demo with a screen reader.

Install a screenreader

NVDA for windows

VoiceOver for Macs

ORCA

React hook: useButton

I like React hooks. It is great for reusing functionality. Our custom button is great but we are stuck with a span element. We can change this in several ways. My favorite is moving the component behavior and state in a React hook. Once we’ve moved the behavior out of the custom button, we don’t need the custom component anymore. We can directly apply the props to any element we want to make into a button.


const KEY = {
  Enter: 'Enter',
  Spacebar: ' ',
}

function useButton({ onClick, className }) {
  const [isPressed, setIsPressed] = React.useState(false);

  const onKeyDown = (e) => {
    if (e.key === KEY.Enter || e.key === KEY.Spacebar) {
      onClick(e);
      setIsPressed(true);
    }
  };

  const onKeyUp = (e) => {
    if (e.key === KEY.Enter || e.key === KEY.Spacebar) {
      setIsPressed(false);
    }
  };

  return {
    isPressed, // tells if the button is pressed
    a11yProps: { // props that tell the browser this is a button 
      tabIndex: 0,
      role: "button"
    },
    eventProps: { // event handlers 
      onClick,
      onKeyDown,
      onKeyUp
    }
  };
}

// usage

  const { isPressed, a11yProps, eventProps } = useButton({ onClick });

  let className = "custom-button";
  if (isPressed) {
    className += " custom-button-pressed";
  }

  //...
  
  <span className={className} {...a11yProps} {...eventProps}>
    Click Me
  </span>


  //...

For the a11yProps, we only needed tabIndex and role=button.

Extending the hook

We can extend useButton with other ARIA props for various use cases e.g. a toggle button. A toggle button keeps its isPressed state until triggered again. Using aria-pressed, we can keep the state set for the browser’s benefit.


// usage
  import _ from 'lodash';

  const { isPressed, a11yProps, eventProps } = useButton({ onClick });

  let className = "custom-button";
  if (isPressed) {
    className += " custom-button-pressed";
  }

  const newA11yProps = _.extend({}, a11yProps, {
    'aria-pressed': isPressed,
    'aria-label': 'Toggle'
  });

  //...
  
  <span className={className} {...newA11yProps} {...eventProps}>
    <span className="toggle-notch" />
  </span>


  //...

We’ll use lodash’s _.extend here (make sure it’s imported: import _ from 'lodash';) to merge the new props in without mutating the original object. Also, we threw in aria-label to fix the lack of visible text.

Wrapping up

To make an accessible custom button component we need a few things;

CSS to simulate a button state from unpressed, focused, and when activated.
Event handlers not just for the mouse but for the keyboard as well.
ARIA to change the semantic meaning of an element to a button.

With the useButton hook we can extract the learnings from this exercise into a reusable function and apply it anywhere we need a custom button element.

Five Web Accessibility Extensions for Visual Studio Code

Thu, 15 Dec 2022 08:07:00 GMT

Developing with accessibility in mind requires knowledge of WCAG rules and good techniques. These techniques boils down to remembering good accessbility patterns in code. Linters are good at discerning less ideal patterns and provide hints on how to fix them. Before I used to think linters are optional for developers. But now I don’t think I can work without them. Using a good IDE linter will help making sure your code follows accessibility best practices and in turn make you more productive.

Web accessibility involves following certain design principles which ensure that people who experience difficulties or limitations have the same or a similar experience as those who do not. - Hubspot

In the example below the linter should be able to recognize that the button tag is missing a visible label.


<button>
  <img src="save.png" class="responsive" alt="" />
</button>

The code above is problematic for screenreaders because it does not have any text to describe what action the button is supposed to do. I have seen a lot of HTML markup that forgets this simple rule. A linter would have caught this before even going into production.

Here is the same code with a linter

Visual Studio Code have plugins that help coders make their code pass accessibility checks.

Here are the top 5 plugins I use:

1. Axe accessibility linter

Axe is a leader in accessibility testing and tooling. They built axe-core which powers axe-linter. It is easy to install and no configuration needed. You can start enjoying the benefits of realtime code accessibility checks.

Its pre-configured to check the following file extensions:

React (.js, .ts, .jsx, .tsx)
HTML (.htm, .html)
Markdown (.md, .markdown)

The great thing about axe-linter is you can click a link in the hint. The linked page will explain the issue, why its relevant and how to fix it.

2. Webhint

Webhint helps you improve your site’s accessibility, speed, cross-browser compatibility, and more by checking your code for best practices and common errors. - Webhint

Webhint.io is a tool that looks for a suite of website best practices. These best practices include accessibility, website performance, security, etc. The command line tool will scan the site provided and return a report. The webhint visual studio extension, on the other hand, analyzes code while you develop. (See accessibility hints).

It also uses axe-core to analyze the code.

3. Web Accessibility

Website accessiblity is another Vscode plugin geared at checking for accessibility issues in code. Not as extensive as the first two plugins but I think that is a good thing. Its focus is just accessibility issues nothing else. The hints are simple and does not offer any other options. Perfect for coders who love memory efficient IDEs.

Eslint is a bit more complex to install than the previous plugins. If you’ve been developing with the Eslint and Eslint plugin then you will have an easier time.

Installation

Run these commands in your project root


npm install --save-dev eslint eslint-plugin-jsx-a11y
./node_modules/.bin/eslint --init

You can also do this globally;


npm install -g eslint eslint-plugin-jsx-a11y 
eslint --init

Finally, add jsx-a11y in plugins section of your .eslintrc


{

 "plugins": ["jsx-a11y"]

}

You might get a popup saying there is an error starting eslint plugin, check the output logs in Vscode for any issues. In most cases, making sure you have the latest nodejs and npm fixes the issue.

5. SonarLint

Last but not the least, Sonarlint is a code quality checking tool, like Webhint and Eslint. It checks for a suite of issues in your code not just accessibility. It requires Java runtime to work.

The accessibility rules are limited to HTML portion of your code.

If you are more interested in accessibility checks, I recommend using the other plugins on this list.

Bonus: Errorlens

Errorlens is not an accessibility plugin but a support plugin that places the warnings and errors from the linters front and center. Its nice to see the issues directly without having to hover over the squiggly lines or opening the “problems” tab.

Once you have chosen your accessibility plugin I recommend installing Errorlens to improve visibility of errors and warning messages.

Without Errorlens

With Errorlens

Wrapping up

You still need to have unit and regression tests in place before pushing anything into production but at least the number accessibility issues that get through would be less than just leaving it to CI/CD testing suites. Using proper tools in development makes your work look more professional. It also helps your team. Use these accessibility plugins so you can bake in accessibility into your workflow will less effort.

Five simple steps to improve website accessibility

Sat, 10 Dec 2022 23:07:00 GMT

Accessibility is very important. It ensures that anything we make is available to a greater number of people. It is not just about people who use screen readers.

Web Content Accessibility Guidelines (WCAG) set down a set of rules on how to make websites accessible to people with health conditions or impairments.

It is hard to meet all the WCAG criterions. It requires understanding of each criterion and the sufficient techniques to meet those requirements. I have been working to improve accessibility in our product. Most of the time I’ve only needed to remember five things.

1. Add labels to interactive elements(buttons, links, input etc.) and descriptive text to images

Interactive elements like buttons, links, and form elements should have labels. Images should have alternative text. This ensures assistive technologies are able to get context for these page elements.

Buttons

Buttons are used to trigger an action. Best practice is to name it to something that describes the action.

Save
Download
Delete
Add
etc.


<button>Save</button>
<button><image src="download.svg" alt="" /> Download this wallpaper </button>

There will be instances that you may want to hide the label e.g. icon buttons. You can still be accessible by adding an aria-label.


<button aria-label="Delete"><image src="delete.svg" alt=""/></button>

Links

We use links to provide a way to navigate to other locations on the net. It can be another web page, email address, or a section on the current page. So link labels should convey the purpose or destination.


<a href="/home"> Home </a>

Link to download an image

For links with images, you can add an adjacent text or provide the image with alternative text.


 <a href="/wallpaper-wide.jpg"><image src="thumbnail.png" alt="Download wallpaper" /></button>

Email


 <p> Email me to <a href="mailto:help@codespud.com">get help.</a> </p>

Link to new window or tab

Sometimes you want to provide a portion of the text to screen readers. Style the text so that they are hidden but visible to screen readers.


<a target="_blank" href="http://google.com"> 
 Go to Google 
 <span class="screenreader-only">(Link opens in a new tab)</span>
</a>

.screenreader-only {
    position:absolute;
    left:-10000px;
    top:auto;
    width:1px;
    height:1px;
    overflow:hidden;
}

Link text should be unique

<!-- Do NOT do this! -->

<ul>
 <li>
 <span>John Doe</span> 
 <a href="/user/1">Read Profile</a> 
 </li>
 <li>
 <span>Sam Flag</span> 
 <a href="/user/2">Read Profile</a> 
 </li>
 <li>
 <span>Rick Star</span> 
 <a href="/user/4">Read Profile</a> 
 </li>
</ul>

Screen reader users can scan links and may bypass context when they do. The markup above will make it hard for the user to locate the information they are looking for.

<!-- Better! -->

<ul>
 <li>
   <a href="/user/1">John Doe <span class="screenreader-only">profile</span></a> 
 </li>
 <li>
   <a href="/user/2">Sam Flag <span class="screenreader-only">profile</span></a> 
 </li>
 <li>
   <a href="/user/3">Rick Star <span class="screenreader-only">profile</span></a> 
 </li>
</ul>

Now the screen reader can jump to these links and immediately understand that these are links to user profiles.

Form elements

Form elements must have labels. This should be a name or short description of the data you are collecting. For radio or checkbox input types, describe the relationship of the invidual items.

Explicit labels

Using label tag


<label for="firstname">First name<label>
<input type="text" name="firstname" id="firstname" />


<input type="checkbox" name="attending" id="attending" />
<label for="attending">Attend event<label>

Using aria-label


<input type="search" aria-label="Search" />
<button>Search</button>

Implicit labels


<label>
 Firstname: 
 <input type="text" name="firstname" />
</label>

Checkbox and radio input tags


<label>
 <input type="checkbox" name="attending" />
 Attend event
</label>

<fieldset>
<legend>Choose a fruit to buy</legend>
<label>
 <input type="radio" name="fruit" value="apple"/> Apple
</label>
<label>
 <input type="radio" name="fruit" value="pineapple"/>Pineapple 
</label>
 <label>
 <input type="radio" name="fruit" value="pear"/> Pear 
 </label>
</fieldset>

Images

Alternative text should describe the image. It is useless for impaired users to hear the image filename.

 <img src="blue-sky.jpg" alt="Beautiful clear summer sky " />
 <img src="couple.png" alt="Senior couple holding hands" />

Using figure tag

 <figure>
 <img src="couple.png" alt="" />
 <figcaption>Senior couple holding hands</figcaption>
 </figure>

Embedded SVG uses title


<svg viewBox="0 0 20 10" xmlns="http://www.w3.org/2000/svg">
<polygon points="473.486,182.079 310.615,157.952 235.904,11.23 162.628,158.675 0,184.389 117.584,299.641 91.786,462.257 237.732,386.042 384.416,460.829 357.032,298.473 "/>
 <title>A black star</title>
 </polygon>
</svg>

2. Do a keyboard test. Ensure focus order makes sense.

Screen readers and assistive technologies work with/like a keyboard. Ensuring that your site is keyboard accessible will help in navigating through interactive elements like buttons and links.

The rule is if an element is operable using the mouse then you should be able to do the same via the keyboard.

At the very least, a user should be able to:

Navigate through elements using the Tab (and Shift + Tab) key.
Confirm action using the Enter key or Spacebar.
Close a revealed widget using the Escape key e.g. popup menu.

It is important to understand the UI/page/form functionality. Check that each functional element is navigate-able and operable using the keyboard.

The focus order should follow the visual order on the page. If you find something out of place or an element is not focusable. Refactor your code or add tabindex to manage the focus order.

Make focusable


<div tabindex="0" class="form-response">Submission is successful</div>

Prevent element from getting focus


<div class="drawer is-closed" tabindex="-1"></div>

3. Use semantic markup

Semantic elements

Region (main, nav, footer, header etc.)
Lists (ol, ul, li, dl, dt, dd)
Headings (h1, h2, h3 etc.)
Content (article, section)
For emphasis (strong, em, b, i, u etc.)*

* In the past, its not recommended to use b, i and u tag when you intend to style a phrase or word to provide emphasis. Latest Screen readers now can understand strong and b(old) tag serve the same purpose. It is true for em and i too.

Landmark tags provide shortcuts for assistive technologies to bypass blocks on a page. For example, a user can go straight to the main content (marked by the main tag) or jump to the navigation block to move to a new page (wrapped by nav tag).

Headings aid assistive technologies to skip through topics on a page. For example, if I only want to know about the legal ramifications of whaling, I can locate the third heading and read on the topic.

 <h2>Moby Dick and whales in literature</h2> 
 <p>Captain Ahab's nemesis ... </p>

 <h2>How to catch a whale</h2>
 <p>First, you need a boat. ... </p>

 <h2>Whaling is illegal in most countries</h2>
 <p>IWC banned the practice in 1986 ... </p>

Use list tags to describe a collection. Screen readers will anounce a list and help it navigate each item and were you are in the list.

<!-- screen reader will treat this as a block of text
Do NOT do this if you intend to present a list -->

<h3> Fruits on sale</h3>
<div class="list">
  <span>Pineapple</span>
  <span>Apple</span>
  <span>Mango</span>
  <span>Pear</span>
</div>    

<!-- proper list uses list elements -->

<h3> Fruits on sale </h3>
<ul class="list">
  <li>Pineapple</li>
  <li>Apple</li>
  <li>Mango</li>
  <li>Pear</li>
</ul>

4. Make sure to have color and non-color indicators to convey the same information.

Using a red asterisk to tag required fields is a classic example of this. Using a symbol and a color ensures that color-impaired users can distinguish required fields.

Another example is adding patterns to a chart. Using patterns in conjunction with color make charts more inclusive. Imagine looking at a bar chart using only a color key. If a user suffering color blindness look at the same chart, he/she will find it hard to understand.

5. Use relative sizing for fonts

For font-size, use relative units(em, rem) instead of absolute units (px, pt). I recommend using rem with a body font size of 16px. Using relative units will ensure that users that need to zoom in on text are able to. This is especially important in mobile devices with smaller screens.


body { font-size: 16px }
h1 { font-size: 4 rem }
h2 {font-size: 2.5 rem }
blockquote { font-size: 1.25rem }
p {font-size: 1rem}

Wrapping up

There are more things to do to make a truly accessible website like color contrast and using ARIA attributes. For now, follow these few simple steps and you will have a more inclusive site that caters to a wider audience than just leaving it as is.

Reference

Working with Date and Time Input

Fri, 09 Dec 2022 12:07:00 GMT

I remember using JqueryUI’s datepicker. It was my go-to calendar widget in the past. It was great. I just drop an input box give it an “id” and then run a function.


$('#datepicker').datepicker();

You get a great-looking calendar picker for your forms. It was a great bit of software engineering. I’ve used it in a lot of my old projects and clients were impressed.

Some experts strongly advise against adding too many third-party libraries to websites. The extra library requests increase the time your site loads. Now that site speed has grown increasingly important to users, developers must be smart when deciding on the modules they add to their projects. Resources like javascript files block the browser from rendering until it’s fully loaded.

One less library to load is a few seconds slashed from your site’s loading time. Read Web.dev for more information regarding optimizing content loading with regards to third-party javascript.

Use native elements

One strategy to optimize a website is to use native elements like the date and time inputs instead of third-party widgets.

Aside from reducing the fat from your site, using native elements improves accessibility. You don’t need the extra coding necessary to make these elements work with assistive technologies.

Date input

The date input looks pretty much like any regular input element. Some browsers(e.g. Chrome) will have a placeholder corresponding to the date value and a calendar icon button.


<label for="birthdate">Birth date:</label>
<input type="date" id="birthdate" name="birthdate" />

Birth date:

Month input

The month input lets a user enter a month and year. The input value returned is of format YYYY-MMM where YYYY is the four-digit year and MM is the month number e.g. January is 01.


<label>
    <span>Month</span>
    <input type="month" >
</label>

Month

Week input

Use the week input type when you want to accept the week number of a year in your forms. It lets a user set up a picker for the 52/53 weeks out of a year.


<label>
    <span>Week</span>
    <input type="week" name="week" >
</label>

Week

Time input


<label>
    <span>Time: </span>
    <input type="time">
</label>

Time:

Date-time local input

The datetime-local input type provides a way to input both date and time.


<label>
    <span>Date and time - local: </span>
    <input type="datetime-local">
</label>

Date and time - local:

Specifying a range

There will be instances where you want to limit the possible values. For example, your form is about a month-long event. You can prevent your clients from setting up a date that is outside your set event by specifying a range. This is done with the minimum(min) and maximum(max) values.


<label for="event">Event date:</label>
<input type="date" id="eventdate" name="eventdate" min="2023-04-01" max="2023-04-30"/>

Event date:

Another use case is preventing inputting past dates, for example when scheduling airplane flights. Specifying the minimum value to date before today is what you want to do.


<div>Today is: 2022-12-01</div>

<label for="flightstartdate">Event date:</label>
<input type="date" id="flightstartdate" name="flightstartdate" />

Event date:

Limit the week input to a certain year, e.g. selling monthly tickets for a sports season.


<label>
    <span>Event Month</span>
    <input type="month" min="2022-01" value="2022-12" >
</label>

Event Month

The format for the min and max setup for the week input type is “year-week number” e.g. 2023-W01 for the first week of 2023.


<label>
    <span>Week</span>
    <input type="week" name="week" min="2023-W01" max="2023-W52">
</label>

Week

Adding Suggestions

Using datalist element we can add hardcoded values as options to a date input. A great use case for this is suggested dates for restaurant reservations in the current week.

Date input with datalist


<div>
    <label>
    <span>Recommended dates: </span>
    <input type="date" list="recent-dates">
    <datalist id="recent-dates">
        <option value="2022-01-01">
        <option value="2022-02-14">
        <option value="2022-05-01">
    </datalist>
    </label>
</div>

Recommended dates:

Time input with datalist


<label>
    <span>Popular hours: </span>
    <input type="time" list="popularHours">
    <datalist id="popularHours">
    <option value="12:00">
    <option value="13:00">
    <option value="14:00">
    </datalist>
</label>

Popular hours:

Wrapping up

Support is limited but getting better. Most modern browsers support these input types. Do be wary and check your audience. I still had clients who stuck with IE until IE11 was decommissioned. For old browsers, the input type will default to a regular input text box. Make sure to provide a fallback in those cases.

I am glad we have native options for something ubiquitous as requiring a date/time input. Try using these new input types in your next project.

Rock-Paper-Scissors-Lizard-Spock Game

Sun, 20 Nov 2022 02:13:00 GMT

I am a big Big Bang Theory fan. So is my wife. Her absolute favorite character is Sheldon Cooper. In one of the episodes Sheldon proposed an improved version of the rock-paper-scissors game. This version extends the possible moves to five(5). The additional two options would increase the possibility of win chances as it minimizes the chance of both players picking the same move.

I made a javascript version. Using a few emojis for the hand graphics. I made a very simple interface

Game logic

The game logic is pretty simple.


build gameboard

:play
  get user move
  get computer move
  get win_or_lose
  increment round
  if (round equals max_round) goto display_winner
  goto play 

:display_winner
...
end game

To check who wins per round we need to know the rules of the game (taken from Big Bang Theory wiki).

Scissors cuts Paper
Paper covers Rock
Rock crushes Lizard
Lizard poisons Spock
Spock smashes Scissors
Scissors decapitates Lizard
Lizard eats Paper
Paper disproves Spock
Spock vaporizes Rock
(and as it always has) Rock crushes Scissors

Here are the rules again coded in javascript.


function winOrLose(playerChoice, computerChoice) {

    if (
        (playerChoice === Hands.Scissor && computerChoice === Hands.Paper) ||
        (playerChoice === Hands.Paper && computerChoice === Hands.Rock) ||
        (playerChoice === Hands.Rock && computerChoice === Hands.Lizard) ||
        (playerChoice === Hands.Lizard && computerChoice === Hands.Spock) ||
        (playerChoice === Hands.Scissors && computerChoice === Hands.Lizard) ||

        (playerChoice === Hands.Rock && computerChoice === Hands.Scissor) ||
        (playerChoice === Hands.Spock && computerChoice === Hands.Scissors) ||
        (playerChoice === Hands.Lizard && computerChoice === Hands.Paper) ||
        (playerChoice === Hands.Paper && computerChoice === Hands.Spock) ||
        (playerChoice === Hands.Spock && computerChoice === Hands.Rock)
    ) {
        // player wins 
    }

}

I love hash tables! They minimize code complexity. This is a great alternative to the code above.


const WIN_OR_LOSE = {
    [`${Hands.Paper}${Hands.Rock}`]: true,
    [`${Hands.Rock}${Hands.Scissor}`]: true,
    [`${Hands.Scissor}${Hands.Paper}`]: true,
    ...
};


if (!!WIN_OR_LOSE[`${playerChoice}${computerChoice}`]) {
    // player wins
}

The previous bit of code only handle win conditions, what if both players choose the same move? We test this even before testing win conditions,


function winOrLose(playerChoice, computerChoice) {
    if (playerChoice === computerChoice) {
      // show tie result  
      return;
    }
    ...
}

Finally, we test if the game has ended. Whenever a round ends, we check if the game should end(finished 10 rounds). If yes, we calculate the game result and notify the user.

  function gameOver() {
    let [yourScore, pcScore] = score;
    if (games >= maxGames) {
      done = true;
      if (yourScore === pcScore) {
        gameResult("It's a draw!", "tie");
      } else if (yourScore > pcScore) {
        gameResult("You win!", "win");
      } else {
        gameResult("You lost!", "lose");
      }
      return;
    }
  }

User interface

For the input, I made five(5) buttons with images corresponding each game move. When the game starts you are prompted to choose a move. When the player chooses a game move, it’s checked agains winning conditions and depending on the outcome computes the score.

Rock-paper-scissors-lizard-spock game buttons

Play the game. Enjoy!

Creating My Animated Bottom Bar Experiment

Sat, 19 Nov 2022 01:07:00 GMT

I wanted to see how much we can do with CSS transitions. No keyframe animations at all. Although you would have more control over the animation with keyframes. For our demo, we need a simple change from one state to another. CSS transitions are all we need.

In one of the animations, I used a technique I call the Sibling-Follow technique. Before you ask, I did not invent this technique - just the name. It’s nice to name something when it’s this good. I got it from one of the front-end sites - I forgot which.

When I understood the technique, my brain ran on overdrive. I was sketching different designs I can abuse this technique. I used this to animate the highlight element in the codepen below.

Sibling-Follow Technique

To illustrate, let me walk you through a simple tab bar animation. If you are familiar with Material UI tabs, it behaves very similarly.

Material UI tabs

Make a list of buttons. Then, add another element and set the class as follow. We will use this to target and style the element later.

HTML

<ul>
  <li> <button> button 1 </button></li>
  <li> <button> button 2 </button></li>
  <li> <button> button 3 </button></li>
  <li> <button> button 4 </button></li>
  <li> <button> button 5 </button></li>
  <li class="follow"><li>
</ul>

CSS


ul,
li {
    display: flex;
    list-style-type: none;
    margin: 0;
    padding: 0;
}

ul {
    position: relative;
}

li {
    width: 50px;
    padding: 5px;
}

.follow {
    position: absolute;
    top: 0;
    left: 0;
    transition: left 0.4s ease-in-out;
    height: 2px;
    background-color: red;
}

I made a Javascript event handler to add the active class to the list item containing the button I clicked.

<ul>
  <li> <button> button 1 </button></li>
  <li class="active"> <button> button 2 </button></li>
  <li> <button> button 3 </button></li>
  <li> <button> button 4 </button></li>
  <li> <button> button 5 </button></li>
  <li class="follow"><li>
</ul>

Using the sibling selector(~), we apply the desired styling for .follow element. In this case, I want to position the mentioned element above the second list button.


li:nth-child(2):active ~ .follow {
    left: 60px;
}

I added the other left positions to the rest of the li items with some trial and error.

Voila! We get a simple highlight animation, ala Material UI tabs, with a few markup and the magic of CSS transitions.

For my demo, I hardcoded the left property to the CSS for each transition state. Add a Javascript function to calculate these coordinates for you. Then you do not need to hardcode these values, especially if you are going to incorporate this into your professional work.

You can make it fancier by animating the width of the follow tab at different speeds. Apply different easing functions. Make many follow elements running at various vectors. I will let you play with that on your own. Let your imagination run free.

I made five tab bar styles. Feel free to use these in your projects.

Wrapping up

You can make pretty amazing things with CSS, HTML, and a bit of Javascript.
Sibling-Follow technique is a simple method you can use to create tab animations.
CSS transition is your friend if you want to animate a simple change from one state to another.

All in all, I was happy with the outcome of this exercise. I had so much fun and learned a lot. We could use some accessibility work though. 😜 That is something we can work on for another day.

I will explain the other animation styles I made with this pen later.

Update: This pen got showcased in a Codepen Spark newsletter last April 14th (link below). Thanks Codepen!😀🎉

Tab Bar Styles, AI Games, and Some Good Forking News (April 14).

Build an Accessible Tab Container

Mon, 10 Oct 2022 01:07:00 GMT

As part of the work I do for my employer, I analyze UI elements on our product to check if we need to re-engineer the component to improve accessibility. One of the accessibility challenges I have reworked for our company site is the tabbed container.

Imagine a folder with pages you can flip through using tabs at the edges. That is the closest I can imagine when I think of tabbed containers. This concept is very straightforward, tabs on top of the container serves as buttons to access the corresponding grouped content. Only one grouped content is shown at any time. I love tabbed containers because they are very good at cleaning up the interface when you have so much content but have the same level of importance.

For the new component, I based it on the tab panel pattern suggested in the WAI(Web Accessibility Initiative) site.

Focus Order

Using the keyboard with the old tabbed container, the focus goes from the first tab, 2nd tab, 3rd tab, and so on. Then the tab content 1, etc. One would need to finish traversing the tabs before you can access the first tab’s content. Its confusing to screenreader users as you would assume when you focus on the tab you can read the content.

The navigation sequence does not follow the natural way of content consumption.

To improve the focus/read order, we should make the first tab active and prevent the inactive tabs from getting the focus sequence. Navigation will go directly to the content when tabbing from the tab button. Another rule some UI developers forget is to make sure hidden elements do not get focus. So for the previous example, the “Services” and “Products” content panels and its content must not receive focus.

Now the user is only able to access the currently active tab and tab content

Keyboard controls

The old tab container component only supported the Tab key to navigate which only follows the DOM sequence. A few tabs are tolerable but once you get more than five(5) tabs it can be annoying for the user to use.

To make the component keyboard accessible, we add behavior that follows the WAI tab panel pattern. The tab navigation activates once the focus goes to the active tab (button). Using the Arrow Left and Arrow Right, the user can navigate to the previous and next tabs correspondingly.

Additionally, you have two types of tab container behavior. Automatic tab containers will switch to a new tab when focus changes. While, Manual tabbed containers use Enter or Spacebar key to confirm the switch. I will use the “automatic” behavior for our demo.

The active tab shows focused styling when navigating with the keyboard. Using the arrow keys we can navigate to other tabs.

ARIA attributes

Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

- MDN

It would have been nice if there was a tab panel semantic tag. There is none so we use ARIA attributes. On their own ARIA attributes do not do much. It does not add styling or extra behavior. But for screen readers or tools that aid people with impairments, ARIA attributes paint a picture that a browser can interpret.

For the tabbed container, we set the following ARIA attributes.

ARIA attribute/role	Description
role=tablist	Container for tab buttons
role=tab	Tab button element. Contains the label for the currently active content.
role=tabpanel	Container for the currently active tab content
aria-selected=true	Tab button is selected and content is visible
aria-selected=false	Tab button is inactive and content is hidden
tabindex=-1	Removes the element from tab order sequence. We use this for the inactive tabs and hidden tab content. Aids in focus management.
aria-controls=ID	Set on the tab button. ID refers to the associated tab content
aria-labelledby=ID	Set on the tab content container. Refers to the tab button serving as a label for the content.
tabindex=0	Set on the tab content container. Puts the container back to tab sequence

Our tabbed container in action

Accessible UI Component Series

Thu, 19 May 2022 21:24:33 GMT

A short series of accessible UI components built on one shared “Codespud” design-token file, so I could test ARIA Authoring Practices patterns myself instead of trusting a component library blindly.

Two more pieces from the same series already have full write-ups: the accessible tab container and the focus-within fixes for common hover-only UI patterns.

Accordion

Disclosure pattern using aria-expanded, aria-controls, and role="region" per the ARIA APG accordion pattern, with animated expand/collapse and visible focus states.

Accessible buttons in claymorphic styling

Proof that an on-trend visual style (claymorphic / soft-UI) doesn’t have to come at the cost of accessible markup — real <button> elements, visible focus rings, and sufficient contrast underneath the styling.

Shared design tokens

Both components above (and the tab container/accordion pair) pull from one typography and color token file — a small design system built with accessible contrast ratios in mind from the start.

More CodePen experiments: codepen.io/chrisbautista

Mobile Pet Gallery

Tue, 12 Apr 2022 05:41:39 GMT

A CodePen challenge entry: a pet adoption gallery sized to a phone, with two views — a thumbnail grid and a full-bleed carousel — and a transition between them that runs on CSS alone.

The experiment

The question was how much of a layout change CSS transitions can absorb before you need JavaScript to animate it. The answer: more than expected, as long as you transition the container rather than the items.

The two views are one DOM tree. A hidden checkbox holds the mode, and the sibling combinator (.mode:checked ~ .gallery) swaps the gallery between a wrapped flex grid of 110px thumbnails and a single-row flex track of 360px slides. The transition list on .gallery — left, width, height — plus width on each figure means the browser tweens the reflow. Clicking a thumbnail unchecks the box and slides the track to that index; the home button re-checks it and returns to zero.

Paging is the same trick applied to a smaller element. Six dots sit behind a single dark “follow” dot, positioned by .active:nth-child(n) ~ .follow rules and transitioned on left, so the indicator glides to the current page instead of the page repainting. A short scale keyframe fires on arrival, restarted by the usual clear-animation/force-reflow/restore dance since animations don’t replay on their own.

JavaScript does the bookkeeping only: track the index, set gallery.style.left, toggle the active dot, hide the arrow at either end. Every visible movement is a transition.

Notes

Transitioning left and width means animating on layout properties, which is the expensive path. At six slides in a 360px frame it’s fine; a longer gallery would want transform: translateX() instead. The checkbox-as-state-holder is doing real work here, but it’s a hack — the mode toggle isn’t announced to assistive tech, and swipe/drag handling never got built.

Links

Pen on CodePen
Photos from Unsplash, hosted on CodePen assets

Remote Development Setup

Sun, 19 May 2019 12:07:00 GMT

Tell me if this sounds familiar. You have a workstation that can not support the technology stack your project requires. Having VMs or Docker installed on your machine is out of the question since it can barely support office software. You end up building a development machine(perhaps an Linux box) as a desktop server. This works well for a while until you need to access your development setup remotely. Luckily there’s a number of ways you can achieve this.

The Options

Local editor/IDE via SFTP. - This entails connecting via SFTP and uploading the code changes manually. Problem with this setup, you need to run a lot of steps to test your code. Upload (manually) then run tests, rinse and repeat. Don’t expect to use any IDE functionality here. Not very useful but it works when the need arises. I recommend using WinSCP on windows for this.
Local editor/IDE with automatic syncing via an SFTP client. - Very similar to the first option minus the manual uploads. Some SFTP clients would have a “sync on changes” option. WinSCP has the “keep up to date” feature which serves this purpose well.

For Apple machines, Panic’s Coda/Transmit setup is a great example.

Additionally, using a plugin, some editors/IDE’s (e.g. SublimeText, VSCode, etc.) would be able to carry out the same use case. In my experience though, managing files via plugin is not very consistent. When it fails, it fails spectacularly with me ending up trying to resolve corrupted files.

Local IDE using rsync - This setup leverages rsync to synchronize your changes automatically. Using rsync is similar to using SFTP with automatic syncing. The difference is that rsync by default only upload/download files that changed. The most popular setup is to watch for file changes and then trigger a rsync command to upload only the delta. No manual uploading but not very different from the first one on this list. You can use inotifywait or gulps watch functionality to monitor file changes then manually trigger a function or command based on rsync.

Using inotifywait,

#watch_and_sync.sh

#!/bin.ssh
while inotifywait -r -e modify,create,delete /directory; do
    rsync -avz /directory /target
done

Using gulp and gulp-rsync,

npm install gulp-rsync --save-dev

//gulpfile.js
var gulp = require( 'gulp' );
var rsync = require( 'gulp-rsync' );
gulp.task( 'watch', function() {
  var watchFiles = [
    './src/**', './templates/**'
  ];
  var watcher = gulp.watch( watchedFiles, ['sync']);
});
gulp.task( 'sync', function() {
  return gulp.src( 'js/**' )
    .pipe( rsync({
      hostname: 'remote.server.com',
      destination: '~/project/'
    }));
});

Local IDE using SSHFS - SSHFS(Secured SHell File Systems) can mount directories and files from remote machines as if they were local folders. Using this logic you can set up your remotely available codebase into your local IDE. This is very easy to put up since most Linux machines support SSH and it does not need any other libraries to install and configure. Although useful it’s not very consistently executed in most clients. For windows, check out NetDrive and WinSFP
Remote editing using vi/vim - Developing using vim on the development machine is a very powerful setup. This requires opening a terminal and connecting to the remote machine via SSH. Then navigating to your code base and running vim. You use vi’s powerful text editing features to edit files. A bit of tweaking and installing some vi/vim plugins would make vim work more like an IDE. The problem most have is the learning curve but once you get around the idea of coding on the terminal, you might end up loving it or not. :) Another minor issue is when you need to upload new files like images and PDFs. If you’re used to dragging and dropping your files into your IDE this might be off-putting. You will need a separate SFTP client to do upload these files.

Here’s a link to my vimrc. Search through Github there’s no shortage of excellent vim configurations that might fit your liking.

    "====================
    " vim workflow
    " @chrisbautista "codespud"
    " features:
    " - asynchronous linting
    " - prettier
    " - dark theme
    " - tree file view via NerdTree
    " - fuzzy file search
    " - more info on status and tab lines
    " - keyboard mappings
    " - php debugging
    " - use , as <leader>
    "====================
    
    //...

My recommendation to you is to use vim without modifications. Once you get the hang of it, you might NOT even need plugins.

Remote editing using a cloud editor - This has been quite popular lately. My favorite is Cloud9 IDE. Even Amazon Web Services(AWS) uses it for its cloud services.

Using the Cloud9 IDE project you can set up any code base and make it available via the browser. It is not as powerful as Eclipse ( or clones e.g. PHPStorm, Netbeans) but it keeps your code and tasks in the same machine — not yet at least. But it is significantly better than most options in this list as its very similar to how you would develop in a regular IDE. Most would have terminal emulation as well and support for plugins. The problem is you can’t really do this for all your projects. Since you will be exposing the editor via the browser you still run the risk having your code hacked easier than without it. Like any internal application, there are ways to secure it.
```
# Install
git clone https://github.com/c9/core.git c9sdk
cd c9sdk
scripts/install-sdk.sh

# Start Cloud9 and expose /var/www/html
node server.js -w /var/www/html
```
VSCode with remote development pack - To be precise, the Remote development pack is only available through VS Code Insiders edition as of yet. No local code needed locally when using the remote development pack. The best benefit is all your beloved VSCode plugins can run on the code as if it’s local.

Aside from SSH, the pack also include support for container setups(Docker) and Windows Subsystem for Linux (WSL).

To install Remote development pack: SSH

- Install an [OpenSSH compatible SSH client](https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client) if one is not already present. 
    I recommend installing [Git Bash](https://git-scm.com/downloads) for windows. 

    Note: PuTTY is not supported on Windows since the ssh command must be in the path.
- Install [Visual Studio Code Insiders](https://code.visualstudio.com/insiders/). 
- Open **Visual Studio Code Insiders** then open modules
- Search for [Remote Development](https://code.visualstudio.com/insiders/) extension pack, then hit Install.

From VS Code documentation

>   [Optional] If your server requires multi-factor authentication, set "remote.SSH.showLoginTerminal":"true" in settings.json 
>   and enable the [ControlMaster](http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/ssh_config.5?query=ssh%255fconfig%26arch=i386#ControlMaster) SSH feature. See here for details.

Security

Since your code base needs to be accessed in the cloud, security is very important. Most of these setups use Secured SHell since its more secure than FTP and not to mention a lot of firewalls would have SSH open. There are also some features you might want to keep to secure SSH further.

Never let login with root (PermitRootLogin=no) and create sudo-users
Enable key authentication (PubKeyAuthentication=yes)
Limiting the service to a specific host and address instead of listening to all interfaces.

(ListenAddress=hostname:port)

Create Private keys with passphrases

There are other SSHD configuration options that can further secure your connection. Check some recommendations from ssh.com

For Cloud editors like Cloud9 IDE; Enabling SSL(HTTPS), gating(strong password) and limiting access to known networks will keep your risk to a minimum.

Recommendation

I still prefer using vim for remote development but having an IDE setup like VSCode with Remote Development pack comes with great benefits which a developer like me finds quite appealing. Having to use a graphical UI for engaging my code base not to mention having some great plugins for language support is a major plus. But I digress, this is not an article to compare the benefits of IDEs in development. :) I’ll let you decide on that on your own.

It really depends on what’s available for you and how comfortable you are in different environments.

Image attributed to Microsoft VS Code Documentation.

How to Use Custom Domains with Github Pages

Mon, 22 Apr 2019 14:20:00 GMT

Hosting a project wiki or a personal blog on Github is very easy with github-pages and static site generators like Jekyll. You will end up with a site hosted on <Project/Repository Name>.github.io, if you’re happy with that then skip the rest of this article. If you want more or just curious about the steps then keep reading.

What you’ll need

Domain hosting
Github hosted static site (gh-pages branch)

Steps

Setup your domain hosting

As an example, I am using Godaddy’s admin panel. Your mileage might be different but most domain providers will have similar tools for you to use.
1. Add a A entry to 185.199.108.153 with the following details.
  - Host: @
  - Points to: 185.199.109.153
  - TTL: 600 seconds
1. Do the same for 185.199.109.153, 185.199.110.153 and 185.199.111.153.
2. Add a CNAME with the following details:
  - Host: www
  - Points to: -----.github.io
  - TTL: 1 hour
3. Save your settings.
Update: It seems Godaddy has upgraded their interface you need to add those entries and the settings are automatically saved for you.
Setup Github Pages
1. Switch to your gh-pages branch and create a text file with your domain (e.g. www.codespud.com)Save it in the root of your static site.
1. Navigate to Settings > Options > GitHub Pages
1. Point branch to gh-pages branch
2. Fill in your domain. In my case, it’s www.codespud.com.
3. Enable ‘Enforce HTTPS’, if the option is enabled. Sometimes it will indicate you need to wait for 24 hours. Just check again later and enable it if you’re allowed to. If you have a different issue checkout Github article on troubleshooting custom domains.

NPM package

If you’re familiar with npm, you can use gh-pages cli to setup this for you.

npm i -g gh-pages

Before you can deploy to gh-pages. Remember to create the CNAME text file I mentioned earlier in step 1 of Setup Github Pages.

Point it to your static site code, e.g. (dist folder)

gh-pages -d dist

This will set up your Github pages with the content of your dist folder and point it to whatever domain you specified in CNAME.

Conclusion

If everything went well. You should have your Github hosted site using your shiny new custom domain. :)

Morsecode-Potato

Tue, 28 Aug 2018 19:21:31 GMT

Morsecode-Potato is an experiment in packaging functionality into reusable React hooks. It translates text to Morse code and plays it back as sound, light, or both.

Role

Sole author. I built the hooks and the demo app:

useMorse — translates text to international Morse code (ITU-R M.1677-1) and returns a Morse string.
useMorsePlayer — plays a Morse string as audio, as a silent visual signal, or both in sync. One clock drives everything, so sound and light can’t drift.
Demo page — a Tailwind-styled React app themed after an old-time telegraph station, with an input text area, playback controls, and an abbreviation reference table.

Demo page in light theme

Demo page in dark theme

Links

Make Your Bash Prompt Work For You

Mon, 14 Nov 2016 04:08:17 GMT

If you work with Linux or Unix-like operating systems like Ubuntu or the MacOS, you might be familiar with Bourne-Again Shell or BASH for short. This article will show you that with a little elbow grease, you can have your BASH prompt work for you and heck maybe have a little fun with it.

People tell me the invention of the GUI (graphical user interface) is the best thing that ever happened to modern computing. I beg to differ. Not all work is accomplished through the GUI nor is it efficient.

I find myself working on the command line for work more and more — managing my servers even my Apple computer. So I get to spend much of my time on the command line. Launching commands like a stenographer recording the latest court drama. I realized very early how powerful the command line could be.

But not having a GUI does not mean you should be happy with the default command prompt. Is this familiar?

Boring command prompt!

Using the table below we can build a BASH prompt that is not only pretty but saves us a few keystrokes as well.

BASH Special Characters Reference

<th align="left">
  Description
</th>

<th>
  Special character
</th>

<th align="left">
  Description
</th>

<td>
  an ASCII bell character (07)
</td>

<td align="center">
  \d
</td>

<td>
  the date in &#8220;Weekday Month Date&#8221; format (e.g., &#8220;Tue May 26&#8221;)
</td>

<td>
  end a sequence of non-printing characters
</td>

<td align="center">
  \e
</td>

<td>
  an ASCII escape character (033)
</td>

<td>
  the hostname up to the first `.&#8217;
</td>

<td align="center">
  \H
</td>

<td>
  the hostname
</td>

<td>
  the number of jobs currently managed by the shell
</td>

<td align="center">
  \l
</td>

<td>
  the basename of the shell&#8217;s terminal device name
</td>

<td>
  newline
</td>

<td align="center">
  \r
</td>

<td>
  carriage return
</td>

<td>
  the name of the shell, the basename of $0 (the portion following the final slash)
</td>

<td align="center">
  \t
</td>

<td>
  the current time in 24-hour HH:MM:SS format
</td>

<td>
  the current time in 12-hour HH:MM:SS format
</td>

<td align="center">
  \@
</td>

<td>
  the current time in 12-hour am/pm format
</td>

<td>
  the current time in 24-hour HH:MM format
</td>

<td align="center">
  \u
</td>

<td>
  the username of the current user
</td>

<td>
  the version of bash (e.g., 2.00)
</td>

<td align="center">
  \V
</td>

<td>
  the release of bash, version + patchelvel (e.g., 2.00.0)
</td>

<td>
  the current working directory
</td>

<td align="center">
  \W
</td>

<td>
  the basename of the current working directory
</td>

<td>
  the history number of this command
</td>

<td align="center">
  \#
</td>

<td>
  the command number of this command
</td>

<td>
  if the effective UID is 0, a #, otherwise a $
</td>

<td align="center">
  \nnn
</td>

<td>
  the character corresponding to the octal number nnn
</td>

<td>
  a backslash
</td>

<td align="center">
  \[
</td>

<td>
  begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
</td>

<td colspan="3">
  the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format results in a locale-specific time representation. The braces are required
</td>

Special character
\a
\]
\h
\j
\n
\s
\T
\A
\v
\w
\!
\$
\\
\D{format}

Change the Bash Prompt

The environment variable we want to modify is PS1.

Using the reference table above we can break down the current prompt as

\u – the current user
\h – the computer’s hostname
\w – the current working directory

Not very useful is it? Let’s change that.

By modifying the PS1 variable and exporting it with the command below we can manipulate the prompt to output anything we want.

Add a smiley

Below is my favorite bash prompt which I install for all my servers and even my workstation. I can easily see important details like the hostname – very important if you find yourself managing multiple terminal windows and you can distinguish between windows. This configuration also shows the load averages, the current date and time and the working directory. The color helps to give it contrast to the monotonous black on white default of most terminal windows.

Make it Permanent

To make your BASH prompt permanent, just edit ~/.bash_profile or ~/.bashrc or ~/.profile or run the command

Ideas

Count the files in the current directory
Display in blinking colors the last line of a todo list
Display CPU/Memory/Disk usage
Display command to pull up a help screen
Echo a smiley if the system is working in top condition

There you have it, you can now work on the command line with a little bit more help. The key here is to be creative and think of what you want your bash prompt to have. Enjoy!

BoxerJS

Mon, 02 Mar 2015 23:06:34 GMT

A lightweight jQuery plugin that turns links to images into quick inline previews.

BoxerJS wraps image links so they open as fast previews instead of full page loads. It supports images and HTML snippets loaded over AJAX. See the demo for live examples.

Install

Download the files.
Copy boxer.js, boxer.css, and close.png into your project.
Include boxer.js and boxer.css.

Wrap your target anchors in a container:

<div class="boxer">
  <a href="picture1.png" title="this is a picture">
    <img src="picture1_thumb.jpg" />
  </a>
  <a href="picture2.png" title="this is another picture">
    <img src="picture2_thumb.jpg" />
  </a>
</div>

Initialize it: $(".boxer").boxer();

Role

Sole author. I designed and built the plugin, its preview/overlay behavior, and the AJAX snippet support.

Links

How To Make A Timer/Stopwatch Using AngularJS

Sun, 28 Sep 2014 18:09:50 GMT

I’ve got some leeway pushing Khrunus off the ground. I’ve always been successful using JavaScript’s timing functions but since Khrunus would primarily be built-in in AngularJS. I have to research a way to reuse my timing snippets into proper Angular code. To study, I built a simple angular app:

Problem

How to use AngularJS to make a time-related app, in this case, a timer for logging elapsed time?

What I need

Before I started this little venture, I need to detail the parameters of the experiment.

Firstly, I need to layout my application into two sections. The top section will show a digital clock face and a button to toggle(start or stop) the clock. The bottom section will be a table showing start and end times, as well as the total duration. To know that the application is successful, start and end times should be logged. Using those values I can compute for the duration.

We have two modes; an idle state,”stopped” and an active mode,”started”. We need to consider that when coding the helper functions.

Solution

Firstly, we start with a basic AngularJS template. Please note I am assuming you have at least some experience working with HTML, Javascript, and AngularJS.

I need two sections so I make two main DIVs.

Next, in DIV 1, we add another div to serve as the container for the timer digits and a button.

Next in DIV #2, we format a table with a header and three columns; “Start”, “End” and “Duration(secs)” correspondingly.

What we have now is not very pretty, we’re going to fix that in a bit. Create a CSS file, call it “app.css”. Let’s style everything as follows,

Looking good! 🙂 Now to add the functionality we need. Let’s start with some data binding and a basic controller.

HTML

Javascript

Awesome! For the button, we’re going to use that as a trigger to toggle between modes as well as an indicator to show the user what’s happening.

Now, we can switch between modes, using the button data {{mode}} as a toggle flag. Now to the meat of the application, as a reference I’m going to use this basic clock code I use when I need digital clock displays.

The hero of this application is AngularJS’s $timeout service. The $timeout service gives the user a wrapper for window.setTimeOut. So it still acts like setTimeOut but with the code organization and excellent exception handling that AngularJS provides. Our code should follow this format

We build the clock functionality via a $timeout statement, but first let’s refactor our controller and add two functions to handle the Start and Stop modes.

Now for the $timeout service,

You can see that we used the timeout service to recursively call the StartTimer function. When you call $timeout, just as window.setTimeOut, you create a timing object that we then save to our variable ‘tmPromise’. We’ll get into more of that later just take a note of it. Since we’re really making a stopwatch and not a clock that tells the current time, let’s recode. We need the current time so we use date.getTime(). Adding two more variables timeStart and timeEnd. When we button is clicked, we save the time to timerStart. Every time the timeout completes and we call StartTimer, the value of $scope.timeEnd changes. We then subtract $scope.timeStart to get the current elapsed time in milliseconds. We add some normalization code and we end up with this,

Now for the stopTimer function, issuing the cancel method will stop the $timeout service. Remember the variable we made earlier, ‘tmPromise’. We will use that as the parameter for our cancel call illustrated below. We then collect the start and end times and push that into the history array.

Conclusion

Yay, we just made an AngularJS timer widget. Adding a service to insert a line in our table we end up with this.

This is a very simple implementation. One that did not need a unit test but if we wanted to, we can use a $timeout.flush() method. More details from the reference links below.

See the app in action here

** UPDATE: Code sample here here

Download all the source here.

References

Quick and Free Way to Set Up Your App using Heroku

Sun, 20 Apr 2014 20:52:49 GMT

I had a struck of inspiration earlier this week. I’ve always wanted to make this webapp that has been playing in my mind for a while and I finally had some ideas to start on. Of course, like any of my projects, the first thing I do is research. First in my list was a workflow to streamline development. It’s been a while since I modified my workflow and so I thought it was time for a change.

Aside from the design and flow of the application, my immediate concern was where to host my apps once I’m done with the first milestone. I was researching around the interweb and a familiar link caught my eye. Heroku was the 2nd link of my search. I investigated Heroku when I first made a Facebook application for Lowe Philippines. I remember seeing a link to Heroku from Facebook’s “Create App” wizard. Back then I was more curious than impressed. Anyway, this time I was very curious but now I’m also very impressed with how Heroku made it easy to deploy an app. Heroku does not magically build a scaffold for you but it does guide you through steps in their “Getting started” page and heck it’s free.

What you get for a free account?

One(1) Dyno
10,000 rows of data (postgres)
512 Mb RAM
One(1) hour business-hour support

A dyno is a processing unit coined by Heroku. Heroku help says “A dyno is a lightweight container running a single user-specified command. You can think of it as a virtualized Unix container—it can run any command available in its default environment”. It’s a lot to take in but it simply means you have one worker processing requests and things for you to serve your website and other arbitrary functions like data requests. One seems not a lot but with how fast this requests gets done you won’t even notice, unless of course your application gets some substantial traffic. Aside from the dyno, you get to save 10000 rows of data to Postgres and a generous 512Mb RAM allocation. If you think your application will need more resources, you can scale up by buying more dynos. But for a hobby app or POC, a Heroku free account will serve you nicely.

How to start?

Heroku is very easy to setup. You can go straight to the toolbelt and the dashboard or you can go to their Getting Started page, which I recommend if you’re starting to learn or new to deploying to Heroku.

Getting Started <- start here

Heroku supports a number of languages including PHP, NodeJS etc. This time I was making a PHP application with some AngularJS for the frontend so I followed the PHP track. Anyway, I just did the steps and I got a functional workflow as a starting point.

In summary the steps are:

Download and Install Heroku Toolbelt for your OS.
Login to Heroku
Get keys
Create App
Deploy App with git push

Is that it?

You followed the steps, and you got a lean file structure to start with. You have to ,of course, be familiar with Composer and Git to optimize your project, both of which are not covered by this post. Just google them, there are a lot of well written articles and tutorials out there. I especially like the ff:

https://getcomposer.org/doc/00-intro.md

https://www.atlassian.com/git/tutorial/git-basics

Final thoughts

The cool thing about this is everything is accessible and manageable from one console. If you’re a little queasy at the idea of working with the console, this might not be the best thing for you. An alternative is the Heroku dashboard – just create the app and setup a more familiar way of deployment like github. Just provide Heroku of a repo and Heroku will monitor and automatically deploy your app when a change is uploaded.

Heroku is neat and well documented. There’s a bit of a learning curve especially if you’re starting to learn to code or is a total console-phobe. Also, if you’re app has grown popular and pulling some substantial traffic, you need to increase the dynos or your app will shutdown and refuse to process requests. Which will catch a hefty bill. Nevertheless, it does get you started with some impressive workflow and and it’s free-ish. 🙂

Some notes:

First time you push a project (git push heroku master) and it’s empty, it would trigger a error similar to this

! Push rejected, no Cedar-supported app detected

It just means, Heroku does not know what your app is about and so it can’t build the application. Solution is just provide a common starter file like index.php or index.html. This will tell Heroku that you have a PHP or HTML project and build the necessary dependencies. You can also fix this by providing a composer.json, setting up the dependencies you need.

Self: AWARE

Fri, 29 Jun 2012 21:18:35 GMT

Self is an award-winning iOS app for the AWARE Foundation of Singapore.

Most women do not report domestic violence, verbal or physical, because they have no evidence to prove it. When activated, this app monitors for a spike in ambient sound (for example, shouting) and automatically starts recording, saving the audio to a hidden folder the victim can later use as proof of abuse. It can also send an SOS via SMS to a nominated contact when the sound level crosses a set threshold.

Role

I built all of the server backend for user management and SMS processing, using the Slim PHP framework for its small footprint. The initial iOS version was created by a contractor; I later took it over and maintained the whole app, applying Noel Perlas’s flat design when it was updated for iOS 6.

Credits

Concept — Dominic Stallard
Creative direction — Noel Perlas, Eranga Tennekoon, Mandar Wairkar

Awards

D&AD Wood Pencil, 2014
Creative Circle Awards — part of Lowe Singapore’s 29-award haul
Spikes Asia 2013, Mobile

Install Twitter Search Widget

Mon, 19 Oct 2009 04:40:00 GMT

When I started blogging again last September, I was delighted to get a template with built-in message polling to twitter. I played with it a bit and settled with the look you see at the right. I am not a prolific ‘twitterer’, but I love the whole concept of micropublishing.

Sometimes when I feel lazy but I want something new in potatokorner; I’d post a tweet, from quotes to funny videos, just to see the widget change(LOL). Great as it is – it’s not perfect. What the widget lacks is interactivity. One day, I started planning (with frameworks like Jquery and Mootools in mind), to make a custom widget that can access twitter API with features like searching for a user’s tweets or scrolling through a Trending Topic . Also thought adding some nice animation and CSS styles. Luckily, I don’t have to; the nice peeps from Twitter beat me to the punch and released a widget – packing almost all the things I wanted. I experimented with this along with some feed scripts from Google a days back (Updates on Pepeng).

The widget’s concept is to supply the it with a search term (or phrase), like ‘potatokorner’ and it will periodically check twitter.com for tweets with the word potatokorner – but not just tweets by yours truly – every single tweet which it appears. Unlike a regular search the widget periodically pulls messages from the site(twitter) and displays it in a marquee. Twitter.com describes it,

“Displays search results in real time! Ideal for live events, broadcastings, conferences, TV Shows, or even just keeping up with the news.”

Making your widget is easy. Log in to twitter.com. Open the Settings page, then click “You can add twitter to your site here”.

You are asked where you want to place your widget, click “My Website”.

Then, you are presented three widgets, choose the “Search Widget”.

Now what you have before you is the heart of the “search widget” configuration.

You’ll learn when you’ve finally playing with your new widget that it’s a parsing nightmare when people add tags even if their topics are not related, especially when it’s a “trending topic”. Fortunately, Twitter.com provided quite a collection of filters to narrow down your search. You can limit tweets to a certain vicinity( near:{location}) or screen out certain words ( -{word}), you can even limit them to happy ones ( 🙂 ). See Advance operators to build your strings. I won’t touch this much, but I’ll explain what I’m going to use.

For our example, I want to add a twitter search widget to find tweets with the word “party”, but I only want positive or happy tweets! , thus the smiley, ” 🙂 “. The smiley is a generic one, but twitter is smart enough to find all the variations (e.g. “:D”,”=)” etc. ). Now lets test it.

Great! It’s working. As you can see, there are only a few tweets shown. It gives it an air of history unfolding. If you like it to show all the tweets in history at once, we’ll move to that later. Now that our search string is tested and working. You have the option of changing the “Title” and “Caption”. Lets leave the title alone and match our search string to the Caption.

So far so good, let’s see how we can configure tweets. Choose preferences. This tab controls how your tweets will look and behave.

Enable “Poll New Results?”, if you want the widget to continue checking the public timeline of relevant tweets to your search. (Default: Checked)

Enable “Enable Scrollbars”, if you need to be able to review the rest of the resulting tweets without waiting for it to loop. (Default: Checked)

Behavior has two values, its either “timed interval” or “load all tweets.” Default behavior is timed interval – tweets are shown one at a time, kind of like a news marquee. When set as timed interval, you have an option to set how much time it takes before showing more results(Interval). You can also set if you want it to repeat the results when all the tweets have been shown(Loop Results).

“Load all tweets” on the other hand, set’s the widget to show all the tweets related to your search – all in one go. No fancy animation. Kind of boring to me, but someone out there might have a use for it.

For our example, let’s leave it as is.

For really large results, you can increase or decrease the number of tweets to show.

Finally, you also have control over how your tweets will look like. If you only need the messages without people’s faces polluting the content area, unset “Show Avatar”.

If the time the message was sent doesn’t interest you, you can remove it by unchecking “Show Timestamps”.

Finally, if seeing hashtags so many times is starting to strain your eyes, hide it by unchecking “Show hashtags”. I find helpful when my search word is a hashtag.

Now for aesthetics, lets change colors to match my site.

I’ll leave the dimensions as is. Unfortunately, you can not test the numbers you have set for the widget. You just have to see how it looks in your page – and decide if you need to adjust. Note you can let the widget grow into the container you want to place it, or if you’re just not sure how to adjust it to fit your site – you can try setting “auto-width”.

I’m happy with the results, click “Finish and Grab Code” button to get the code. See our results below.

Simply insert the code into your page’s html and you’re done. see results here

There you have it, shown you how to get the widget. Now go play with your new toy! If you have a problem installing, just leave a comment or email me at questions at codespud dot com.

Some closing tips

If you’re using a fluid-width layout, you might find auto-width useful.
Use the minus operator(-) plus word (you want to leave out) in the search parameter to narrow your search.
If you’ll remove the scrollbar, enable “Loop results” so you’ll be able to see all the results.
I found the optimum interval for showing tweets is 5 secs, but of course it depends on what you intend to use it for.
Sometimes, you can clean your results by showing hashtags and filtering unwanted tags out with minus(-).
Enable scrollbars if you chose to load all results.

Bit.ly, A Simple URL Shortener

Sat, 17 Oct 2009 23:50:00 GMT

It started with TinyURL, URL aliasing/shortening has become big business with similar sites growing out of the woodwork(See URL Shortening – History). With other unrelated services following the trend, like scr.im(email aliasing) and twt.fm(promotes music), adding value to support our slowly growing twittering society. Bit.ly is one such revolutionary child; but this child has grown big enough to even rival TinyURL.

What so great about bit.ly?

It accomplishes it task, but with flair. I love that bit.ly provides a means for me to track how many clicked the URLs i sent. Might be the reason for it’s sudden increase in popularity for such a short period. It doesn’t hurt either that it’s officially endorsed by twitter.com.

The member’s site has a number of features but I’ll concentrate on URL shortening and tracking.

Above screenshot you see the URL entry tool in RED dashed borders. This is where you jam your uber long URL. Usually, URL shortening is more conveniently done via an API call via a tool in your client software. But if you’re just want your un-memorize-able URL to be easier to carry around or share then the web tool should suffice.

bit.ly, a simple url shortener

All You Need Is A Browser

Mon, 12 Oct 2009 05:02:00 GMT

The web has become more than just a glorified paperless library, now it has become a place where everyone works, plays and meet up. This has become more true with the surge of desktop applications to their web equivalents (email, desktop publishing, spreadsheet etc.) and the advancement in web technologies(AJAX, HTML5 etc). More and more I find myself using online versions of my computer’s desktop. Having been hosted on a remote server I enjoy; savings in storage space, automatic backups, safety from physical hardware damage(like for some of my friends affected by Typhoon Ondoy) and ready support(depends on the service provider). Though you do need to constantly have a decent internet connection, for me it works just fine. If you’re interested, read on!.

What you need?

You need to install Google’s Chrome browser. No specific channel. Though I recommend using “Dev”, for plugin support and cutting edge stuff. Secondly a list of online services that emulates software you normally would install like Gmail/YahooMail(Email), Grooveshark(Music Player) etc. Also, depending on the web application, you might need to register for accounts to use their services.

How?

The secret of this system is Chrome’s create application shortcuts. It’s a menu item inside the page menu, shown below.

Why use this you say, when you can simply bookmark the sites URL. Firstly, making webapps as application shortcuts makes them readily accessible; without the extra steps of opening a browser and finding the bookmark. Also, to get the illusion of a desktop app, we need the chrome(extra browser sections like the menu bar, status bar etc) to disappear(See below) leaving only the application in its intended glory.

What is more awesome is whatever favicon image the site has, is saved with the shortcut as an icon.

Note: This system can work for other browsers. I just used Chrome since most of what I need are Google Apps. So if you know how to do this in Firefox or IE then go ahead.
Let’s get started. Say we need an email client. You have either a choice between a webmail client, like Gmail and Yahoo Mail, or a POP/IMAP client like Squirrel or Horde installation. Let’s go with Gmail. You log in to Gmail – find a comfortable page like the inbox or the login page. Normally for security purposes I’d go with the login page, but since I’m the only one using this workstation lets make it easy for me and pick the Inbox as our starting page.

Now a popup should appear asking where you want to place your shortcut. It can be on the Desktop, the start menu, or a shortcut on the Quicklaunch bar. This is just a matter of preference. I prefer the Quicklaunch bar to maintain the minimalist feel of this system.

Voila! you now have an email client on steroids. Well, almost. You can configure Gmail some more to personalize it. I’ll cover this part in a future post. Repeat this for other applications, each time finding the “comfortable” starting page when you create the shortcuts. Fortunately for you I’ve listed a number of them below to get you started.
Update 2010/08/21: If you don’t like Chrome. Mozilla’s Prism accomplishes the same thing.

Download from here.

Applications

Office Alternative(Word, Excel, PowerPoint etc.)

Email

Calendar and Tasks

Music Player/Online Radio

Picture Organizer

Instant Messaging

Meebo

If you know other similar applications or more web alternatives to desktop applications, please don’t hesitate to mention in it in your comments.

Read some more

http://www.google.com/support/chrome/
http://www.makeuseof.com/tag/5-great-alternatives-to-google-docs-you-should-consider/
http://alternativeto.net
http://brontesaurus.com/blog/2008/12/3-webmail-alternatives/

What Browser?

Sat, 10 Oct 2009 16:04:00 GMT

Ever wondered what a browser truly is? Or know someone you’ve been trying to educate for a long time to use one? Ever met someone who keeps confusing a browser with a webpage? Are you still at hairs end trying to pick the best one? Don’t fret, Google comes to the rescue again.

Built by “some folks from Google”, WhatBrowser.org is a site dedicated to what we all would agree to be the most used application in any computer, “the Browser”. Any Operating System has it in some form or another(Anyone said Lynx(?). Companies battle it out for supremacy, sometimes even forcing their religion; I mean browser, down our throats. Whatever a browser is or where it came from, it paved the way for the information superhighway AKA The Internet. That is cause for celebration and dedicatory site, won’t you agree?

WhatBrowser.org is kind of timely if you think Oct 13 will be birthday no. 15 of the commercial browser. Imagine software, a teener! No wonder some people still gets confused (LOL).

Visit the site

When you visit the site, you are presented a video. The video is a cute presentation of what a browser Is and what it is Not. It continues with what you can do with it(browser). Watch the video. It may amuse you and educate you a bit at the same time. Also opposite the video is the name of the browser you used to access the site, the user-agent. You can see that I use Chrome. I will admit that lacking plugins for Chrome was kind of a turn off at first, but with the release of the dev channel and it’s plugin support, I found myself doing more and more work with it, but thats a topic for another day.

Your user-agent may not be what you expect it to be,since some browsers enable you to change user agents. The site also has 3 more sections below the video, linking to other features/services. I especially like the “Under the hood” page. There you can subject your browser to some benchmarking tests. I’ll post a comprehensive post related to this tests later.

WhatBrowser.Org

The site is a awesome idea. Maybe in the near future, the site will grow and provide even more tools to help us understand and make the most out of our “browsers”.

What Browser? – Home

Read some more

Funny Video: Animator vs Animated

Thu, 08 Oct 2009 01:07:00 GMT

Shared for your viewing pleasure.

Programmers beware the evil of AI! LOL!

OCR API on Google Docs(not yet)

Wed, 30 Sep 2009 07:41:00 GMT

Google API blog announced today, new features for their Documents List – Data APIs (DLDA) – one of which is Optical Character Recognition(OCR). To put it simpy, sending an image(with readable text) to a DLDA application, when OCR is enabled into the request, will equip the API to read the image and generate a properly editable document.

Applied Fiction

Agent 007 photographed a top secret document he needs to deliver to M in CSV format (LOL). Q is not around to give him a nifty watch-slash-camera with OCR features. Good thing he also talks geek and plays with GoogleAPIs. He uploads the digital image into Google Docs and after a length of a blink, he gets a text version of the document. M receives the document, sends Bond a beautiful accountant to “help” him, found the location of the villain, saves the world – the end.

summary: 007:The Gold Potato that Never Dies Tomorrow

_Oh, I forgot he gets to trash another Aston Martin while saving the girl(not the accountant).
_
OCR is not integrated into Google Docs Home interface yet, but this API improvement is a step closer. Heres, a mockup of how I believe this feature would integrate into Google Docs’s upload function.

The feature is still in its early stages, shown by errors and misses in documents generated by the live demo. The developers did say to use high quality images.

OCR will only work well on high-resolution images. The quality of the extracted text isn’t perfect yet, but we’re busy improving it!

Miss or not, this is all very exciting, especially for Google Doc users like myself.

source: http://googledataapis.blogspot.com/2009/09/import-scans-or-go-multilingual.html

Updated list of Verified Relief Centers

Mon, 28 Sep 2009 23:02:00 GMT

Here’s another repost.A list of verified in-kind drop off points for Ondoy victims relief operations. Includes what they need and who to contact.

image attributed to: http://news.xinhuanet.com

For updates keep checking gmanewstv.com

Update: List of verified relief centers for ‘Ondoy’ victims

QUEZON CITY

UP College of Arts and Letters

Go to: College of Arts and Letters (CAL)
University of the Philippines, Diliman, Quezon City
Hotline: 09296454102 (Prof. Roselle Pineda)
Look for: Guard on Duty (in UP CAL)
Operations: 24 hours until Wednesday tentatively
You can:

Donate medicines, clothes, blankets, food to be distributed by Citizens’ Disaster Response Center.

Erica Paredes

Go to: Katipunan Avenue, Quezon City
(Call or text contact number for complete address) Contact #: 09174741930
Look for: Erica Paredes
Operations: Throughout the week tentatively, from 10 am to 6 pm
You can:

Donate ready-to-eat foods like hard-boiled egg, bread, packed juice, sandwich filling
Volunteer to prepare sandwiches and distribute goods

NoyMar Relief Operations – QC

Go to: Balay Expo Center, Farmers Market, Cubao or in White Space, Pasong Tamo Ext., Near BMW, Makati
Look for: Clare Amador or Jana Vicente
Hotlines: 09285205508, 09285205499, 0908-6579998, 0939-3633436, 9137122
Operations: 8 a.m. to 9 p.m. throughout the week until further notice.
Website: www.marroxas.com
You can:

Donate drinking water, old medicines, clothing, blankets, canned goods, noodles
Volunteer to man stations and repack food.

Miriam Quiambao and World Vision Development Foundation

Go to: One Orchard Road Building in Eastwood or at the World Vision office at 389 Quezon Avenue, corner West 6th St., Quezon City
Hotline: 0917-8623209
Look for: The guard in the lobby (on One Orchard Road)
Website: http://www.twitter.com/miriamq, www.worldvision.org.ph
Operations: Until Sept. 28, 2009 (Monday), 24-hour operation
You can:

Donate goods like clothes, blankets, canned goods, crackers, mattress, hygiene kits, noodles, bottled water, oatmeal, instant coffee, sugar (for relief pack to be distributed by World Vision)

Volunteer to help repack relief goods for World Vision starting today at 7pm
Deposit cash donations to World Vision Development Foundation, BPI savings account number 4251002415 and BDO savings account number 270043411

Philippine Army

Go to: Philippine Army Gym inside Fort Bonifacio, Makati or General Head Quarter’s Gym in Camp Gen. Emilio Aguinaldo, EDSA, Quezon City
Hotline: 892-3417 (direct line), 845-9555 (trunkline) local. 6464 and 6466
Look for: Any personnel on duty
Operations: Ongoing everyday for 24 hours until further notice
You can:

Donate relief goods (no cash)
Call hotline for rescue, evacuation or relief assistance.

Call to report missing persons

Papemelroti Gifts and Decorative Accessories

Go to: 91 Roces Ave., Corner Scout Tobias, Quezon City or mall branches in Ali Mall Cubao, SM City North EDSA, SM Fairview, SM Megamall, Glorietta 3 in Makati, SM Centerpoint, SM Southmall
Hotline: refer to website for individual branch numbers
Website: www.papemelroti.com
Operations: Mall hours (10am-9pm), ongoing everyday until further notice
You can:

Donate goods like canned goods, clothings, blanket, cooking utensils and other relief goods EXCEPT cash.

Ateneo de Manila University Disaster Response Group

**Go to: **Ateneo de Manila University, Loyola Heights , Quezon City, Manuel V. Pangilinan Building Center for Student Leadership Lobby, University Dorm Cervini Hall
Hotlines: 09089977166, 09178952792, 4266001 local 5050
Look for: Gio Tiongson, President, Sanggunian ng mga Mag-aaral
Website: www.ateneosanggu.com
**Operations: **24-hour operations for the entire week
You can:

Donate goods like bottled water, sardines, canned goods, candles, cup noodles.

Volunteer to help repack relief goods, administer basic first aid.

Report missing persons.

Seek evacuation/temporary shelter at University Dorm Cervini Hall.

Citizens Disaster Response Center (CDRC)

Go To: 72-A Times St., West Triangle Homes, Quezon City.
**Hotlines: **9299820, 9299822
Operations: 8 a.m. onwards.
You can:

Donate money, old clothes, blanket, bigas, munggo.
Volunteer to help distribute goods.Radio Veritas **Go To: **Veritas Tower , West Ave. corner EDSA
Look For: Karla Turingan
**Hotlines: **9257931 to 39, 0918VERITAS
Operations: 24-hours, tentatively until Tuesday.
You can:

Donate old clothes, food, assorted goods, bottled water, cash.

Our Lady of Pentecost Parish

**Go to: **12 F. dela Rosa cor. C. Salvador Streets, Loyola Heights , Quezon City
**Hotlines: **632 4342397, 63 2 9290665
Operations: 7 a.m. till 10 p.m. Sunday, until further notice.
You Can:

Donate packed meals, bottled water.

MAKATI/TAGUIG/MUNTINLUPA

Victory Fellowship – Fort Bonifacio

**Go to: **Victory Fellowship, Every Nation Building , across Market-Market, Fort Bonifacio
Look for: Pastor Bernard Marquez
Hotlines: 813-FORT, 8171212
**Operations: **Tentatively until 5pm, may may extend hours. Entire week until Friday.
Website: www.twitter.com/VictoryFort
**You can: **

Donate canned goods, milk, bottled water, clothes, cash.

Volunteer to help pack relief goods

Sacred Heart of Jesus Chaplaincy

Go to: Hillsborough Village, Cupang, Muntinlupa City, Metro Manila
Hotline: 8428148, 8079847
Look for: Genelyn Sembrano, Meanne Cuneta
Website: www.sacredheartofjesus-alabang.org
Operations: Tuesday-Sunday (Sept. 29-Oct 4). 8 am to 12 noon, 2 to 6 pm
You can:

Donate water, blankets, shoes, clothes and other goods

Donate in cash

PASIG CITY

LUZON RELIEF: Volunteer / Donate / Pray

Go to: Renaissance Fitness Center, 2nd Floor, Bramante Building, Renaissance Towers, Ortigas, Meralco Avenue, Pasig City
Hotline: 0929-8713488
Look for: Warren Habaluyas, co-founder
E-mail: luzonrelief@gmail.com
Operations: Monday to Saturday (Sept. 28-Oct. 3), 9am-7pm
You can:

Donate non-perishable food items, beddings, pillows, blankets, clothes

You can donate cash but it is not encouraged

– Compiled by Annalyn Ardoña and Patricia Faustino, GMA NEWS AND PUBLIC AFFAIRS

Update: some more info from google-ondoy page

Google Ondoy Help Page

Mon, 28 Sep 2009 10:39:00 GMT

Updates:

Helping Victims of Tropical Storm

Google joins the Filipino nation in helping those affected by Typhoon Ondoy!

I am reposting the info here if you have time please check the actual google page.

http://www.google.com/landing/typhoon-ondoy.html

Help for Typhoon Ondoy Victims in the Philippines

On September 26, 2009, Typhoon Ondoy brought a month’s worth of rainfall to Metro Manila and nearby areas in just a few hours, causing severe flooding which resulted in the loss of many lives and the displacement of hundreds of thousands of people. This site compiles relevant information about the disaster, including a volunteer-maintained map of persons needing rescue and a list of relief organizations accepting donations, so that more help can be provided where it is needed. You can also keep track of the latest news on Google News and YouTube.

Know someone who needs help?

A group of volunteer map makers have been maintaining the map below, which documents flood updates and persons needing rescue. If you know someone who needs help urgently or if you would like to report the status of the flood in your area, pleasecomplete this form. The information will be sent to the group’s main database for posting on the map.

View Ondoy situation map for Metro Manila in a larger map

Disclaimer: This map was initiated by a group of volunteers not directly connected with Google. We cannot guarantee 100% accuracy of all placemarks. If you are familiar with Google Maps and would like to help the group’s volunteer efforts, please email typhoonondoy@googlegroups.com.

Useful Links

News and Updates

Disaster Emergency

Rescue Operations
- National Disaster Coordinating Council (NDCC) (+632-9125668, +632-9111406, +632-9115061, +632-9122665) Help hotlines: (+65 734-2118, 734-2120)
- Philippine Coast Guard (+632-5276136)
- Air Force (+63908-1126976, +632-8535023)
- Metro Manila Development Authority (136)
- Marikina City Rescue (+632-6462436, +632-6462423, +632920-9072902)
- Pasig Rescue Emergency Number (+632-6310099)
- Quezon City Rescue (161)
- San Juan City Hall Command Post (+632-4681697)
- Bureau of Fire Protection Region III (Central Luzon) Hotline: (+63245-9634376)
- Senator Dick Gordon (+639178997898, +63938-444BOYS, +632-9342118, +632-4338528)
- Senator Manny Villar (+639174226800. +639172414864, +639276751981)
Civil Society/ Media
- Philippine National Red Cross (143, +632-5270000)
- Philippine National Red Cross Rizal Chapter operations center hotline: (+632-6350922, +632-6347824)
- Go to GMA Facebook page & post complete addresses and names of people in need of immediate help.
- ABS-CBN Typhoon Ondoy Hotline: (+632-4163641)
- Jam 88.3: (+632- 6318803) or SMS at JAM (space) 883 (space) your message to 2968
Rubber Boat Requests, 4×4 Trucks
- NCRPO (+632-8383203, +632-8383354)
- Private citizens who would like to lend their motor boats for rescue
  please call emergency nos: +632-9125668, +632-9111406, +632-9122665, +632-9115061)
- You can also text (+632917-4226800 or +632927-6751981) for rescue dump trucks.
- For those who are able to lend 4×4 trucks for rescue: Please send truck to Greenhills Shoppng Center Unimart Grocery to await deployment, Tel No. (+632920-9072902).

Online and In-Kind Donations

Below you’ll find a list of groups in the Phillippines that are accepting cash and in-kind donations to help with disaster relief efforts:

Monetary Donations

1. Bank Donations Actual table here

1. Credit Card/PayPal Donations

1. SMS Donations

	Procedure	Smart Money	Globe GCash
PNRC	Type RED `Ex. RED 100`	4493	2899
TXT POWER	5577-5144-1866-7103	0917-9751092

In-Kind Donation

Victory Fort is opening its doors to those affected by the typhoon. Call 813-FORT.
NoyMar relief Operations: Clare Amador (+639285205508) or Jana Vicente at +639285205499). Drop off for relief donations is at Balay Expo Center across Farmers Market Cubao.
Miriam Quiambao drop off points: One Orchard Road Building in Eastwood, or message http://www.twitter.com/miriamq for more details.
Philippine Army Gym inside Fort Bonifacio or GHQ Gym in Camp Aguinaldo are now distributing donations for Ondoy Victims.
Team Manila stores in Trinoma, Mall of Asia, Jupiter Bel-Air and Rockwell shall be accepting relief goods (Canned Goods, Ready-to-drink Milk,Bottled Water and Clothes) for distribution by Veritas.
Caritas Manila Office at Jesus St., Pandacan Manila near Nagtahan Bridge (+632-5639298, +632-5639308)
Radio Veritas at Veritas Tower West Ave. Cor EDSA (+632-9257931-40)
Aranaz Stores in Rockwell & Greenbelt is accepting donations of any kind for Payatas communities affected by Ondoy
Simbahang Lingkod ng Bayan Task Force Noah, a disaster response arm of the Jesuits, is accepting donations. Please drop it off sa Ateneo Cervini Dorm.
Philippine National Red Cross‘ different ways to Donate.
Red Cross Load Donations: Right now the easiest way to make donations from the seat of your chair is via mobile phone load. The Red Cross Rescue and Relief Operations. Text: REDAMOUNT to 2899 (Globe) or 4483 (Smart)
Ateneo de Manila University is now accepting donations for the victims of Ondoy. Donations can be dropped at MVP Lobby. For those stranded/those who need help: To all students who need help or know of people who need help. Please text the name, location, and contact number to (+6329088877166). ATENEO, which is now an open shelter, accepts refugees. Call (+632917-8952792)
Papemelroti stores in 91 Roces Ave. / Ali Mall Cubao / SM City North EDSA / SM Fairview / SM Megamall / Glorietta 3 in Makati / SM Centerpoint / SM Southmall are accepting relief goods (canned goods / milk / bottled water / clothes – NO CASH pls.)
TXTPower now accepts donations via SmartMoney 5577514418667103, GCash 09179751092 and Paypalhttp://is.gd/3GvuN
Our Lady of Pentecost Parish (+632-4342397, +632-9290665) per Gabe Mercado, donations are very much welcome. The Parish is located at 12 F. Dela Rosa corner C. Salvador Sts., Loyola Heights, Quezon City.
Hillsborough Village Chapel – Water, blankets, shoes, and clothes may be sent to Hillsborough Village Chapel in Muntinlupa City. These will go to families whose houses were washed out in the nearby sitios.
Greenhills/Mandaluyong/San Juan Area, if you want to help out with the rescue and relief operations, you can drop off your donations (clothes, food, etc..) at La Salle Greenhills Gate 2 tomorrow or volunteer from 9am to receive, sort, repack the donations.
Petron: You may bring your relief goods to all Petron branches.
LUCA stores (Rockwell, Shang-rila, Eastwood, or GA towers): Send your old clothes & donations (no cash pls).
“LUZON RELIEF: Volunteer / Donate / Pray”: Donations can be brought to RENAISSANCE FITNESS CENTER, 2nd Floor, Bramante Building, Renaissance Towers Ortigas, MeralcoAvenue, Pasig City starting MONDAY (Sept.28) / 9am – 7pm Contact Person: Warren Habaluyas (+632929-8713488) or email at luzonrelief@gmail.com
MOONSHINE boutique in Rockwell also accepting relief good to help Ondoy victims in Marikina and Cainta.
Katipunan Avenue. Contact Erica Paredes at (+632917-4741930) — they need bread, packed juice, sandwich filling (tuna, chicken, anything) You can help her make them, deliver the sandwiches to her house, or help her distribute! Call for more details.
Manor Superclub, Eastwood City will accept goods and other emergency items starting Sunday at 10 am.
Citizens Disaster Response Center (CDRC): Relief goods for typhoon victims being accepted at 72-A Times St., West Triangle, QC. Tel (+632-9299820/22)
MINISTOP IBARRA (Espana cor. Blumentritt, Sampaloc Manila) is also accepting relief goods, Food (non-perishable goods only) Clothing, Medicines, Beds, Pillows, Blankets, Emergency Supplies to help Typhoon Ondoy victims.

Updates on Ondoy: Places to donate – Efforts by bloggers

Mon, 28 Sep 2009 03:07:00 GMT

A call for help. If you are able, please donate whatever you can spare to the victims of Ondoy(Ketsana).

I collected some details of donation centers and numbers but it pales in comparison to what other bloggers were able to post.

Please check the list of posts below:

Here are government and NGO sites with some info as well.

I know a hundred more bloggers and sites out there I don’t know about- doing the same thing. God bless them. Even if you can’t donate material items or you dont have specialized skills like doctors and nurses – you can help by spreading the word – checking the sites listed above and others. If you have anything to add to the list, please post a comment.

Thanks and Lets pray for the safety of those affected.

Added Oct 6, 2009

Here’s a site dedicated to the cause! Thanks goes to @Joel for sharing.
http://www.ketsanarelief.com/

These are times that I’m proud to be Filipino!

Project 10^100: The Voting Begins

Fri, 25 Sep 2009 23:39:00 GMT

Project 10^100 is a Google Project that transcends the information superhighway. It’s aim, simply, is to help – to help people so they can help others. How ? They promised to give 10 million dollars to fund any project that can improve peoples lives. But as funding is finite, they need to find the best ideas. Projects they believe, can do the most good.

The past year (2008), Google received more than 150,000 ideas. It took another year(2009) and 3000 Google employees to sort them through. The ideas need to cover one of the following categories

Categories:

Community: How can we help connect people, build communities and protect unique cultures?
Opportunity: How can we help people better provide for themselves and their families?
Energy: How can we help move the world toward safe, clean, inexpensive energy?
Environment: How can we help promote a cleaner and more sustainable global ecosystem?
Health: How can we help individuals lead longer, healthier lives?
Education: How can we help more people get more access to better education?
Shelter: How can we help ensure that everyone has a safe place to live?
Everything else: Sometimes the best ideas don’t fit into any category at all.

Out of the huge collection of ideas, they have narrowed them down to 16. Each of which is inspired by different submissions. So no one submission can claim the idea, just part of the whole. Its a wonder how some minds are alike. 🙂 Even greater wonder that they choose to do good with those creative brains.

What now?!

Now they are asking for people to vote. To pick the ideas they believe can make the difference. Out of 16 they need 5 ideas to turn into funded projects. The call to vote started September 24, 2009 and will end October 8, 2009. Watch this video:

So I invite you guys to go on Project 10^100’s voting page. Read all the ideas, and look into yourself what you think will help this hurting world of ours. Then pick the best one. After that invite others( friends,family, co-workers etc.) to do the same.

Conclusion

It’s great that large companies like Google still have that sense of civic responsibility to better this world. I hope this generation can nurture what Google started and the projects that will win this opportunity. God bless us all!

Use Export Command To Help Linux Find Your Scripts

Fri, 25 Sep 2009 03:37:00 GMT

You compiled and installed a linux binary or made a nifty script but you don’t want to mess the server bin tree. So you placed it in an isolated folder like so:

Level: Beginner, Intermediate

Yeah your a rockstar!

  /usr/local/myscripts/really/great/work/bin/myutility

You go on with business as usual. But soon you got tired of typing the whole path or changing folders every time you need the app. You could simplify your life by making a symbolic link(shortcut) or a wrapper script and place it on a more convenient path like /bin or /usr/bin. But you realize that would be defeating your original intent. what do you do?

Simple. Do what experts do. Use “export” to modify the PATH environment variable.

> help export

export: export [-nf] [name[=value] …] or export -p
NAMEs are marked for automatic export to the environment of subsequently executed commands. If the -f option is given, the NAMEs refer to functions. If no NAMEs are given, or if `-p’ is given, a list of all names that are exported in this shell is printed. An argument of `-n’ says to remove the export property from subsequent NAMEs. An argument of `–‘ disables further option processing.

<p>
  To get an idea, try this command on the console:
</p>

<div>
  > echo $PATH</p> 
  
  <p>
    /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin</div> 
    
    <p>
    </p>
    
    <p>
      The above value is a typical &#8220;root&#8221; PATH for a fresh text-only CentOS installation &#8211; so don&#8217;t fret if you got something different. This will grow in time the more you install applications. Anyway, back to business, now you want to add your &#8220;incredible&#8221; scripts. Run the ff:
    </p>
    
    <div>
      > export PATH=$PATH:/usr/local/myscripts/really/great/work/bin
    </div>
    
    <p>
      Done, now see if Linux can find your script or binary.
    </p>
    
    <div>
      > which myutility</p> 
      
      <p>
        /usr/local/myscripts/really/great/work/bin/myutility</div> 
        
        <p>
          Success! Now test your script.
        </p>
        
        <div>
          > myutility
        </div>
        
        <p>
        </p>
        
        <blockquote>
          <p>
            If your script throws an error, you may need to work on it. It may be using hard coded relative paths. Sometimes using absolute paths can do the trick.
          </p>
        </blockquote>
        
        <p>
          Yahoo! It works! Now lets take it a bit further, lets configure your system so you don&#8217;t need to keep typing the export-PATH command. Open the ~/.bash_profile file in your favorite text editor.
        </p>
        
        <div>
          > vi ~/.bash_profile</p> 
          
          <p>
            # .bash_profile
          </p>
          
          <p>
            # Get the aliases and functions<br />if [ -f ~/.bashrc ]; then<br />. ~/.bashrc<br />fi
          </p>
          
          <p>
            # User specific environment and startup programs
          </p>
          
          <p>
            PATH=$PATH:$HOME/bin
          </p>
          
          <p>
            export PATH<br />unset USERNAME</div> 
            
            <p>
            </p>
            
            <blockquote>
              <p>
                Note the tilde(~) symbol, this is just shorthand for your home folder. Lets say your username is iamgenius, that should translate to /home/iamgenius/.bash_profile
              </p>
            </blockquote>
            
            <p>
              Same as what you did earlier, append your script folder to the PATH construct, as shown below
            </p>
            
            <div>
              PATH=$PATH:$HOME/bin:/usr/local/myscripts/really/great/work/bin
            </div>
            
            <p>
              Now your done, the next time you login, the new &#8220;PATH&#8221; should kick in.
            </p>
            
            <p>
              Congratulations! Now go play with your scripts!
            </p>
            
            <p>
              <a href="//dl.getdropbox.com/u/1510515/potatokorner/potatokorner-tutorial-export-command.pdf" target="_blank">Download a PDF copy</a>
            </p>

About Me

Thu, 24 Sep 2009 01:07:00 GMT

Hi, I’m Chris Bautista — a frontend engineer who specializes in accessible, production-grade web interfaces.

My recent posts are about accessibility (WCAG 2.1 AA) and modern frontend engineering: auditing components for screen reader and keyboard support, fixing real-world issues like focus traps, missing alt text, and unlabeled controls, and writing about what I learn along the way so other developers can skip the trial and error.

What I work with

Languages: JavaScript, TypeScript
Frontend: React, Gatsby, Tailwind CSS
Accessibility: WCAG 2.1 AA audits, ARIA patterns, keyboard/screen-reader testing, semantic HTML
Testing: Vitest
Other: Node.js, REST APIs, CSS (container queries, modern layout)

Recent case studies

Build an Accessible Tab Container — roving tabindex, arrow-key navigation, ARIA tab pattern
Fix accessibility using focus-within — solving keyboard-vs-mouse UI mismatches without JavaScript
Automatically generate skip buttons — scripted skip-navigation links
Accessible UI Component Series — an accordion, buttons, and shared design tokens built to test ARIA patterns firsthand

Also see Creating My Animated Bottom Bar Experiment, my most-loved CodePen experiment — interaction and motion rather than accessibility, but a good look at range.

See the full portfolio or browse posts tagged accessibility for more.

A bit of background

I’ve been building for the web for over 15 years — from hybrid mobile apps (Cordova, jQuery Mobile) and PHP/REST backends to, more recently, React and TypeScript. These days accessibility is the thread that ties most of my work together.

I still own CodeSpud Web Services, and you can find my code on GitHub. Have a challenge I can help with? Email me at chris at codespud dot com.

Outside of code: gaming, cooking, and chasing the perfect cup of coffee.

Picasa 3.5 comes with Face Recognition

Thu, 24 Sep 2009 00:28:00 GMT

Google released Picasa 3.5 yesterday, with some cool features. In keeping with Picasa Web Albums enhancements, Developers have added face recognition and geo tags to their photo-organizer-slash-jack-of-all-trades software.

http://picasa-readme.blogspot.com/

With name tags, you can organize your photos based on what matters most: the people in them

As soon as the announcement came, I installed Picasa 3.5 – eager to try the new features. As it seems, face recognition is activated from start , no warning whatsoever, but you do need to login to your picasa account to get your name tags.

Processing seems a bit longer than usual, as with the old version, you can still use the application even while it’s still sorting through all your stuff – so no worries. Picasa 3.5 got almost 100% from my tests. I already tagged faces on Web Albums so I didn’t had the chance to tag new faces. But I’m amazed how good this works even if the person is facing front or showing their profile. Nevertheless, your results may vary depending on how distinct people in your photos are. If it’s anything like Picasa Web Albums, the engine should improve in time the more you use it.

Its a great addition to Picasa. It eases the pain of digging all your albums to find people. I know I’ll be abusing this one for a long time. 🙂

Download Picasa 3.5
Image from http://parenting.leehansen.com

NES on Javascript

Mon, 21 Sep 2009 08:19:00 GMT

Here’s something amazing for Javascript, your good-ole NES (Nintendo Entertainment System) games are now available and playable via Ben Firshman’s JSNES page. JSNES, is an NES emulator built on javascript’s canvas objects.

http://benfirshman.com/projects/jsnes/

Mr. Firshman recommends to use Google’s Chrome browser to maximize your gaming pleasure. I tried it on IE8, it doesnt work as well. So take his word for it.

Aside from SMB(Super Mario Bros.), he also ported some old favorites like the Zelda, the banana maniac-Donkey Kong and the blaster wielding Megaman.

Ben Firshman shows us that with a little programming acrobatics and some improvements to browser canvas objects, anything is possible.

Enjoy peeps!

Question: When can we start seeing 3D games running on browsers? Hehehe

XOXO Creativity

Sun, 20 Sep 2009 12:16:00 GMT

Here’s a good way to promote creativity and have fun at the same time. The rule is to draw as many things as your imagination can conjure up from X’s and O’s.

Almost done.

This is what Panamericana School of Art and Design did in a advertising campaign.I tried googling for their site but can’t seem to find it. Anyway I’ll update this page when I get more info.

There’s something naughty in this shot.

I made my own versions to work with. You can download them below. Try them out with your kids and friends. You might just be surprised what plays in their minds. 🙂 Everybody say Rorschach test! :D.

Credit to Panamericana for the idea.
Images from www.toxel.com

O’s Creativity Test DOWNLOAD
X’s Creativity Test DOWNLOAD

Resume on Youtube!

Sat, 19 Sep 2009 13:51:00 GMT

Streaming Video giant, Youtube, recently announced a Resume feature along with other improvements for their groundbreaking service. (Cheers! claps! Bring in the beer! LOL). Gone will be the days where you had to restart a video just to continue where you left of. Now you dont need to restart a whole video or pause till the video fully loads then skip every so and so, just to pick up where you last watched.

Note the feature will only work for resumes past the 3 minute mark – meaning any resumes less than mentioned duration are ignored – so you need to run the video from the start again. A perfectly logical limitation.

This addition is a big step forward for online media players – hopefully other video sites will follow suit. 🙂 For more info go here

Google got reCAPTCHA

Sat, 19 Sep 2009 08:55:00 GMT

Google announced recently in its official blog, that it has acquired reCAPTCHA. CAPTCHA is a web technology made out of necessity. It primarily is used to prevent BOTS (or automated apps designed to do malicious tasks) by adding an extra step to site pages that require human interaction. Yes, they’re the annoying barely readable text images when you register/login for a site.

Anyway, this move by Google is more than just for improving it’s CAPTCHA capabilities. As they explain, reCAPTCHA technology will improve Google projects that require reading text in images. The best to benefit from this are Google’s Books project and the recent Fast Flip zine search. For more info see the official announcement.

M I STUPID?

Sat, 19 Sep 2009 07:41:00 GMT

Do you know how to send an SOS in morse code? Do you know your birthstone? Or the winners of the Oscars since 1927 ? MIStupid.com has an assortment of trivia and topics not known by the most of us. As a bonus they have categories with games and puzzles you can play with when you catch a bit of an information overload.

http://mistupid.com/contents.htm

No matter how trivial or uninteresting the fact is MIStupid.com will surely have it, otherwise go back to Google (hehehe). Well okay it’s not Encarta but its free and GREEN 🙂

Enjoy!

potato

How to Write a Backup Shell Script using Tar and Gnu Zip

Fri, 02 Jan 2009 23:20:00 GMT

Happy New Year!

As promised I made a rudimentary Linux shell script utilizing the tar and gzip commands to archive or make backups. If you’re new to shell scripting you might like to read these articles.

Unix shell scripting with ksh/bash Advanced Bash-Scripting Guide

If you’re lazy like I am. Don’t worry I’ll explain parts of the code.

Our goal is to make a shell script to create backups (in tar-gzip versions) of the folders we want unto a safe location on a disk. We want to be able to list all the folders and have the script loop through them. Now that’s settled, we can proceed to the code.

First, don’t forget to tell linux what scripting interpreter to use. I usually use sh but there are others like bash and ksh. But many experts suggest to use sh for portability to older systems.

#!/bin/sh

Next, we configure the script. The lines below enumerates the folders I want archived ,then stores them in a SHELL VARIABLE named FOLDERS. (duhh!..)

# — LIST OF FILES/FOLDERS TO BACKUP
FOLDERS=”/var/www/html /opt/sandbox”

This line saves the folder path I want the archives to be stored in.

# — BACKUP HERE
BACKUPFOLDER=”/opt/backup”

REMINDER
Make sure that the backup folder exist. If it doesn’t run the lines below on the console.

> mkdir /opt/backup
> chown root:root /opt/backup
> chmod 755 /opt/backup

Here I configure the command string I want to use. Regarding the details of the command I used – see this [link].

# — ARCHIVE COMMAND
COMPRESSCMD=”tar czfv “

Here we use the for command to loop through all the items we listed in $FOLDERS and store it in another variable, $itm.

## loop thru folders
for itm in $FOLDERS; do
# commands here
….
done

These lines configures the commands we’re going to use inside the loop. The first line generates a formatted file path for my archive, $FARCHIVE.

FARCHIVE=$BACKUPFOLDER/`basename $itm`_`uname -n`_`date +%F`.tgz
$COMPRESSCMD $FARCHIVE $itm

If you’ve noticed I used the tilde symbol(`). Yes they are not single quotation marks. In linux console, any commands enclosed within tildes are ran first and the result is returned as a string. So for example $itm is equal to /var/www/html. The resulting FARCHIVE value will be:

> echo $FARCHIVE
/opt/backup/html_potato_2009-01-02.tgz

The second line uses $FARCHIVE as well as the command we configured earlier and runs it.

For a breakdown of the enclosed commands we used.

echo the last(base) name in a path string.

> basename /var/www/html
html

echo the system’s computer name.

> uname -n
potato

echo the current date in this format (YYYY-MM-DD)

> date +%F
2009-01-02

Here is the full script.

#!/bin/sh
#set -x
#——————————————–
# ID: cabBackup.sh – BACKUP items to folder
# USAGE: ./cabBackup.sh
#——————————————–
# AUTHOR: codespud 2008-2009
# VERSION: 0.01

# TODO: arguments
# TODO: config file
# TODO: functions
# TODO: filtering

# Sources
# http://www.hsrl.rutgers.edu/ug/shell_help.html

# PATH
PATH=/opt/bin:/usr/bin:/bin; export PATH

# CONFIG

# — LIST OF FILES/FOLDERS TO BACKUP if not specified via console

FOLDERS=”/var/www/html /opt/sandbox”
#FOLDERS=””

# — BACKUP HERE
BACKUPFOLDER=”/opt/backup”

# — ARCHIVE COMMAND
COMPRESSCMD=”tar czfv ”

# — DO NOT EDIT BEYOND THIS LINE (unless if you knw what ur doing ;] ) —

# Check if the folder exists if not make it
[ ! -d $BACKUPFOLDER ] && mkdir -p $BACKUPFOLDER || :

chown root:root $BACKUPFOLDER
chmod 755 $BACKUPFOLDER

# clean the screen
clear

echo lets start

## loop thru folders
for itm in $FOLDERS; do

FARCHIVE=$BACKUPFOLDER/`basename $itm`_`uname -n`_`date +%F`.tgz
$COMPRESSCMD $FARCHIVE $itm

done

echo .. done

Now name and save the file. I named mine cabBackup.sh.

You need to make the script executable.

> chmod 755 ./cabBackup.sh

There you have it just run it from the console.

> ./cabBackup.sh

There are still some things we need to do to make it a fully fledged automation script like configuration files, some pre-process commands and error trapping. But what we have now serves our purpose very well. I’ll post revisions of this script so watch for that.

Links
http://www.dartmouth.edu/~rc/classes/ksh/print_pages.shtml
http://tldp.org/LDP/abs/html/
Linux: Snippet – Backup using Tar and gzip

Linux: Snippet – Backup using Tar and gzip

Sun, 07 Dec 2008 08:51:00 GMT

As a programmer i have to make multiple revisions of a project on a remote site. Getting things wrong and messing up the files tend to happen more often than I am comfortable with. Fortunately, making quick backups in linux is a breeze. You can either make a folder and just copy your existing files via recursive cp command or; archive it using tar and gzip. Personally, I prefer archives since they tend to be smaller and easy to manage.

Install tar and gzip

You can be hardcore and download the source for tar and gzip and recompile them.

http://www.gnu.org/software/tar/

http://www.gzip.org/

Or you can use apt-get or yum(Yellow dog Updater, Modified ? — weird name ) to do it for you.

yum install tar

yum install gzip

Sample commands

Archive a folder ( -c means create )

tar cvf - folder | gzip > archive.tar.gz

Archive a file

tar cvf - filename | gzip > archive.tar.gz

Archive files

tar cvf - filename1 filename2 | gzip > archive.tar.g

Alternative format (-z means use gzip to compress)

tar cvzf /path/to/dir/archive.tar.gz filename

tar cvzf /path/to/dir/archive.tar.gz filename1 filename

Extracting (-x means extract )

tar xvzf /path/to/dir/archive.tar.gz

There are other ways and tools to make your archives. But we’ll continue with that some other time. For the really lazy, I’ll make a bash script that uses tar and gzip in a later post so watch for that.

I hope my article helped some newbies out there. Mabuhay!

CodeSpud RSS Feed

View Transitions vs. My Old CSS Habit: What Actually Changes

#Contents

The old way, and why it always felt fragile

What the browser does differently

React wraps it, with real constraints

Building the same toggle two ways

Wrapping up

My Drafts Folder Is a Graveyard, and a WIP Limit Fixed It, So Far

#Contents

Where the mess actually starts

What a WIP limit is supposed to fix

Making the limit cost something

#What’s on the board right now

Accessibility Law World Map

#Data

#Notes

Top 5 Git Commands You Should Know for a Better Dev Workflow

#Contents

git switch

git restore

git worktree

git bisect

git reflog

#A habit, not a full workflow

Four Things Every CMS Image Field Needs

#Additional metadata that makes an image an “asset”

Alt text that travels with the placement

A field that asks what the image is for, before what to call it

Focal points, not fixed crops

Lazy loading and reserved space, by default

#What a boring image field buys you

#The checklist

#The image metadata we want

Typographic Hierarchy Playground

#Presets

#Layouts changes with Presets

#Notes

#Final screen

10 TypeScript Patterns That Make Code Explain Itself

#1. satisfies: keep the specific type, not just the general one

#2. const type parameters

#3. Discriminated unions with exhaustive checks: a state machine in the type

#4. NoInfer: say which part of the signature is fixed

#5. using declarations

#6. Branded types

#7. Template literal types

#8. Generic components without React.FC: let the signature describe what it accepts

#9. ComponentPropsWithoutRef

#10. Type predicates

#Wrapping up

Stop Writing Novels in Your Gallery's Alt Text

#What an image gallery is, and why we reach for one

#What alt text is for

#Why galleries make it worse

#Rules for an accessible gallery

#Alternatives to alt text

#Visible captions

#Page copy

#A linked long description

#aria-describedby for prose

#Skip autopilot AI alt text

#The checklist

#References

Research, Plan, Execute, Learn: The Agent Loop I Wish Someone Had Drawn Me First

The shortcut nobody admits to

1. Research: read before you write

2. Plan: a plan is a contract, not a vibe

3. Execute: let it check its own work

4. Learn: the phase everyone skips

The whole loop in one picture

Wrapping up

The ts-jest to Vitest Switch Is Lower-Risk Than You Think

#Why ts-jest got slow

#It’s compatible on purpose

#What actually changes

#Run it in an afternoon

#The Gotchas Worth Knowing

#The bottom line

Your Alt Text Is Not the Problem — Your Images Are

Contents

Contents

What’s on the board right now

Data

Notes

Contents

A habit, not a full workflow

Additional metadata that makes an image an “asset”

What a boring image field buys you

The checklist

The image metadata we want

Presets

Layouts changes with Presets

Notes

Final screen

1. `satisfies`: keep the specific type, not just the general one

2. `const` type parameters

3. Discriminated unions with exhaustive checks: a state machine in the type

4. `NoInfer`: say which part of the signature is fixed

5. `using` declarations

6. Branded types

7. Template literal types

8. Generic components without `React.FC`: let the signature describe what it accepts

9. `ComponentPropsWithoutRef`

10. Type predicates

Wrapping up

What an image gallery is, and why we reach for one

What alt text is for

Why galleries make it worse

Rules for an accessible gallery

Alternatives to alt text

Visible captions

Page copy

A linked long description

`aria-describedby` for prose

Skip autopilot AI alt text

The checklist

References

Why ts-jest got slow

It’s compatible on purpose

What actually changes

Run it in an afternoon

The Gotchas Worth Knowing

The bottom line

A widget is a sticker over a crack

Unplug your mouse

The dull CSS that does the work

Focus first

Use the element, not the costume

Why this beats the fine

Start tomorrow morning

Accessibility: Not Just a Checkbox

Enter AI: Your New Accessibility Sidekick

AI: Not Just for Chatbots and Cat Memes

Tools That Actually Help (And Don’t Just Add More Tabs)

1. Microsoft Accessibility Insights + Copilot

2. Google Lighthouse + Gemini

3. Axe by Deque

Workflow: AI-Driven Accessibility in Action

Looking Ahead: The Human + AI Partnership

Wrap-Up

1. Basic Discriminated Union

2. Exhaustiveness Checking

3. Handling Different API Responses

4. Handling Success and Failure

5. Representing UI States

6. Navigating Nested Data Structures

7. Managing Different Events

8. Representing Validation States

9. Handling Multiple Plugin Types

10. Streamlining Command Execution

When to use Discriminated Unions

Wrap-Up

How to do container queries

1. Make a wrapper element and setup `container` property

2. Define styles in container query

The experiment

What I learned

Wrapping up

Problem