10 Things Even AI Can't Do in HTML

Give it a prompt, and it can create a navigation bar, build a landing page, generate forms, organize content, and even produce a complete website structure.

The result might look perfectly fine at first glance.

But there's a difference between generating HTML and knowing how to use HTML properly.

A page can render without errors and still have a confusing structure. A button can look correct but behave like the wrong element. A form can collect information without considering whether users actually need to provide it.

This is where things get interesting.

I've been thinking about what makes a developer valuable in a world where generating code is becoming easier. The answer isn't simply writing more code or memorizing more HTML elements. It's understanding why something should be built, making the right decisions, and knowing when an apparently correct solution isn't good enough.

Here are ten things AI still cannot reliably handle on its own when working with HTML.

1. Understand the Problem Before Writing the Markup

The first mistake in many development tasks happens before anyone writes a single line of HTML.

Someone describes a feature, and the immediate reaction is to start implementing it.

AI follows this approach particularly well. Give it a request for a dashboard, navigation menu, or registration page, and it will probably generate something that matches the description.

But does the requested interface actually solve the problem?

Imagine a company asking for a registration form with fifteen fields.

AI can generate all fifteen fields. It can add labels, placeholders, and validation attributes.

A developer should ask a different question:

Do we really need all fifteen fields?

Perhaps the application only needs an email address and a password. Maybe the remaining information can be collected later, when it becomes relevant.

This is what problem definition means. Before deciding how to implement something, you need to understand why it is necessary.

The HTML might look like this:

<form action="/subscribe" method="post">
  <label for="email">Email address</label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    required
  >

  <button type="submit">
    Subscribe
  </button>
</form>

It's simple because the task itself is simple. There's no reason to add unnecessary fields or interactions.

AI can help implement a requirement, but deciding whether that requirement is worth implementing requires product understanding, communication, and judgment.

The point: A good developer doesn't just ask how to build something. They ask whether it should be built in the first place.

2. Give HTML Elements Their Actual Meaning

HTML is not just a collection of tags used to arrange content on a page.

It is a language for describing the structure and meaning of a document.

This distinction is easy to forget when working with modern frontend frameworks and CSS-heavy interfaces.

Consider this:

<div class="button">
  Save changes
</div>

It looks like a button. With CSS, you can make it look exactly like one.

But it isn't a native button. It doesn't automatically provide the same keyboard interaction, focus behavior, or semantics.

The more appropriate version is:

<button type="button">
  Save changes
</button>

The same principle applies to links, lists, headings, tables, and page sections.

For example:

<a href="/about">About us</a>

A link navigates somewhere.

<button type="button">Open settings</button>

A button performs an action.

These elements might look similar after styling, but their purposes are different.

AI can generate semantic HTML when asked. The problem is that it may choose elements based on how the output should look rather than what the elements actually represent.

Understanding the difference requires knowledge of the browser platform and the purpose of the interface.

The point: HTML should describe what something is, not just how it should appear.

Reference: MDN — HTML Elements Reference

3. Build a Structure That People Can Actually Navigate

A web page isn't only consumed visually.

Some users navigate through headings, landmarks, and document regions using a screen reader. Others use a keyboard or rely on browser features to move through the content.

This is why document structure matters.

Consider a basic page:

<body>
  <header>
    <nav aria-label="Main navigation">
      <a href="/">Home</a>
      <a href="/articles">Articles</a>
      <a href="/contact">Contact</a>
    </nav>
  </header>

  <main>
    <article>
      <h1>Understanding HTML Semantics</h1>

      <p>
        HTML provides structure and meaning to web content.
      </p>

      <section aria-labelledby="importance">
        <h2 id="importance">Why semantics matter</h2>

        <p>
          Semantic elements help browsers and assistive
          technologies understand a document.
        </p>
      </section>
    </article>
  </main>

  <footer>
    <p>© 2026 Example Website</p>
  </footer>
</body>

Elements such as <header>, <nav>, <main>, <article>, and <footer> communicate the purpose of different regions.

Headings also establish relationships between sections.

One important detail: a <section> does not automatically become a named accessibility landmark. When it represents a distinct region users need to navigate to, give it an accessible name, usually through a heading.

This isn't about adding as many semantic elements as possible. It's about choosing the right structure for the content.

A page with ten unnecessary sections isn't automatically better than a page with three meaningful ones.

AI can generate a structure, but it doesn't automatically know which parts of a particular document deserve to be grouped together.

The point: A good HTML structure makes sense to people, browsers, and assistive technologies.

References: MDN — Structuring Documents · W3C — Page Structure

4. Make Content Understandable Beyond Its Visual Appearance

A page can look beautiful while communicating very little to machines or users who cannot see its visual presentation.

Think about a product listing containing ten images, prices, and buttons.

If the HTML contains only generic containers and images without meaningful text, it becomes harder for different technologies to understand what the content represents.

The same applies to page metadata.

A descriptive document title is more useful than a generic one:

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>HTML Semantics: A Practical Guide</title>

  <meta
    name="description"
    content="Learn how semantic HTML improves document structure,
    accessibility, and maintainability."
  >
</head>

The title and metadata help describe the document.

Google Search can use the <title>, visible page headings, and other signals when generating search result titles. However, providing good metadata does not guarantee a particular ranking or an exact search result title.

The content itself matters just as much.

For example, a product page should communicate the product name, relevant details, price, and available actions through actual content rather than relying entirely on images or decorative elements.

A developer has to understand what information matters and how it should be represented.

AI can generate metadata and markup, but it cannot independently guarantee that the information accurately represents the page.

The point: HTML should communicate the meaning of the content, not merely display it.

References: Google Search Central — Title Links · Google Search Central — SEO Guide

5. Provide Meaningful Experiences for Users Who Cannot See the Page

Accessibility is one of those areas where an interface can look completely correct while still having serious problems.

A developer can create a beautiful image gallery, but what happens when someone using a screen reader visits it?

Consider:

<img src="product.jpg" alt="Image">

The markup includes alternative text, but it doesn't communicate anything useful about the image.

A better example would be:

<img
  src="running-shoes.jpg"
  alt="Black running shoes with white soles, shown from the side"
>

The description communicates relevant visual information.

There is another important distinction: not every image needs descriptive alternative text.

Decorative images that don't provide meaningful information should generally use an empty alt attribute:

<img src="decorative-pattern.png" alt="">

This prevents screen readers from announcing irrelevant content.

The same thinking applies to other elements:

• Use meaningful text for links.
• Provide labels for controls.
• Preserve logical heading order.
• Make interactive elements keyboard-accessible.
• Avoid communicating important information through color alone.

AI can generate many of these attributes, but it doesn't necessarily know what an image contributes to a particular page or what information a user needs.

Accessibility is not a box you check by adding alt to every image.

The point: You need to understand the content before deciding how to make it accessible.

Reference: W3C WAI — Images Tutorial

6. Design Forms Around People, Not Just Input Fields

Forms are among the most common places where poor HTML decisions affect real users.

AI can generate a form with every input type imaginable. But a useful form is not defined by how many fields it contains.

It is defined by how easily someone can complete the task.

For example, consider a simple registration form:

<form action="/register" method="post">
  <fieldset>
    <legend>Create your account</legend>

    <label for="name">Full name</label>
    <input
      type="text"
      id="name"
      name="name"
      autocomplete="name"
      required
    >

    <label for="email">Email address</label>
    <input
      type="email"
      id="email"
      name="email"
      autocomplete="email"
      required
    >

    <label for="password">Password</label>
    <input
      type="password"
      id="password"
      name="password"
      autocomplete="new-password"
      required
    >

    <button type="submit">Create account</button>
  </fieldset>
</form>

Notice a few details:

• Labels are explicitly connected to their inputs.
• The appropriate autocomplete values help browser autofill.
• Required fields are marked clearly.
• Related controls are grouped using <fieldset> and <legend>.
• Native form behavior is preserved.

HTML also provides built-in validation:

<input
  type="email"
  name="email"
  required
>

The browser can check whether the field is empty or whether the entered value has an appropriate email format.

However, client-side validation is not a security mechanism. The server must validate submitted data independently.

The W3C Forms Tutorial also emphasizes clear instructions, understandable error messages, and giving users a chance to review or correct their input.

These details are easy to overlook when the only goal is generating a form that looks correct.

The point: A good form asks for the right information, explains what is expected, and helps users recover from mistakes.

References: W3C — Forms Tutorial · W3C — Labeling Controls · W3C — Input Validation

7. Understand That Localization Is More Than Changing Words

A website can be translated into twenty languages and still feel foreign to users in every one of them.

That's because localization involves more than replacing English sentences with translated alternatives.

It also includes writing direction, date formats, currencies, terminology, cultural references, and the way information is presented.

For example, a page intended for Arabic readers should communicate its language and direction correctly:

<html lang="ar" dir="rtl">
  <head>
    <meta charset="UTF-8">
    <title>مرحباً بك</title>
  </head>

  <body>
    <main>
      <h1>مرحباً بك</h1>
      <p>نحن سعداء بزيارتك.</p>
    </main>
  </body>
</html>

The lang attribute identifies the language of the document, while dir establishes its text direction.

For content that can contain text in different writing directions, the <bdi> element can help isolate text whose direction should be determined independently:

<p>
  Username:
  <bdi>developer_محمد</bdi>
</p>

This matters when displaying user-generated names or text that might mix left-to-right and right-to-left characters.

But technical direction is only one part of localization.

An expression that sounds friendly in one language may sound too informal or even inappropriate in another. A symbol or color can also carry different meanings depending on the audience.

AI can translate words and generate locale-aware markup. Understanding whether the complete experience feels natural in a particular culture requires local knowledge and human review.

The point: A localized website should feel like it was designed for its audience, not simply translated for it.

8. Preserve the Browser's Native Capabilities

Modern frontend development often involves JavaScript frameworks, custom components, and complex application architectures.

Sometimes, developers forget that the browser already provides a lot of useful functionality.

A simple link can navigate between pages:

<a href="/articles">
  Read articles
</a>

A native form can submit information:

<form action="/search" method="get">
  <label for="search">Search articles</label>

  <input
    type="search"
    id="search"
    name="q"
  >

  <button type="submit">Search</button>
</form>

Neither example requires JavaScript to provide its basic browser behavior.

You can add JavaScript later to improve the experience, but the essential functionality already exists.

This is closely related to progressive enhancement.

The idea is simple: start with meaningful HTML that provides the core experience, then add CSS and JavaScript to improve it.

For example, a navigation link should still be a useful link before any client-side routing enhancement is added.

Not every interface needs to be a fully custom JavaScript component.

Sometimes the native element is the better solution.

The PDF's discussion of smart reuse is relevant here. Originality doesn't require rebuilding everything from scratch. It often comes from combining existing tools and capabilities in a more appropriate way.

The point: Knowing when not to write additional code is also a development skill.

Reference: web.dev — Learn Forms

9. Create Something Original Without Ignoring Existing Standards

This is probably the most interesting part of the discussion.

What does originality actually mean in software development?

Does writing an entirely new HTML structure make a developer original? Does avoiding existing patterns automatically make a project better?

Not necessarily.

The PDF introduces an important distinction: originality is not simply creating something that has never existed before. It can come from the creator's distinctive contribution and the way existing knowledge is combined.

I think this idea applies directly to HTML development.

Consider the following three dimensions:

Product-focused originality

The structure and content should serve the specific product. A documentation website, an online store, and a portfolio do not need the same document structure.

Person-focused originality

The content, writing style, presentation, and decisions should reflect a meaningful identity rather than simply copying a generic template.

Social and strategic originality

The implementation should make sense for the intended audience, the team, and the goals of the project.

For example, using <details> and <summary> to create an FAQ section is not a completely new invention.

<section aria-labelledby="faq-heading">
  <h2 id="faq-heading">Frequently Asked Questions</h2>

  <details>
    <summary>What is semantic HTML?</summary>
    <p>
      Semantic HTML uses elements that describe
      the meaning and purpose of content.
    </p>
  </details>

  <details>
    <summary>Why should I use it?</summary>
    <p>
      It helps browsers, developers, and assistive
      technologies understand the document.
    </p>
  </details>
</section>

The originality is not in inventing a new element. It's in recognizing that a native HTML feature is the right solution for a particular problem.

A developer who understands HTML can combine existing elements, patterns, and ideas in ways that produce a more useful experience.

AI can suggest combinations, but choosing the right combination depends on understanding the product and its users.

The point: Originality doesn't mean avoiding existing solutions. It means knowing how to use them in a way that creates something valuable.

10. Take Responsibility for the Final Result

This is where technical knowledge, experience, and professional judgment come together.

AI can produce a complete HTML document, but that doesn't mean the document is ready for production.

Someone still needs to check whether:

• The markup follows the HTML standard.
• Interactive elements behave correctly.
• The document has a logical structure.
• Forms are usable and provide appropriate feedback.
• Accessibility requirements have been considered.
• The content and metadata are accurate.
• The implementation fits the existing codebase.

And importantly, someone needs to take responsibility when something goes wrong.

A useful starting point is validating the generated markup with the Nu HTML Checker.

But passing validation doesn't guarantee a good user experience. You should also test the page using a keyboard, screen reader, different browsers, and realistic content.

There is another part of responsibility that often gets overlooked: working with other developers.

The PDF makes a valuable point about shared coding conventions. A developer's originality should not mean introducing a completely different style into every project.

Imagine joining an established codebase where every page follows consistent naming, indentation, component boundaries, and document conventions.

Adding your own personal style everywhere might feel creative, but it can make the code harder for the next developer to understand.

A professional developer knows when to follow an existing pattern and when there is a strong reason to improve it.

That decision often requires discussion, explanation, and collaboration.

The point: Generating code is an activity. Owning the quality and consequences of that code is a responsibility.

So, What Makes a Developer Valuable in the AI Era?

I don't think the answer is writing HTML faster than an AI model.

AI can generate basic markup, create forms, suggest semantic elements, and explain unfamiliar parts of the standard. It can save a considerable amount of time on repetitive work.

But speed alone doesn't define a good developer.

The more important skills are becoming increasingly clear:

• Defining the right problem before implementation.
• Understanding the technology beyond copying examples.
• Combining existing solutions in useful ways.
• Making thoughtful architectural and design decisions.
• Communicating with teammates and understanding users.
• Maintaining code that other people can work with.
• Continuously learning and developing deeper expertise.

One idea from the PDF is especially relevant here: technical execution is becoming easier to automate, while the value of judgment, problem-solving, and meaningful contribution becomes more important.

That doesn't mean technical knowledge is becoming irrelevant. Quite the opposite.

The deeper your understanding of HTML, browser behavior, accessibility, and web standards, the better you can evaluate generated code and recognize when something is wrong.

AI can help you move faster, but understanding what deserves to be built is still a major part of the job.