Before this come part one, on architecture, and part two, on privacy and regulation.

Five failures that gave no warning at all

Liquid doesn't throw errors: it returns nothing. Jekyll's template language, faced with a mistyped key, doesn't complain: it returns emptiness. The result is a link with an empty destination, or a blank label. The page builds, ships and is broken. I discovered that an identifier behaved differently with and without quotation marks — without them it was treated as a non-existent variable — by watching an illustration vanish with no explanation whatsoever.

YAML is case sensitive. I wrote jobtitle in a data file and jobTitle in the template. The result was a null value in the page's structured data. Perfectly valid JSON, data lost, zero warnings.

The filter that was computed and never used. In the blog listing, the per-profile filter was correctly stored in a variable… and the loop went on iterating over the full collection. The IT blog was also showing Administration articles. Worse still, it was camouflaged, because the profile with no articles did show the "nothing here yet" message and the others "showed articles". Everything looked like it worked.

Method lesson: check what comes out, not just whether something comes out.

The skip link with no styles. From day one the site had a "Skip to content" link for keyboard users. The markup was there… and it never had any CSS. For weeks it had been appearing as loose text in the corner of every page and I read straight past it.

The focus that didn't move. And once I finally styled it, it still didn't work properly: pressing it scrolled the page down to the content, but keyboard focus stayed at the top. The next tab press sent you back into the header. It looked like it worked. The fix was to let the main element receive focus programmatically.

That last one deserves an explanation, because it's the perfect illustration of why it exists:

flowchart LR
  accTitle: Keyboard journey with and without a skip link
  accDescr {
    Without a skip link, a keyboard user has to press tab around twelve times to get through
    the whole header before reaching the content, and must do so on every page they visit.
    With a skip link, the very first tab press offers to jump straight to the content on the
    second press.
  }
  subgraph WITHOUT["Without a skip link"]
    direction LR
    A1["Tab 1"] --> A2["..."] --> A3["Tab 12"] --> A4["Content"]
  end
  subgraph WITH["With a skip link"]
    direction LR
    B1["Tab 1:<br/>Skip to content"] --> B2["Content"]
  end

The header has around twelve links. Without a skip link, someone navigating by keyboard goes through all of them on every single page they visit. That's success criterion 2.4.1, Bypass Blocks, and it's level A: the bare minimum.

The styling has a nice technical twist. A single focus ring will always fail against some background, and there are eight palettes here. The solution was a double concentric ring: a light outline with a dark shadow around it. The outline paints on top of the shadow, so one of the two will contrast against any possible background. And it sits above the sticky header, which also covers criterion 2.4.11, Focus Not Obscured, new in version 2.2.

The audit: twenty reports, and what none of them catches

The target was WCAG 2.2, level AA. I did the automated part with axe DevTools against the live site: twenty reports, covering all eight palettes, with the full battery of guided tests — keyboard, forms, structure, images, tables, dialogs, interactive elements. Final result: zero issues.

What had to be fixed along the way:

But something that often goes unsaid is worth saying: automated tools catch roughly a third of real problems. The rest has to be seen by a person. That meant:

• Reflow at 320 pixels wide across fourteen pages, with no horizontal scrolling and no loss of content.
• Text-only zoom to 200%. This uncovered a fault no tool would have caught: as the text grew, so did the sticky header, and the scroll offset reserved for it fell short. Anchors were leaving the heading half hidden.
• Forced text spacing, in case someone applies their own stylesheet.
• A full keyboard pass: reachability, visible focus, logical order, no traps.
• The NVDA screen reader, the most widely used in Europe.

And one criterion no tool on earth can check: 3.1.2, Language of Parts. When I leave a Spanish expression untranslated in an English text — say chácaras y tambor, the instruments of a Canary Islands folk group — it has to be marked up as such, or the screen reader will pronounce it using the rules of the wrong language and the braille display will apply contractions that don't belong. No machine knows that an unmarked phrase is in another language. Only someone reading it does. (Yes, that phrase above is marked up. Go and look at the source.)

That's the work still outstanding, and it's why this site's accessibility statement isn't published yet: I'd rather write it when I can say exactly what I've measured.

Two details I learned from

Reduced motion. The site honours the system preference for reduced motion. The interesting part is how: the duration is set to one hundredth of a millisecond, not to zero. At zero, some animations never fire at all, and a script waiting for a "transition ended" event waits forever. It's also one of the few places where marking a rule as important is justified: it implements the user's intent, not the developer's.

The client is never a security boundary. Character limits, required fields and the form's character counter are convenience, not defence. Anyone who can edit the HTML can edit the JavaScript. The real defence always lives on the server.

Publishing

The native GitHub Pages builder was no use to me: it's pinned to a much older version of Jekyll and supports neither the bilingual plugin nor modern Sass. That wasn't a preference, it was a constraint: a custom workflow was the only way.

flowchart LR
  accTitle: Automated publishing pipeline for the site
  accDescr {
    Pushing changes to the repository's main branch starts a GitHub Actions run that sets up
    Ruby and installs the dependencies, builds the site in production mode, packages the
    result and deploys it to GitHub Pages, which serves it under the custom domain.
  }
  A["Push to the main branch"] --> B["GitHub Actions"]
  B --> C["Ruby 3.3<br/>and dependency install"]
  C --> D["Build<br/>in production mode"]
  D --> E["Package the site"]
  E --> F["Deploy to GitHub Pages"]
  F --> G["carloslb.com"]

Three things I learned there:

URL and base path are not the same thing. One key is protocol plus domain; the other is the subfolder within that domain, and it only takes a value if the site doesn't live at the root. Putting the domain in the second one would duplicate the domain in every generated link and break absolutely everything. Before going live, that key was still pointing at my virtual machine's private IP: had I left it, the sitemap and the canonical URLs would have shipped pointing at an address on my local network.

Intermittent failures are the worst kind. The bilingual plugin has a documented race condition on continuous integration runners: one process writes into a language directory another hasn't created yet. It fails sometimes. You turn parallelisation off and that's that.

The last hurdle was daft and highly instructive. The push was rejected because of the commit's email address. I had fixed the Git configuration, but configuration only affects future commits: the one already made kept the old author. You fix it by rewriting the authorship of the pending commit — harmless as long as nothing has been pushed yet.

What I take away

1. The silent failure is the enemy. What isn't complaining isn't fine: it's quiet.
2. Magic numbers lie. When a number describes something that can change — an element's width, a header's height — sooner or later it stops being true.
3. Cohesion prevents errors that discipline doesn't. Two tags whose relative order matters belong together in one place, not "correctly positioned" separately.
4. The output folder doesn't always empty itself. Faced with anything odd: stop, empty, start again, and then diagnose. I lost an afternoon chasing a ghost path left over from an earlier build.
5. Check the source before asserting.

That last one deserves to close the series, because it ties back to what I said in part one about working with an AI assistant. It got things wrong three times in the same way: asserting with confidence something inferred from an incomplete source — a truncated file listing, an out-of-date copy of the project, a filename cut short by length. On one of those occasions it even corrected me when I was right.

I caught all three because I know my own project and because something didn't sit right. And that's exactly the same lesson as the rest of the article: a confident, wrong answer is a silent failure too. It throws no error. It sounds good. And it needs checking just like a loop that "shows articles".

Whoever gives you an answer, go and look at the source.

The code for all of this is at github.com/carloslb-com/carloslb-com.github.io. If anything here is useful to you, take it. And if you run into an accessibility barrier on this site, get in touch: I'd rather know than be right.

In part one I covered the architecture. Here comes the part you can't see.

The diagram that gave me away

I was going to write articles with diagrams, so I set up Mermaid. It worked first time: one line pointing at a public delivery network and done.

I spotted the problem while rereading the cookie policy I had just written. That line lived in the base template, which is to say on every page of the site. Every visitor, whichever door they came through, was handing their IP address to an outside company in order to load a library that was only needed on articles with a diagram. In other words: none. I was declaring one thing and doing another.

Self-hosting it cost more than it looked:

• The modern bundle uses code splitting: the main file imports dozens of chunks from a sibling folder. Copying the single file breaks those imports — which is exactly why an earlier attempt kept "missing files". The fix was to use the classic single-file build.
• GitHub doesn't publish compiled builds. The repository holds the source code; the distribution folder lives in the package registry, and that's where the public networks copy it from. You have to go and fetch it from the right place.
• A JavaScript trap that cost me a while: an import inside a script that isn't declared as a module throws a syntax error that kills the entire script. It isn't that line that fails: nothing runs at all.

The library now lives on the site itself and loads only on pages that declare they contain a diagram. I did the same with the maths formulas, with an extra trap: in the current version the fonts don't ship with the package and the loader points to an external network by default. If you don't override that, you've self-hosted the engine and you're still calling out.

The result: this site doesn't load a single third-party resource. Typefaces, icons, diagram and formula engines: all served from here.

No cookies, and that isn't a marketing line

There are no cookies. No analytics, no advertising, no session. So there's no consent banner either, because there would be nothing to consent to.

The only thing stored in your browser is your theme preference, light or dark, in local storage. According to the cookie guidance issued by the Agencia Española de Protección de Datos (the Spanish data protection authority), that counts as technical storage for personalisation at the user's request, and is exempt from consent. The difference isn't the mechanism: it's what you use it for.

The form: sending a message without a server of your own

A static site can't process a form. You need a third party. I compared fourteen services against three criteria: that the data be processed within the European Union, that there be a proper data processing agreement, and that the free tier actually be usable.

sequenceDiagram
  accTitle: The journey of a message sent through the contact form
  accDescr {
    The visitor fills in the form on the site and submits it with an ordinary HTTP request,
    without the site needing any JavaScript of its own. The provider, whose servers are in
    Germany, applies its spam filter and honeypot field, then responds with a verification
    page of its own. There the browser solves a cryptographic challenge by itself and the
    person is only asked to confirm with a click. The provider then delivers the message to
    the mailbox and redirects the visitor to the site's thank-you page.
  }
  participant V as Visitor
  participant W as carloslb.com
  participant F as Provider (Germany)
  participant M as Mailbox
  V->>W: fills in and submits the form
  W->>F: ordinary HTTP request, no JavaScript of its own
  F->>F: spam filter and honeypot field
  F-->>V: its own verification page
  Note over V,F: The browser solves the challenge.<br />the person is only asked for a click
  V->>F: confirms with a click
  F->>M: delivers the message
  F-->>V: redirects to the thank-you page
  Note over V,F: None of the provider's resources are embedded in the site

That detail about the captcha is the key one: it is served on the provider's own page, after you press send. Nothing of theirs is embedded in my site, and the form submits with plain HTML, without any JavaScript of its own.

And the kind of captcha matters as much as where it lives. There's no distorted text to decipher and no traffic lights to point at: the browser solves a cryptographic challenge by itself, and the person is only asked to confirm with a click. That isn't merely convenience, it's accessibility. Image-based captchas are a well-known barrier for people with low vision or those using a screen reader; when the device does the work instead of the person, there's no visual or audio test left to pass.

I ruled out one competitor for processing data in the United States and using cookies, and another — open source and rather elegant — because it required a back end of my own that I don't have.

Two more decisions about the form:

Data minimisation. Name, email, subject and message. No phone number, no line of business. If I don't need it in order to reply to you, I don't ask for it. That's what the regulation requires, but it's also common sense: data you don't hold can't leak.

Disabling the submit button until the form is valid: ruled out on accessibility grounds. It's a widespread pattern and it's a bad one. A disabled button doesn't explain why it's disabled, and since it can't receive keyboard focus, a screen reader won't even announce it. The person is left facing a form that doesn't respond, with no clue as to why. The browser's native validation already warns them and moves focus to the offending field. Less code and more accessible.

Which regulations actually apply

This is where my other trade comes in. Before copying a legal template, I worked out what does and doesn't bind me. This is my reading of my own case, not legal advice: if your situation differs, so does the outcome.

flowchart TD
  accTitle: Which regulations apply to a personal website with no economic activity
  accDescr {
    Four checks. Royal Decree 1112 of 2018 on accessibility only covers the public sector,
    so it does not apply. Law 11 of 2023 does not apply because there is no e-commerce. The
    Spanish information society services act does not apply because there is no economic
    activity, which means neither a legal notice nor a cookie policy is mandatory. The
    General Data Protection Regulation, on the other hand, does apply, because the contact
    form collects personal data: a privacy policy is mandatory.
  }
  A["Is this a public sector site?"] -->|No| A2["Royal Decree 1112/2018:<br/>does not apply"]
  B["Is there any e-commerce?"] -->|No| B2["Law 11/2023:<br/>does not apply"]
  C["Is there any economic activity?"] -->|No| C2["LSSI-CE: does not apply<br/>Legal notice and cookie policy<br/>are not mandatory"]
  D["Is personal data collected?"] -->|"Yes: the form"| D2["GDPR: applies<br/>Privacy policy mandatory"]

The result: of the four documents everyone copies, only one was actually required. I keep the others by choice — I'd rather err on the side of too much — but with one rule:

Keeping the document is not the same as keeping the fiction.

Legal templates come bloated. The one I downloaded declared processing for commercial, statistical and browsing-analysis purposes. None of that exists here. And declaring processing that doesn't exist does harm twice over: it misinforms the reader, and it commits you to legal bases you don't have. So I pruned everything that wasn't true.

The same goes for the data I publish about myself: name and email address. No national identity document, no home address, no phone number. The template asked for them; the law, in my case, does not. For consistency, the repository commits use GitHub's no-reply forwarding address, and there is no email address in the pages' structured data: address harvesters crawl precisely there.

You can read the outcome in the privacy policy and the cookie policy. I rewrote the latter from scratch, because a template that opens by explaining which cookies it uses is no use for saying that you use none.

Next: in part three, what nearly broke the site without throwing a single error, how you actually audit accessibility, and why the GitHub Pages builder wasn't an option for me.

I started in early June 2026. The site went live on 22 July. In between there are a fair few decisions you can't see, and those are exactly the ones worth telling: the value of a portfolio isn't in the list of technologies, it's in the reasoned trade-offs.

All the code is out in the open: github.com/carloslb-com/carloslb-com.github.io.

The principle that ordered everything else

Before writing a single line I set myself a limit: have something to show, rather than being 99.9% accurate. A perfect portfolio that never ships isn't a portfolio, it's a folder. And a working motto: robustness over brevity or cleverness. Every time I hesitated between the clever solution and the boring one that holds up, the boring one won.

The stack, and why

The important thing about that table is what isn't there: no database, no CMS, no third-party services embedded anywhere. A static site is a pile of HTML files. There's no session to steal and no query to inject.

One person, three worlds

The structure is identical across the three profiles. Header, sections, blog, footer: the same. The only thing that changes is the skin: the palette and the typeface.

flowchart TD
  accTitle: Site structure, with a neutral landing page and three profiles
  accDescr {
    The landing page is a neutral space with three doors: IT and Telecommunications,
    Administration and Human Resources, and Training and Teaching. All three lead to the
    same page structure, and the only thing that differs between them are the CSS tokens
    that define the colour palette and the typeface.
  }
  H["Neutral landing page<br/>(three doors)"] --> IT["IT / Telecommunications"]
  H --> AD["Administration / HR"]
  H --> FO["Training / Teaching"]
  IT --> B["Same structure:<br/>header, sections, blog, footer"]
  AD --> B
  FO --> B
  B --> T["Only the CSS tokens change:<br/>palette and typeface"]

That's eight palettes: four worlds (the three profiles plus the neutral landing page) times two themes, light and dark. I validated them all at high contrast — most of them at AAA level — before writing a single line of content. Fixing contrast at the end means redoing everything.

The typefaces are self-hosted as woff2. The body text is Atkinson Hyperlegible, designed specifically for low vision. Headings change by world: JetBrains Mono for IT, IBM Plex Serif for Administration, Nunito for Training. A typeface says a great deal before the first word is read.

The data — projects, certifications, courses, work history — lives in YAML, following a key → {es, en} pattern. Only what actually changes between languages gets translated. A year is a year in both.

A small decision with large consequences

The profile class lives on the html element, not on body, alongside the theme attribute. If it lives on body, the browser has already started painting by the time you apply the theme, and you get a flash of the wrong palette. With the class at the top, the script runs before there's anything to flash.

Side effect: because both attributes hang off the same element, the palette selectors are concatenated without a space. Yes, CSS has its own small print too.

Colour can depend on JavaScript; navigation cannot

This is the decision I'm proudest of, and the one that ruled out the most.

The requirement was: if you enter the blog through the IT door, the article should feel like IT. But an article is a single file, and it can be reached from three places and in two languages.

Path 1: generate physical versions of the article per context. Three contexts times two languages is six versions of every article. Unworkable maintenance and duplicate URLs competing with each other. Ruled out.

Path 2: have JavaScript rebuild the navigation bar on the fly. More code, more fragile, and without JavaScript the visitor can't navigate at all. Ruled out.

What I did: the colour and the typefaces do change according to the door you came through; the navigation bar stays put.

sequenceDiagram
  accTitle: How an article takes on the colour of the door you came through
  accDescr {
    From the IT blog listing, the link to the article carries a parameter indicating where
    the visitor came from. The article is served with the neutral skin. A script placed in
    the document head reads that parameter before the browser paints anything, applies the
    matching profile class and removes the parameter from the address bar. The navigation
    bar never changes.
  }
  participant L as IT blog listing
  participant N as Browser
  participant A as Article
  L->>N: link carrying the origin parameter
  N->>A: requests the article (served with the neutral skin)
  A->>A: a script in the document head reads the parameter before painting
  A->>N: applies the IT skin and cleans up the address
  Note over N,A: The navigation bar never changes

If the script fails, the article shows up in neutral colours and reads perfectly. Nobody is locked out.

Two takeaways from that, which I've already reused elsewhere:

When every solution to a requirement is a bad one, sometimes the problem is the requirement, not the solution.

Look for the version that delivers most of the perceived value for a fraction of the cost. Colour gives you 90% of the sense of being in a different world. A dynamic navigation bar added 10% at enormous cost.

How I worked on this

I didn't do it alone. I used an AI assistant as a tool: for reference, for learning Jekyll and Liquid, for diagnosis when something didn't add up, and for organising and tracking the tasks of a project that ran for two months and has a lot of moving parts.

I'm saying so plainly, because hiding it would be the exact opposite of what I stand for. And because the distinction matters: the tool speeds up research and keeps the work organised, but it doesn't make the decisions. The ones above — what to rule out, which requirement to question, where to stop — are mine, and each of them has its reasoning written down. In part three I'll tell you where it got things wrong and how I caught it.

Next: in part two, why this site doesn't load a single third-party resource, how the contact form works without JavaScript, and which regulations actually apply to a personal website — considerably fewer than the templates would have you believe.