The motivation was simple: LLM output at the time could be inconsistent, and we wanted it to write code in a style that matched our team's conventions. So I set out to put together a set of concise, token-efficient guidelines written in Markdown.

My process looked something like this: I'd read through open-source style guides (Google's HTML/CSS guide, for example), strip out the parts that weren't relevant to us, then hand the result to Claude or ChatGPT with a prompt to make it more concise within a token budget. After a few rounds of that back-and-forth, I'd usually land somewhere I was happy with.

Going into this, I had two goals in mind. First, give the LLM better context for our project. Second, produce something I could hand to a junior dev as a quick reference. The guides needed to be concise but still readable for a human.

Looking back, we probably didn't need most of what I wrote. Like I said, we didn't really know what we were doing, and this was new territory for the whole team. The only ones that proved genuinely useful were the opinionated ones. As the lead front-end dev, I have some personal rules I enforce across the team (like no max-width media queries) and that kind of thing is hard for an LLM to guess on its own. Out of everything I wrote, we still use three guidelines today: one for design tokens, one for our custom Tailwind implementation, and a general CSS styling guide.

Even though most of these are pretty useless now (AI tooling has advanced so much since late 2024), I don't think it was a waste of time. Creating those guidelines taught me two things that still matter: the importance of giving your AI assistant good context, and how to think about token management.

If you want to see the retired guidelines, I put them up on GitHub.

Check that all controls are reachable and usable with the keyboard.

• Can I Tab/Shift+Tab to all interactive elements in a logical order?
• Can I activate controls with Enter/Space (and Arrow keys where expected)?
• Is there a visible focus ring when I navigate via keyboard?
• Can I close menus/dialogs with Escape, and does focus return to the trigger?
• Does focus never get lost or trapped (except intentionally in modals)?

Semantics & Roles

Check that elements use the right HTML semantics so assistive tech understands them.

• Am I using the correct native element (<button>, <a href>, <input>) instead of a div/span?
• Does every input have a visible label that is programmatically associated?
• Do all link/button labels clearly describe their purpose (e.g., “Save changes” not “Click here”)?
• Do headings follow a logical order without skipping levels?
• Does the component have one — and only one — primary heading when it renders standalone (e.g., dialog/card title with <h2>)?
• Am I using landmark elements where relevant (<main>, <nav>, <header>, <footer>)?

Motion & Zoom

Check that the UI works for users with motion sensitivity or magnification needs.

• Does the component respect reduced motion when prefers-reduced-motion is enabled?
• Can I zoom to 200% without layout breaking or forcing sideways scrolling?

Forms & State

Check that inputs, errors, and states are clearly labeled and communicated.

• Does every input have a visible, programmatically associated label?
• Are error or help messages placed near the field and tied with aria-describedby?
• Are states (checked, disabled, pressed, loading) clearly reflected visually?
• Do buttons that trigger async actions show a loading or disabled state while processing?
• Do disabled buttons look visually disabled (dimmed, muted, etc.) without relying only on the disabled attribute?

​ Note: The disabled attribute makes elements invisible to screen readers and not keyboard-focusable. Use aria-disabled="true" for accessible inactive states.

Media & Images

Check that images and media are properly described or hidden when decorative.

• Do all content images have an appropriate alt attribute?

• If the alt is an empty string (alt=""), does the surrounding text convey the image’s meaning so that no information is lost?

• Are decorative images/icons hidden with alt="" or aria-hidden="true"?

• Do icons that convey meaning have a text label (or accessible name)?

• Does media (video/audio) avoid auto-playing on load?

• Use descriptive alt for meaningful images.

• Use alt="" for purely decorative images only when the surrounding text already conveys the meaning.

​ Note: The alt attribute is required by the HTML spec on every <img> tag.

Custom Controls

Check that custom UI components behave like their native equivalents.

• If I built a custom checkbox, radio, or switch, does it sync with a hidden native input?
• Do custom controls respond to Space/Enter like native elements?

Dialogs, Popovers, Tooltips

Check that overlays and popups are labeled, focusable, and dismissible.

• Does a modal set aria-modal="true" and trap focus while open?
• Does a dialog, menu, or popover have a visible label or aria-label?
• Do tooltips only provide supplemental info, not critical content?

ARIA Hygiene

Check that ARIA is used sparingly and correctly.

• Am I only using ARIA attributes when necessary?
• Are all ARIA attributes used valid and appropriate (aria-expanded only on toggles, etc.)?
• Do elements avoid duplicate or conflicting labels?

Miscellaneous

Check that global attributes and temporary messages are handled accessibly.

• Do snackbars/toasts give users enough time to read or provide a way to dismiss them?
• Is the correct language attribute set (lang="en", etc.)?

notes

This is not an exhaustie list and there many more things that can be done ensure that your site is accessibile. In my opinion this list is something that a dev can review and take care of relatively quickly without having to be knowledgeable in accessibility practices.

I left out the color contrast because it can be a little tricky to understand and test quickly. I also feel that in some organizations the devs may not have a say in this matter and a broader discussion it required to resolve it.

.fs-scale {
	--root-fs: 16;
	--min-fs: 1;
	--max-fs: 2;
	--mq1: 300;
	--mq2: 1024;
	--min-width: calc(var(--mq1) / var(--root-fs));
	--max-width: calc(var(--mq2) / var(--root-fs));
	--slope: calc(
		(var(--max-fs) - var(--min-fs)) / (var(--max-width) - var(--min-width))
	);
	--y-intersect: calc(
		(calc(var(--min-width) * -1) * var(--slope) + var(--min-fs))
	);
	--slope-vw: calc(var(--slope) * 100vw);
	--preferred-val: calc(calc(var(--y-intersect) * 1rem) + var(--slope-vw));
	--clamp-fs: clamp(
		calc(var(--min-fs) * 1rem),
		var(--preferred-val),
		calc(var(--max-fs) * 1rem)
	);
}

.fs-scale {
		font-size: calc(var(--min-fs) * 1rem);
}

@media (min-width: 64em) {
	.fs-scale {
		font-size: calc(var(--max-fs) * 1rem);
	}
}

@media (min-width: 1px) {
	@supports (font-size: clamp(1px, 2px, 3px)) {
		.fs-scale {
			font-size: var(--clamp-fs);
		}
	}
}
/* how to use */
<div class="fs-scale title">Title</div>

.title {
	--min-fs: 1;
	--max-fs: 5;
}

I have actually used this in production. There is also a comment with it that says "If you don't understand this, don't use it." It's been quite some time since I wrote it and it turns out that I know how to use it, but I do understand what it is doing. If you think this post will be me trying to explain it to you then you have guessed wrong. I gave the class to multiple AIs and asked them to explain it and then combined the results I liked into one. Here's the comprehensive explanation that emerged from that collaboration:

⸻

What it does (in plain English)

.fs-scale creates smooth, proportional text scaling between viewport breakpoints instead of jarring jumps: • From --mq1 (300px) → use --min-fs (in rem) • To --mq2 (1024px) → use --max-fs (in rem) • Between them → font-size grows linearly along a mathematically precise curve • Below/above them → clamped to min/max boundaries

Think of it like plotting two points on a graph and drawing a straight line between them. Instead of text that's 16px until 768px then suddenly jumps to 24px, you get smooth scaling where text at 600px viewport might be 20px.

Progressive enhancement: Modern browsers get fluid scaling with clamp(), older browsers get sensible breakpoint-based steps.

Ready to implement? If you just want to use this technique, skip to the How to use it section. Want to understand potential implementation challenges first? Check out the gotchas and tips section. If you want to understand the mathematical foundations, keep reading.

⸻

The mathematical foundation

This system implements linear interpolation using the classic equation y = mx + b:

1. Coordinate system setup

--root-fs: 16; /* Base reference: 16px = 1rem */
--min-fs: 1; /* Starting size: 1rem = 16px */
--max-fs: 2; /* Ending size: 2rem = 32px */
--mq1: 300; /* Starting viewport: 300px */
--mq2: 1024; /* Ending viewport: 1024px */

This establishes two coordinate points: (300px, 16px) and (1024px, 32px)

2. Unit normalization

--min-width: calc(var(--mq1) / var(--root-fs)); /* 300÷16 = 18.75rem */
--max-width: calc(var(--mq2) / var(--root-fs)); /* 1024÷16 = 64rem */

Converts pixel breakpoints to rem for mathematical consistency.

3. Slope calculation (rise over run)

--slope: calc(
  (var(--max-fs) - var(--min-fs)) / (var(--max-width) - var(--min-width))
);

Result: (2-1) ÷ (64-18.75) = 0.022 rem per rem of viewport width • For every rem the screen gets wider, font grows by ~0.022rem

4. Y-intercept calculation

--y-intersect: calc(
  (calc(var(--min-width) * -1) * var(--slope) + var(--min-fs))
);

Solves for b in y = mx + b using our known point (18.75rem, 1rem) Result: b ≈ 0.59rem

5. Viewport-responsive value

--slope-vw: calc(var(--slope) * 100vw);
--preferred-val: calc(calc(var(--y-intersect) * 1rem) + var(--slope-vw));

Translates the linear equation to work with current viewport width (100vw) Formula becomes: font-size = 0.59rem + (0.022 × viewport-width)

6. Safety boundaries

--clamp-fs: clamp(
  calc(var(--min-fs) * 1rem),
  /* Never below 1rem */ var(--preferred-val),
  /* Calculated value */ calc(var(--max-fs) * 1rem) /* Never above 2rem */
);

Acts like guardrails ensuring text stays within reasonable bounds on extreme screens.

⸻

Progressive enhancement strategy

The implementation builds in three layers for maximum browser compatibility:

Layer 1: Base fallback (all browsers)

.fs-scale {
  font-size: calc(var(--min-fs) * 1rem); /* Safe minimum */
}

Layer 2: Large screen fallback (older browsers)

@media (min-width: 64em) {
  .fs-scale {
    font-size: calc(var(--max-fs) * 1rem); /* Step to maximum */
  }
}

Layer 3: Modern browser enhancement

@media (min-width: 1px) {
  @supports (font-size: clamp(1px, 2px, 3px)) {
    .fs-scale {
      font-size: var(--clamp-fs); /* Full fluid scaling */
    }
  }
}

The @media (min-width: 1px) hack ensures this rule has higher specificity than the previous media query.

⸻

How to use it

Understanding the theory is one thing, but putting this into practice is where it becomes truly valuable:

1. Add the class

<h1 class="fs-scale title">Fluid Title</h1>
<p class="fs-scale">Body text that scales subtly</p>

2. Set per-element ranges

Override min/max per component via companion classes or inline styles:

/* Dramatic title scaling */
.title {
  --min-fs: 1;
  --max-fs: 5;
} /* 16px → 80px */

/* Subtle body text scaling */
p.fs-scale {
  --min-fs: 1;
  --max-fs: 1.25;
} /* 16px → 20px */

/* Small text scaling */
.small {
  --min-fs: 0.875;
  --max-fs: 1;
} /* 14px → 16px */

Or inline:

<h2 class="fs-scale" style="--min-fs:1.25; --max-fs:2.5;">Section</h2>

3. (Optional) Customize site-wide breakpoints

:root {
  --root-fs: 16; /* Keep accurate: match your actual 1rem in px */
  --mq1: 360; /* Start scaling at 360px instead of 300px */
  --mq2: 1280; /* Stop scaling at 1280px instead of 1024px */
}

⸻

What the provided .title does

.title {
  --min-fs: 1;
  --max-fs: 5;
}

A <h1 class="fs-scale title"> will be: • 1rem (16px) at ≤300px viewports • Smoothly scales from 16px to 80px between 300px–1024px • 5rem (80px) at ≥1024px viewports

The scaling follows the mathematical curve: font-size = 0.59rem + (0.022 × viewport-width)

⸻

Advantages over traditional breakpoints

Traditional approach problems: • Abrupt jumps create jarring user experience • Limited control points (usually 2-3 breakpoints) • Awkward in-between sizes on tablets and intermediate screens • Requires manual fine-tuning for each breakpoint

This fluid system benefits: • Seamless scaling eliminates visual jumps • Mathematical precision ensures proportional growth • Infinite responsiveness works perfectly at any screen size • Accessibility friendly respects user font-size preferences (rem-based) • Future-proof automatically handles new device sizes

⸻

Advanced usage patterns

Once you've mastered the basics, these advanced techniques can expand the system's capabilities:

Container-based scaling (modern browsers)

/* Replace 100vw with 100cqw for container queries */
--slope-cqw: calc(var(--slope) * 100cqw);
--preferred-val: calc(calc(var(--y-intersect) * 1rem) + var(--slope-cqw));

@container (min-width: 300px) {
  .fs-scale {
    font-size: var(--clamp-fs);
  }
}

Multiple scaling ranges

.hero-text {
  --min-fs: 2; /* Start larger */
  --max-fs: 8; /* Scale dramatically */
  --mq1: 320; /* Different breakpoints */
  --mq2: 1440;
}

Reverse scaling limitation

/* This WON'T work - clamp() breaks when min > max */
.broken-reverse {
  --min-fs: 1.5; /* clamp() minimum */
  --max-fs: 1; /* clamp() maximum - invalid! */
}

Note: This system only supports scaling up (min-fs < max-fs). Reverse scaling would require modifying the clamp logic.

⸻

Gotchas / tips

• Keep --root-fs accurate: If html { font-size: 62.5%; } (10px rem), set --root-fs: 10 • Values are viewport-based: Uses 100vw, so horizontal scrollbars can affect scaling • Respect user preferences: The rem-based system honors user zoom and font-size settings
• Performance: Calculations happen once per element, very efficient • Debug tip: Use browser dev tools to inspect --preferred-val and see the live calculation • Accessibility: Always test with 200% browser zoom to ensure readability • Design systems: Consider creating preset classes for common scaling patterns

⸻

Browser support

• Full fluid scaling: All modern browsers (Chrome 79+, Firefox 75+, Safari 13.1+) • Graceful fallback: All browsers back to IE9 get step-based responsive text
• Progressive enhancement: Older browsers still get a good experience, just less smooth

AI can be useful in project planning, especially when writing a product requirement document (PRD) and software requirement specification (SRS). While some teams might let AI handle the entire process independently, I believe AI works best as a collaborative assistant, helping guide and refine your thinking rather than replacing it entirely.

PRD + AI

Instead of telling it to just write the PRD, there should be a dialog about the product idea. Describe the basic concept and let AI probe deeper.

The product team can collaborate with AI throughout the PRD development process, leveraging its analytical capabilities in these key areas:

• Analyze user research and market data like a requirement analyst and thought partner
• Structure insights and research findings into a coherent product vision
• Identify and suggest additional success metrics that align with business objectives
• Surface implicit assumptions that should be made explicit before development begins
• Ensure the PRD addresses all technical, design, and business dimensions that downstream teams will need
• Synthesize design and product perspectives to identify potential conflicts between business requirements and user experience
• Review the completed PRD for inconsistencies, gaps, or unclear requirements
• Analyze proposed changes and assess their ripple effects across other parts of the PRD

This collaborative approach ensures your PRD becomes a robust foundation that reflects both AI insights and human strategic thinking.

SRS + AI

Once you have a solid PRD developed through this collaborative process, you can leverage that foundation to create an equally robust SRS. Use AI to help write the SRS by giving it the PRD, technical constraints and architecture details. This will help in guiding it to create your vision and architectural philosophy.

When writing the SRS you shouldn't solely rely on AI to write out the parts of the system you may not be familiar with. Development teams can enhance AI-generated specifications by leveraging domain expertise in targeted areas:

• Frontend developers review and refine frontend specifications, ensuring alignment with existing component libraries and user interface standards
• Backend developers review and refine backend specifications, ensuring proper integration with current data architecture and API designs

However, keep in mind that AI may not understand existing legacy requirements or technology limitations in either domain.

AI can be a stress test and help find inconsistencies between the PRD and SRS. It can help identify scenarios where the SRS might not address the user needs in the PRD or how tech constraints might limit the envisioned product UX and may reveal important trade-offs that need to be considered.

Analysis of the PRD and SRS can serve as a technical review before coding that can help spot challenges, ambiguities, and suggest alternative tech approaches. It can also help with determining how changes due to technical constraints or product requirements may affect the system.

AI Output

Quality of the outputted documents (SRS & PRD) depends on specificity and context that is given to the AI. The more you can tell it about the technical environment, user base, architectural constraints, the better the AI assistance will be. It also can help with structural analysis, surface blind spots, and translate between different levels of abstraction.

If you have multiple team members or teams involved in writing the SRS or PRD it would help to develop prompt guidelines and technical vocabulary to ensure that there is a consistent style to the output.

The final product of AI assistance depends on you. Its suggestions may not align with team capabilities or organizational priorities. Ultimately, these are your documents. This collaborative approach—where AI enhances rather than replaces human judgment—ensures you get the benefits of AI's analytical capabilities while maintaining the strategic vision and practical wisdom that only your team possesses.

However, always-visible focus rings on every element were considered visually distracting and detrimental to UX. Users found the constant focus indicators overwhelming.

Modern browsers now selectively apply focus rings based on heuristics. Focus styles are crucial for keyboard navigation and programmatic focus management (JavaScript). However, when users directly interact using mouse or touch, focus rings are often redundant. Form elements remain a key exception where clear focus indication remains important.

The :focus-visible pseudo-class addresses this by respecting the browser's intelligent focus indication while allowing style customization. This provides a more nuanced approach, but :focus styles remain necessary for older browser compatibility. However you can get away with just providing :focus-visible styles if you can absolutely guarantee that all your users are on a device that supports :focus-visible , otherwise you will need to use a polyfill or a CSS fallback method.

For broad browser support, consider these fallback strategies:

Method 1: @supports Feature Query

CSS

*:focus { /* Default focus styles */ }
@supports selector(:focus-visible) {
  *:focus { /* Undo default styles in modern browsers */ }
  *:focus-visible { /* Reapply for :focus-visible */ }
}

Method 2: :not(:focus-visible) Fallback

CSS

*:focus { /* Default focus styles */ }
*:focus:not(:focus-visible) { /* Undo default styles in :focus-visible browsers */ }
*:focus-visible { /* Styles for :focus-visible browsers */ }

While less explicit, you could also use:

CSS

*:focus-visible { /* Focus styles for :focus-visible */ }
@supports not selector(:focus-visible) {
  *:focus { /* Focus styles for older browsers */ }
}

Methods 1 & 2 are clearer in demonstrating the fallback approach, explicitly showing default :focus styles being refined for :focus-visible browsers.

Interactive & non-interactive

There are two types of alerts: interactive and non-interactive.

Interactive alerts

Interactive alerts require user interaction, which is usually to confirm or provide an input and to capture the user's attention. They must be persistent, meaning that they are visible until an action that dismisses it is performed by the user. Additionally, it should guide the user through the required action.

For accessibility, alerts require that the focus moves to the alert and focus is trapped. It should not be an aria-live region. The first focusable element in the alert should be focused on. It should be dismissible via keyboard by pressing the Escape key. When the alert is dismissed, focus should return to where it was prior to being moved to the alert.

Non-interactive alerts

Non-interactive alerts are for informational messages that don't require an action. These include form validation, status updates, or system notifications. They can be auto-dismissed or persistent. It depends on the priority of the message. Most of the time, they are implemented to auto-dismiss after a certain time period. 4 seconds is what is recommended. These alerts should also have an action to dismiss, such as a close button or the ability to swipe it away. The alert should not disrupt the user's attention.

For accessibility, non-interactive alerts need to be announced to screen readers by using a live region. They should also appear in the DOM but not receive focus.

For auto-dismissing, the timing is important. It's recommended that the alert stay open for about four to five seconds or longer. The reasoning is:

• Users may miss it.

• Users will have different reading speeds.

• User with Visual or cognitive limitations may need more time to read the message.

It's highly recommended not to auto-dismiss non-interactive alerts, but as with most things, it really depends on the importance of the message.

Alert Decision Table

Conclusion

Overall, I think a basic alert is relatively straightforward. Like most things, it all depends on what kind of alert you are implementing and the additional features that may need to go with it. For example, you may be asked to stack multiple consecutive alerts. During one of the discussions at my work, a stakeholder brought up the idea of having a timer in the alert. You need to think a little about how that would change things. If you want to meet WCAG timing criteria, you would have to devise a way to pause or extend the timer. That's just an example of how things can get complicated in their development.

I hope these notes about alerts have been helpful.

Using tree

In Aider I /run tree -I node_modules and add it to the chat. Then I /ask Aider where to put the file I want to create.

This is what the tree output looks like from the command above. -I is ignore.

├── jsconfig.json
├── package.json
├── pnpm-lock.yaml
├── README.md
├── src
│   ├── app.css
│   ├── app.html
│   ├── lib
│   │   └── images
│   │       ├── github.svg
│   │       ├── svelte-logo.svg
│   │       ├── svelte-welcome.png
│   │       └── svelte-welcome.webp
│   └── routes
│       ├── +layout.svelte
│       ├── +page.js
│       ├── +page.svelte
│       ├── about
│       │   ├── +page.js
│       │   └── +page.svelte
│       ├── Counter.svelte
│       ├── Header.svelte
│       └── sverdle
│           ├── +page.server.js
│           ├── +page.svelte
│           ├── game.js
│           ├── how-to-play
│           │   ├── +page.js
│           │   └── +page.svelte
│           └── words.server.js
├── static
│   ├── favicon.png
│   └── robots.txt
├── svelte.config.js
└── vite.config.js

Using ls

If you don't have tree installed you can do this with ls -R1 which will list all the files in a single column.

node_modules/
package.json
pnpm-lock.yaml
README.md
src/
static/
svelte.config.js
vite.config.js

./node_modules:
@fontsource/
@neoconfetti/
@sveltejs/
svelte@
vite@

./node_modules/@fontsource:
fira-mono@

./node_modules/@neoconfetti:
svelte@

./node_modules/@sveltejs:
adapter-auto@
kit@
vite-plugin-svelte@

./src:
app.css
app.html
lib/
routes/

./src/lib:
images/

./src/lib/images:
github.svg
svelte-logo.svg
svelte-welcome.png
svelte-welcome.webp

./src/routes:
+layout.svelte
+page.js
+page.svelte
about/
Counter.svelte
Header.svelte
sverdle/

./src/routes/about:
+page.js
+page.svelte

./src/routes/sverdle:
+page.server.js
+page.svelte
game.js
how-to-play/
words.server.js

./src/routes/sverdle/how-to-play:
+page.js
+page.svelte

./static:
favicon.png
robots.txt

Misc Terminal ways

Unfortunately macOs terminal ls command can't exclude files or directories. However these commands can.

**ls + grep **

# pipe to grep
ls -R | grep -v node_modules

# pipe to grep with multiple exclusions
ls -R | grep -vE "(node_modules|\.git|dist)"

**find **

# Single exclude
find . -name node_modules -prune -o -print

# Multiple excludes 
find . -name node_modules -prune -o -name .git -prune -o -print

Another alternative for macOs is to install the GNU coreutils

brew install coreutils

gls

# ignore flag
gls -R1 --ignore=node_modules

gls -R1Inode_modules

Why?

I made this for a few reasons.

• I wanted to see how Sonnet 4 is compared to other LLMs for coding.
• I don't like writing alt text very much.
• I can use it at work if they want to integrate it into the cms.
• I never thought it would be hard.
• I haven't really purely vibe coded anything

The last point is really the whole reason why. I just wanted to vibe code something. I really didn't have any plans for this other than I wanted to upload an image or supply a url and have OpenAI's o4 mini model return alt text describing the image. No preconceived design, components, architecture or guidelines for the LLM.

Before we continue I think it's pretty important to inform you that where I work we are all in on AI assisted coding. I pretty much use Aider everyday all day. I don't consider that vibe coding because I do plan out everything I do. I review the code and make sure it is acceptable. I don't rely on it 100% for everything either. We spent a lot of time figuring out what system works for us and creating guidelines for the LLM to use to code.

What I did.

The first thing I did was setup a SvelteKit project with Tailwind. Then ran Aider and started prompting away.

I let the LLM decide on the look and layout of it. I do feel it looks rather Bootstrapish. No big deal. If I really wanted to I could style it myself.

In the end I got what I wanted and more. It does the image upload (to nowhere) and converts it to base64 and then sends it to Sonnet 3.5 for analysis. It returns the output, which is the alt text, into an editable area with a button that can copy the text to the user's clipboard. There is also a way to add additional context for the image to be sent along with the image to give the LLM some help in describing the image better. I was also able to add a history that will let you compare the output with a previous output. That is kept in the browser's session storage. Also on the page there is a section that lists the WCAG criteria for alt text.

I did have to direct Aider on accessibility. Can't make a tool for accessibility not accessible. It would either not do it or would do it badly.

You may have noticed that I am using Sonnet 3.5 instead of o4 mini. The reason is something I think is pretty funny. I felt that ChatGPT would be the right tool to use to write the function that sends the image data to o4 mini. However it failed at it. After playing with it for about 20min I decided, never mind this let's see if Sonnet can write its own function to upload to itself. It wrote one on the first try and I decided to use Sonnet 3.5 instead of 4. Which is not an issue, I can always change it. The reason I wanted o4 mini was because it's cheap.

I did this in 2 sessions and it took a total of about 4 hours. It cost something like $4 USD to make.

What I did according to AI

Since the entire Aider log is available, I gave it to Claude and ChatGPT to give me a summary of what I did.

Both of them broke it down into several steps. ChatGPT counted 8 and Claude counted 7. Both of them were pretty much the same. The following list is paraphrasing their steps.

Step 1: Initial setup

I setup the SvelteKit project and tailwind and the initial AltText.svelte component creation. This was done without Aider. It was just typing in the npm command in my terminal to create a Svelte project with tailwind and whatever other options I selected. After that it was creating the AltText.svelte component which I left empty.

After that is when I started to use Aider to start making the component. I had it make the switch which toggles between image upload and URL input, with base64 conversion for LLM processing. I didn't do any back-end wiring.

Step 2: UI/UX

This is where I added the file upload button and drop area, URL sanitization, and submit button. I also had it display some placeholder text in an editable textarea with copy-to-clipboard functionality. This gave me the first visible flow of how it would work before hooking up to an API. I let Sonnet decide on the look of everything. At most I told it to move things, for example to place the input for additional context above the submit button instead of after.

Step 3: Accessibility

In this step I reviewed the accessibility of what was made with Aider and Sonnet. It was missing some keyboard interactions. The uploader did not work at all with the keyboard. You would tab past it. The inputs were missing labels. I also took care of the error handling in this step and did a little bit of UX work.

I made the submit button look disabled. From my understanding when you add the disabled attribute to form elements, screen readers will not have any visibility on the element and skip over them. You could still click on it or submit via keyboard but you would get an error message saying you need to upload something.

I also added an accordion that displays the WCAG guidelines for alt text. I think it's a useful thing to have but also not be in the way of the UI. Which is why I put it in an accordion.

Step 4: Polishing and more features

I tried to add some quality metrics here. I added a character counter and tried to make a quality meter. This is where the AI really seemed to struggle. It chose to do some funky way of measuring the character count with a Svelte $effect. I had to tell it to just do a normal character count on the returned text.

The quality meter didn't really work. Sonnet implemented a series of general conditions that you could consider a good starting point for a quality meter. For example one of the conditions was that it checked if the words image, or picture of were used. The conditions were ok, however the meter just stayed red all the time and never changed to green. The best way to have done this would be to send it back to an LLM for evaluation. I considered that out of the scope of what I wanted. I decided to just eliminate that feature altogether.

I also added a reset feature to clear everything and a history section that uses the session storage. You can compare the text to a previous version in the event that you regenerated the alt text. Sonnet made a nice little modal that would show you the 2 versions.

Step 5: Backend API

Originally I wanted to use OpenAI's GPT o4 mini. I thought ChatGPT would be the best person (AI) to write code for that. I didn't use Aider with the OpenAI API for this. I did it in the chat window. The results didn't work. Even when I gave some example code from its own documentation it just didn't work. After mucking around with it for a bit, I decided to switch to having Sonnet write code for itself to analyze the image. I did this in Aider because it was still connected to the Anthropic API. Worked on the first try.

Step 6: Clean up and even more features.

The last feature I added was showing a thumbnail of the image in the history preview section. Then I had Sonnet clean up the code, add JSDoc and write a README.md.

Insights from ChatGPT and Claude.

In addition to summarizing, I also asked both ChatGPT and Claude to give me some key insights they got from the logs. I am just going to paste in exactly what each wrote out. Claude made a list and ChatGPT made a table. Overall I agree with their observations.

Claude

1. Iterative UX Design

Your process shows excellent iterative refinement - starting with basic functionality and continuously improving based on usage patterns. The progression from prominent WCAG guidelines to a subtle question mark icon demonstrates user-centered design thinking.

2. Accessibility as a Core Requirement

You spent significant time on accessibility improvements, treating it as essential rather than an afterthought. This included keyboard navigation, proper error messaging, and ARIA attributes - valuable for readers building inclusive applications.

3. Technology Pragmatism

• Svelte 5 over React: Your preference for Svelte 5 runes shows consideration for developer experience
• Provider Flexibility: Switching from OpenAI to Anthropic when encountering issues demonstrates adaptable architecture
• No TypeScript: Choosing JavaScript for rapid prototyping while leaving TypeScript as an option

4. Real-World Problem Solving

The log reveals common development challenges:

• Svelte 5 reactivity debugging (character count issues)
• Browser API limitations (contenteditable with two-way binding)
• Environment variable security considerations

5. User Experience Evolution

The progression from basic alt text generation to a full-featured tool with history, context, regeneration, and quality feedback shows how requirements naturally expand during development.

6. Development Workflow Insights

Your use of an AI coding assistant for rapid iteration demonstrates modern development practices - using AI for boilerplate while maintaining control over architecture and UX decisions.

ChatGPT

The overall experience

I'd say the overall experience of vibe coding something was pretty fun. A little frustrating when it would just kind of do something stupid or just not be able to do what you asked at all. However that is not much different from dealing with people in my opinion.

It wasn't a super complex project or really a hard project. If I had not used AI it probably would have taken about 1-3 days. I know I would have gotten caught up in the UI parts of it especially the styling part. The longer I would have taken on it, the more scope creep would happen. I recognized from my past personal projects I need to watch adding additional unplanned features. It's always "while I am doing this I can extend it to do that" or "why not one more crazy idea."

Coding with AI without a fully structured plan can be pretty tricky and hard. I mentioned earlier that I do use Aider at work but we have a plan, designs and a product to make. If you let the vibe coding get out of hand you will get a lot of weird code and kind of waste money because you will find yourself going 2 steps forward 1 step back.

Unfortanately you can't do this in Svelte. The binded variable will be assigned the last element in the each block.

<script>
    let elementArray; 
    // elementArray = div
</script>

{each items as item } 
    <div bind:this={elementArray}>{item}</div>
{/each}

A small change to that example will produce an array of elements.

<script>
    let elementArray = [];
    // elementArray = [div, div, div...]
</script>

{each items as item, index } 
    <div bind:this={elementArray[index]}>{item}</div>
{/each}

vw = hundredths of the viewport width. vh = hundredths of the viewport height.

This is how to calculate 1vw or 1vh

// 1vh
100 / document.documentElement.clientHeight;

// 1vw
100 / document.documentElement.clientWidth;

// calculate a px value of 30
(100 / document.documentElement.clientHeight) * 30
(100 / document.documentElement.clientWidth) * 30