I thought I finished. I'd shipped the Meet Landing Page challenge and taken my victory bow. Then Frontend Mentor rolled out a new feature: automated audits for accessibility, HTML, CSS, and JavaScript. Suddenly, the project wasn't over. It was calling me back for a rematch.
I compiled all the feedback, opened ChatGPT, and asked it to help me design a focused five-day refactor: 30 minutes a day, real improvements.
Going back in the ring meant two things:
- I'd have to get over my GitHub fears. I’ve treated Git like a minefield. Every time I messed up a branch, I’d nuke the repo and start over. That ends here.
- I'd also have to work with my ADHD, not against it. My hyperfocus gives me an edge, but it also gives me burnout. And after two weeks, I was running on fumes.
Did I want to work on this refactor? No. I wanted to dive into the new Art Gallery challenge. But this refactor could become my first dev case study. And that is new.
Let's go.
Day 1: Git Confidence & Semantic HTML
What did you tackle?
- Created a new branch inside VS Code
- Fixed low-contrast text (accessibility)
- Rewrote
<div>s with semantic HTML - Fixed a layout bug: the missing logo
Why did it matter (tech-wise)?
Starting with Git felt risky. I'd always feared breaking things. But I realized the irony: a branch is how you protect your main project. This time, I used git status, git add, and git commit with confidence. That clarity helped.
Using Chrome DevTools and the WebAIM Contrast Checker, I tracked down all the low-contrast text. Those little "!" icons in DevTools? Lifesavers.
I also replaced non-semantic elements with proper headings. Screen readers—and humans—deserved better than creative-but-cryptic names.
Then, the missing logo bug: I'd trapped it inside an over-dived, over-padded container. So I created a structure rule: use <header>, <main>, and <section> first, then <div>—but only when necessary. Cleaner code = better accessibility.
What did you learn or change for the future?
- Figma "padding" doesn’t map 1:1 to CSS. Sometimes it’s margin. Sometimes it’s container padding. That explained my missing logo.
- Semantic tags aren’t just "nice"—they’re critical for accessibility.
- Git is a versioning system, not a punishment system. Here's how I created a new branch:
git branch <new-branch-name>
git branch -a # check all branches
git status # see current branch and file changes
git add . # stage all changes
git commit -m "Refactor: example"
Commit types I’m learning to use:
fix:bug fixesrefactor:cleanups, improvementsfeat:new featuresstyle:non-functional style tweaksdocs:readme, comments
Deep Dive Sources
- https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
- https://developer.chrome.com/docs/devtools/accessibility/contrast
- https://www.reddit.com/r/DesignSystems/comments/1e1dwqp/difference_between_padding_in_figma_and_in_code/
Day 2: Cleaning Up Broken CSS Habits
What did you tackle?
- Unnecessary and/or broken rules
Why did it matter (tech-wise)?
I removed position: relative. When writing the footer, I was layering multiple items, so I thought I needed it everywhere.
Wrong. That led to cluttered, over-styled code.
The CSS report flagged lots of recurring selectors. It suggested I create custom properties (CSS variables). I didn’t implement them yet—it was out of scope—but I took note. Next time: build a base stylesheet before diving into layout.
What did you learn or change for the future?
I’ve always built desktop-first. It felt natural. But accessibility experts and reports nudged me toward a blended approach. Mobile-first CSS isn’t just about phones. It’s about starting lean and layering complexity.
Deep Dive Source
https://www.boia.org/blog/accessibility-tips-avoiding-a-desktop-first-or-mobile-only-mindset
Day 3: Scalable Units & Style Strategy
What did you tackle?
- Fixed units
Why did it matter (tech-wise)?
I had been mixing px, em, and rem without strategy.
Responsive design adapts to devices. Scalability ensures future growth. A Discord dev recommended the “px-to-rem” extension by Marco N—huge time-saver.
)
What did you learn or change for the future?
TL;DR for when to use px, em, and rem:
-
rem→ for font sizes, margins, padding, media queries -
px→ for precise values like borders, shadows, icons -
em→ for component-specific spacing inside elements like buttons
Deep Dive Sources
- https://www.freecodecamp.org/news/css-units-when-to-use-each-one
- https://blog.logrocket.com/ux-design/building-scalable-design-ux/
Day 4: Grid Systems & RTL Support
What did you tackle?
- Excessive columns in my grid layout
- A layout bug at
820px - Learned about logical properties
Why did it matter (tech-wise)?
I learned grid systems from TheNetNinja (highly recommend). But I copied repeat(12, 1fr) everywhere—even when I only needed 3 columns. That clutter caused layout bugs, especially at medium breakpoints.
By reducing column count, I fixed the 820px skewing bug.
The numbered sections looked weird because they were squeezed into excessive grid columns.
A Discord dev introduced me to logical properties like margin-inline-start and margin-inline-end. They’re not just cleaner. They support right-to-left languages and boost global accessibility.
Deep Dive Source
https://medium.com/@nnveux/embracing-margin-inline-start-for-better-rtl-support-in-web-design-e8a66b2c3e19
Day 5: Final Clean-Up & Long-Term Habits
What did you tackle?
No major bugs—just polish and validation checks:
Why did it matter (tech-wise)?
These sites are part of my growing "build-good" developer checklist.
What did you learn or change for the future?
I explored modern CSS functions like clamp() and min().
Haven’t implemented them yet—I’m choosing depth over speed.
For now, I want to master layout, semantics, and responsive thinking. Fluid scaling is next.
Final Thoughts
Five days. Five focused sprints.
One sharper junior dev.
This refactoring taught me more than the original build. I learned how to:
✅ Read automated audit reports
✅ Fix accessibility bugs
✅ Navigate Git without fear
✅ Think structurally about HTML and CSS
Even better? I carried this into my next challenge.
While starting the Art Gallery build, I wrote a global stylesheet up front. I view Figma critically now. For example, the mobile and desktop layouts diverge subtly. So I'm structuring the HTML with those breakpoints in mind.
Refactoring didn’t slow me down. It made me deliberate.
I want to go faster, but going slow and right will get me further than fast and wrong.
Top comments (1)
I love the conclusion. In the times where developers are forced to be fast and all knowing because of AI, you take the time to think about what you are going to do.
Slowness is not a bug, it is a feature when the time is spend wisely.