9 HTML Attributes That Can Make Your Website Better
Small HTML choices can improve performance, usability, accessibility, and the overall user experience.
A website can look beautiful and still feel annoying.
The images take a little too long to appear. A form opens the wrong keyboard on your phone. You tap outside a small menu, and nothing happens. You have to type information your browser already knows.
None of these problems look dramatic in a screenshot.
But use the website for thirty seconds, and you feel them.
This is where design and web development meet. A good interface is not finished when the layout looks right. The way the browser behaves matters just as much.
And surprisingly, some of these improvements don’t require complicated solutions. A few thoughtful choices in HTML can change the experience.
Start With the Moment Someone Opens the Page
Think about a photography portfolio.
The homepage has a large opening image, followed by twelve project photos farther down the page.
Those images do not all have the same job.
The first one is part of the visitor’s immediate experience. The images near the bottom may not be seen for another minute, or at all.
So I wouldn’t ask the browser to treat them equally.
For images farther down the page, native lazy loading can help:
<img src="interior-project.webp" alt="Interior design project" loading="lazy">
The browser can wait before loading an offscreen image until it gets closer to where the user is browsing.
For an important image near the top of the page, the thinking is different. In the right situation, fetchpriority="high" can give the browser a hint that fetching that image deserves more attention.
The important part isn’t memorizing two attributes.
It’s understanding that good performance starts with deciding what the visitor needs first.
A Form Should Feel Easy on a Phone
Desktop forms can hide bad UX.
On a laptop, switching between letters, numbers, and symbols takes almost no effort. On a phone, every unnecessary tap becomes more noticeable.
Imagine you’re entering a six-digit booking code.
You tap the field and get a regular text keyboard.
Now compare that with this:
<input type="text" inputmode="numeric" autocomplete="one-time-code">
inputmode can tell the browser what kind of virtual keyboard would be useful for the expected input.
It’s a tiny technical decision, but it makes the interface feel more considered.
The same principle applies to the Enter key.
For a search box:
<input type="search" enterkeyhint="search">
For a message field:
<textarea enterkeyhint="send"></textarea>
enterkeyhint lets the browser present an action such as Search, Send, Next, or Done on a virtual keyboard.
Nobody is going to open your website and say, “Great use of enterkeyhint.”
They will simply find the form easier to use.
That’s the point.
Don’t Make People Type What Their Browser Already Knows
Now imagine someone wants to request a quote.
Name.
Email.
Phone number.
Street address.
City.
Postal code.
That’s a lot of typing on a small screen.
Good form design should reduce that effort wherever possible.
<input type="text" name="full-name" autocomplete="name"><input type="email" name="email" autocomplete="email">
Using meaningful autocomplete values helps browsers understand what information the fields are asking for.
Visually, nothing changes.
From a UX perspective, a repetitive form can become much faster to complete.
This is something I think designers should care about as much as developers do. We spend time reducing visual clutter, but interaction clutter matters too.
Sometimes the Page Needs to Stop Listening
Interfaces often have temporary states.
Maybe a user opens an important overlay. Maybe part of the interface shouldn’t be reachable while another action is taking place.
A common approach is to start managing individual buttons, links, focus states, and click behavior separately.
But HTML gives us inert.
<section inert> ...</section>
When a section is inert, its descendants cannot normally receive focus or clicks, and they are removed from the accessibility tree.
There is an important design lesson here too.
If something cannot be interacted with, it should also look unavailable.
Technical behavior and visual communication need to agree. Otherwise the browser may understand the state perfectly while the person using the website has no idea what happened.
Small Interactions Don’t Always Need Big Solutions
Modern interfaces are full of little floating elements.
A product may have additional details. A dashboard may need a quick action panel. A portfolio project may have a small information box.
Sometimes developers immediately start thinking about custom JavaScript.
But native HTML has become more capable.
The Popover API, for example, allows an element to behave like a popover:
<button popovertarget="details"> View details</button><div id="details" popover> Project completed in 8 weeks.</div>
With an automatic popover, the browser can handle behaviors such as dismissing it when the user clicks outside or presses Escape. Popovers are also displayed in the browser’s top layer.
That doesn’t mean JavaScript is unnecessary.
Far from it.
Complex interfaces still need custom logic. But I prefer starting with a simpler question:
What can the browser already do well?
Then I add complexity where the experience actually requires it.
Good Frontend Work Is Often Invisible
Some website improvements are easy to show in a portfolio.
A new layout is visible. An animation is visible. A redesigned navigation is visible.
The details I’ve described here are different.
You don’t necessarily see them.
You feel them when a page loads without making you wait for content you haven’t reached. You feel them when a form gives you the keyboard you expected. You feel them when an interface behaves naturally without making you think about how it works.
That’s one reason I don’t see design and frontend development as completely separate parts of a website.
The design decides how the experience should feel.
The code has to protect that feeling when someone actually starts using it.
And sometimes, the difference between an interface that simply looks polished and one that feels polished comes down to a few lines of thoughtful HTML.
Aram Andreasyan — Web Designer and Web Developer Expert
If you want to read more insights, follow me on Medium.
