Designing a Web Inspiration Gallery That Actually Works

I built a web design inspiration gallery last month. I didn't start with a mood board, a color palette, or a fancy design system. I started with a single technical decision that most designers get backwards: I built the mobile version first, and I made it boring on purpose. That's my contrarian claim. The flashy desktop version—the one you'd pin to Dribbble—came last. If you're imagining you're a solo designer launching a side project to showcase great web design, this is the field report I wish I'd read before I started.

Why mobile-first isn't just a slogan

Mobile devices accounted for 52.57% of worldwide website traffic in July 2026 (StatCounter Global Stats). That's the majority. If you design desktop-first, you're designing for the minority and then cramming. I used a mobile-first strategy: fluid grids with relative units like percentages and fr, flexible images with max-width: 100%, and media queries added only when the content demanded them (MDN Web Docs). The viewport meta tag <meta name="viewport" content="width=device-width, initial-scale=1.0"> was the first line of HTML I wrote. That set the foundation. Everything else—the grid of screenshots, the filter bar, the detail view—grew from there.

The trap of fixed breakpoints

I see designers reach for 375px, 768px, 1024px, and 1440px as if they were sacred. They're not. Those are common reference values, but the rule is to add breakpoints when your content breaks, not when a device manual says so (MDN Web Docs). For my gallery, the card grid looked fine at 320px. It started to feel cramped at around 600px, so I added a breakpoint there. At 900px, the sidebar filter became useful, so I added another. Two breakpoints. That's it. I used CSS Grid with the fr unit for the card layout and Flexbox for the filter bar. No framework, no utility classes. Just modern CSS.

Container queries changed how I built cards

Here's the part that made me feel like I was cheating. Each inspiration card—a screenshot, a title, a short description, a tag—needs to look good whether it's in a narrow sidebar or a wide three-column grid. Media queries can't help with that because they only know the viewport. Container queries can. With @container, the card responds to its own container's size (MDN Web Docs). I set container-type: inline-size on the wrapper and then used cqi units—1% of the container's inline size—to scale the title and padding. The same card component now works in a 280px sidebar and a 600px hero slot. No JavaScript, no duplicate markup. Container queries have been Baseline Widely available since February 2023, so this isn't experimental.

Accessibility is not a checklist, it's a design constraint

I ran my first build through a contrast checker. My tag pills failed. WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (WCAG 2.1 AA). My light gray tags on a white background were around 2.1:1. I darkened them. Then I checked my focus states. WCAG 2.1 SC 2.4.7 Focus Visible requires a visible keyboard focus indicator (W3C WCAG 2.1 Understanding Focus Visible). I had removed outlines because they looked ugly. That's a classic mistake. I added a 2px solid outline with a 3:1 contrast ratio against adjacent colors. The gallery is now fully keyboard operable, which matters because WCAG 2.1 SC 2.1.1 Keyboard requires all functionality to be operable through a keyboard interface (W3C WCAG 2.1 Understanding Keyboard). That means every filter, every card, every modal. No exceptions.

Performance: the numbers that actually matter

A gallery is image-heavy. I used AVIF with WebP fallbacks via the <picture> element. According to MDN, lossy AVIF images are around 50% smaller than JPEG images of similar quality, and lossy WebP is 25-35% smaller than JPEG (MDN Web Docs). That's a massive win for load time. But I also set explicit width and height attributes on every image to reserve space and avoid layout shifts. My target was a Cumulative Layout Shift of 0.1 or less, a Largest Contentful Paint of 2.5 seconds or less, and an Interaction to Next Paint of 200 milliseconds or less (web.dev). I hit those on mobile. The biggest surprise? Lazy-loading off-screen images with loading="lazy" cut my initial page weight by more than half. That's free performance.

Dark mode and motion preferences

I built the default light color scheme and then overrode colors inside a @media (prefers-color-scheme: dark) block (MDN Web Docs). That's the standard pattern. But I also added a prefers-reduced-motion query to disable the subtle hover animations on cards. WCAG 2.1 SC 2.3.3 Animation from Interactions requires that motion animation triggered by interaction can be disabled unless it's essential (W3C WCAG 2.1 Understanding Animation from Interactions). My animations are not essential. They're decorative. So I respect the user's system preference. It's three lines of CSS.

What I'd do differently next time

I wasted two days trying to make a complex filter UI work on mobile. I should have started with a simple dropdown. The lesson: don't design the desktop filter bar and then collapse it. Design the mobile filter first, then expand it. Also, I didn't test with a screen reader until week two. That was a mistake. I found missing form labels and empty buttons that I had to fix retroactively. WebAIM's Million study found that 95.9% of home pages had detected WCAG 2 failures, and the six most common error types—low contrast text, missing alt text, missing form labels, empty links, empty buttons, missing document language—account for 96% of all detected errors (WebAIM Million). I had three of those six. Fixing them took an afternoon, but it would have taken twenty minutes if I'd started with accessibility in mind.

• Mobile-first is not a slogan; it's the majority of your traffic.
• Container queries are the right tool for reusable components.
• Accessibility constraints make your design better, not worse.
• Performance is a design feature, not an afterthought.

If you're building a gallery or any content-heavy site, start with the smallest screen and the most restrictive constraints. Design for the user who can't see your hover animation, who's on a slow connection, who navigates with a keyboard. The desktop version will still look great. But more importantly, the mobile version will actually work. And that's the only version most of your visitors will ever see.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• web.dev (Web Vitals) - https://web.dev/articles/vitals
• W3C WCAG 2.1 Understanding Keyboard - https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html
• W3C WCAG 2.1 Understanding Focus Visible - https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html
• WebAIM Million - https://webaim.org/projects/million/