I've been stating in most of my recent contracts that meeting HTML coding Best Practices (what's outputted to the browser) is an important part of UX.

This would include things like Semantics (using headings, paragraph tags, captions, etc.), meeting all accessibility standards (alt tags, labels, table headings and for advanced ones scope..., etc.) and valid HTML/XHTML.

I've been getting push back that these things aren't UX, that they're code practices and unrelated. That when I do QA reviews I should be concentrating on usability and consistency of design and not worry about coding practices.

So, am I out of line here and misinterpreting scope?

  • 1
    Semantics and accessibility standards aren't "just code"; while there's a thousand ways to write a single function and have the UX be the same, if you don't semantically and accessibly design your HTML the end user experience is different, period!
    – Ben Brocka
    Sep 6, 2011 at 13:02

10 Answers 10


"and unrelated"

EVERYTHING that goes into building a successful web site that meets the needs of the users is related.

There's a tradition, it seems, that anything seen as 'code' is immediately given to IT. That separation is rather silly and, IMHO, a remnant of antiquated waterfall development practices.

The way forward that I feel is the most agile and appropriate is that UX (as a team) would be responsible for everything including the presentation layer code (CSS, JS and HTML). They'd then work extremely closely with the back end IT teams going forward.

Politically, that's going to be a fight in a lot of organizations.

(related to this is Marketing, when they think they own the content outside of any UX involvement)

  • As much as I'd like the UX team to be in control of everything (possibly with a view to eventual world domination), I don't think everything should be related to a UX role. Also, I'd imagine a lot of UX practitioners aren't necessarily technically savvy enough to make decisions about code or markup. Feb 23, 2012 at 13:07
  • UX is related to all of it--but it all doesn't' have to be the domain of the UX team. And while a lot of UX individuals may not be code savvy, the UX team should be. If they aren't, then they have no power within the organization to actually ensure what they design gets built.
    – DA01
    Feb 23, 2012 at 16:45

I'm on your side here.

The items you mentioned are coding practices that directly affect the user experience. If you don't stick up for standards no one will.

Other coding practices relate to maintainability and stability etc and that's something the development team can look after on their own.

At our place, the UX folk sit with the front end developers, which is highly recommendable in my opinion. Not only can we easily review code with them, but they can also show us the latest technological developments to keep us up to speed.


I believe the same thing you do; that proper semantic markup improves the UX of the website.

Nevertheless, to directly answer your question: I do believe you are misunderstanding (or probably more properly miscommunicating) the scope defined between you and the client.

So if I might take the liberty of doing my best to answer the question I believe you’re actually asking ("how do I communicate the UX benefits of semantic markup?"):

Since markup seems to many customers as "code" (a necessary evil, not the thing they're paying for), you need to focus on the way those semantic markup principles and accessibility improvements can affect the user's actual experience. You might, for example, like to get a copy of JAWS (on Windows) or set up VoiceOver (on Mac) and demonstrate how applying a strong page hierarchy using headings allows for much simpler page navigation for the blind, and how alt tags make content images meaningful for them.

When I'm communicating the benefits of microformats to customers, I like to use an extension to demonstrate how search engines, future browsers and other content consumers can benefit from proper markup of things like hCards and hCalendar.

You can also demonstrate the document outline using extensions to show how the user's actual interaction with the page can be improved using proper outlining semantics.

The last suggestion I have is related to link types such as link rel="next": there's a Firefox extension called Link Widgets that provides in-chrome navigation of pages in a site. You can also mention with these that browsers can improve the UX through prefetching when you include these links.


Why stop with HTML coding best practices?

Back-end scripts need to be readable and immediately accessible to their users (i.e. everyone in the development department - especially the developers who may not have written them but will end up supporting them).

Nothing screams "unmaintainable" more than uncommented scripts full of classes, functions, and variables with names like "z" and "foo".

  • Interesting... I work in a software development company. As usability practices become established in the Front-End teams, the topic of "Code Usability" has become an important topic. Another interesting one is "Document Usability": how many spec documents did you read which were written or at least structured with the prospective user in mind instead of just randomly listing requirements?
    – Lisa Daske
    Jul 19, 2010 at 13:36

Anyone who pushes back and says these things arent UX doesnt understand UX.

Managing a good UX goes beyond HTML and CSS coding standards, it extends to scripts, to connections with back end system, to quality of images, downloadable files.

As an example. I worked on a project where the front UI was technically accessible and the visual design had tested well in usability. When the site was connected to its back end database the performance was so bad, all the front end benefits didn't matter anymore, the overall UX was a disaster. If I was to ask the database administrator they would say their database is fine, the network engineer would claim their was nothing wrong with the infrastructure, the hardware guys wouldn't accept that the servers might have something to do with.

No one part was actually to blame, but instead of looking at the individual components, stepping back to the overall experience that was expected gave everyone an ability to work on improving just their little bit of the picture.

If you're getting push back, push back harder.


Usability does not stop with the user experience. Extending usability to our code can provide a number of benefits. higher code readability, quicker changes, and simplifying the process of ensuring user usability.

Useful read: http://www.terradoncommunications.com/shared/content/whitepapers/TCG%20-%20Usability%20Best%20Practices.pdf

Exploring Usability Enhancements in W3C Process http://www.w3.org/2002/09/usabilityws.html

Usability, Accessibility and Markup http://www.w3.org/2005/Talks/11-steven-usability-accessibility/


Here's an article that might give you some inspiration to keep up the fight



I'm front-end developer and it really gets on my nerves when people without technical knowledge say that something has to be like they want, because UX requires it. What usually happens -- every page is different, therefor the CSS file if bloated with modifications of excisting elements, JavaScript file is bigger than CSS and HTML combined and HTML is illogically structured. The reason for this is simple, UX designers do not understand what is HTML, CSS or what are JavaScript possibilities, the outcome is buggy, slow and bloated site. If UX people would understand why keeping code minimal, re-using CSS and JavaScript is good, they would change their "beliefs" -- it is possible to to make correct, easy, comfy websites using best practises of back-end, front-end coding and UX.

UX designers, you have to know this kinda things, otherways you end up just like internet marketers -- the enemies of all-end coders :)

  • I've done plenty of HTML and CSS and the problem I've always found is code will be written with no regard to accessibility or convention and it's a terribly bloated awkward mess. I've never seen a situation in which semantic and meaningful coding wouldn't have improved a document, especially provided more than a single coder has to ever read the doc
    – Ben Brocka
    Sep 6, 2011 at 13:32
  • This is a VERY valid point, but isn't really an issue of UX being involved, but rather non-technical UX people being involved. (which is something I'm dealing with right now--and I see the exact same issues you see...bloated CSS, one-off page designs, stc.) If UX can't code, then they really shouldn't have any say in what the coders do--as that's obviously out of their realm of expertise. Yet another argument for having a UX team that can actually understand presentation layer code.
    – DA01
    Sep 6, 2011 at 14:32
  • In otherwords, your developers have to have an appreciation for, and the skills to create solid presentation layer code. Your UX team also has to have an appreciation for, and the skills to create solid presentation layer code. ;)
    – DA01
    Sep 6, 2011 at 14:33

Are you misinterpreting the scope? It depends on what your job description really is.

Are you out of line when it comes to making the UX better? No, as long as you don't fail to pay attention to other tasks as well, like usability and consistency of design that you mentioned. With those, you've covered accessibility and usability so don't forget about stuff like IA and IxD, if that's a part of your job, of course.


There are obvious advantages to ensuring that code and mark-up quality is high, and all organisations should do their very best to ensure that their internal cultures promote good practice. However, having said this I'm afraid I disagree with your central premise.

There's a reason we have roles in any organisation - it's unproductive to say that markup quality is the responsibility of the UX team.

From the user's point of view - semantic mark-up drive the technologies that the user has exposure to. That is the extent of the user's exposure to mark-up.

There are layers between the user and mark-up, which are part of the remit of the UX team.

Think in terms of the affordance sematic markup provides designers. If the things you require from a website require semantic mark-up or use of microformats, then state those requirements (e.g. consistency of design can be met through use of semantic markup), but in my opinion you should not put the horse before the cart.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.