Helping your client maintain markup quality
One thing that is particularly frustrating with caring about Web standards and accessibility is what often happens after your work is done and a site is handed over to the client.
I’m sure most of you have been there. Despite your hard work to educate the client’s editor(s), regardless of the style guide you wrote, and no matter how much time you spent patching the CMS they use, there will be problems.
If you spend enough time working on it (or are one of the few lucky ones to use a CMS + WYSIWYG editor combo that enforces it) you may be able to ensure that the HTML on the site stays valid. In most cases you will not be able to do that, however. And even if you can ensure validity, that alone will in no way guarantee that the site stays accessible.
So what can you do, if rewriting the entire CMS to guide the user through the publishing process is not an option? Well, one idea is to make any errors or suspicious markup obvious to the person working on the document.
One way of doing that is to use CSS the way Marco Battilana describes in the Accessites.org article Big Red Angry Text. The idea is that by inserting the following snippet of CSS in the global stylesheet file, certain markup that shouldn’t be used will be made very obvious to the editor:
font, center, div[align], p[align], table[align], font[color] {color:#cd0000;font-weight:bold;background:#eecc11 url(images/warning.gif) repeat 0 0;margin:10px;padding:10px;border:2px dashed #cd0000;font-size:2em;}
You can use this to clearly mark things like deprecated elements, presentational attributes, and cruft you know that the WYSIWYG editor your particular CMS uses likes to leave behind unless the person using it is very careful.
I’ve been using a similar approach for some time, but only made it visible to the person using the CMS. Instead of inserting the error catching rule or rules in the global stylesheet, I add a few rules to the stylesheet used by the WYSIWYG editor. I also make the errors a little more subtle than Marco’s CSS does.
I’ve found that this approach helps our clients avoid at least some of the many potential problems caused by WYSIWYG editors and/or lack of knowledge.
This idea could also be combined with some of the rules described by Eric Meyer in Diagnostic Styling to catch things like images with no alt attribute and empty list items.
This isn’t ideal of course, but until there is a CMS that does not let editors produce invalid or inaccessible markup it’s a hack that does help.
- Previous post: The resurrection of downloadable Web fonts
- Next post: Videos of people using assistive technology
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
Amen. I think most of us recognize this problem.
Could be dangerous if the Editor uses IE6 to edit the pages and soesn't see the result uantil tha visitors, with better browsers, complaints. But i have made similar things, like a span-trap.
/ m a r t i n
Actually I think this is a brilliant idea. First because every time you pass over a valid product some users are going to instantly make it invalid by putting junk into the editor...
second because they don't do it intentionally to destroy the validity. If this flags to them that something is amiss they have the opportunity to change their behaviour and even to learn what is and is not valid to enter into the editor.
Excellent tip Roger, I'll use that too. But am wondering why it never occurred to me of course :)
thanks for sharing
As always a nice reflection from the ordinary life of a webpro, thanks for bringing things like this up. Even if it's not fun, it's nice to know I'm not alone having this issue and by posting here you now know you're not alone ;-)
The solutions presented seems to be a nice, easy and affordable way to hit the customer with that baseball bat to get their full attention, as "socket-conny" would have said.
Btw FYI: I read this article and making this comment with a "Mozilla/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile Mobile/3A110a Safari/419.3" UA while having a nice espresso at the local espresso bar :-) and your website works very well in this UA (doh! as that would be a surprise).
Nice article, Roger. I'm in the very same situation right now with a client, that does all kinds of markup mistakes (
centertags, not closinglielements, etc.), even after I've tried to explain him how to write clean code.That CSS solution you reported is nice; I've chosen not to use a WYSIWYG editor, since it would likely worsen things even more. Instead, I've chosen to let my client write text with a Textile/Markdown syntax, which is quicker for them, and would ensure me that some common errors (eg. paragraphs made with
br's) won't be made.Of course, it's a start, and there will always be a lot of work to do.
Interesting idea. I like the strong visuals; they really help communicate the message.
At my old job, we tackled this problem by having the site editor create and edit pages using an XML editor (XMetal, specifically).
We created a custom HTML DTD, based on XHTML Basic, with more elements removed and some put back in. This prevented them from using elements like <font> and <center>. Not a cure-all, but it kept out presentational elements, and it didn’t allow them to create invalid pages either.
That's great, I'd never have thought to do that...
How about:
;)
That's a really cool idea, may have to implement that on future projects. I normally don't have too much problems with authors using deprecated attributes and elements but with the code just being full of errors (missing closing-tags etc) and then, obviously, this won't help.
Perhaps if you added p p, p ul, a div, a p, etc to the list of selectors that would catch some errors?
I use a combination of markdown and htmlentities on my site which always ensures 100% semantic and valid (X)HTML output. I think markdown (and the likes) is the only way to go if you want to be sure to have good, valid markup.
Great idea from Marco. I'm going to be putting something like this in my global stylesheets from now on (where other users may be editing my content).
This is a brilliant idea. As some have said the only problem then lies in IE but that means rather than forcing the knowledge of valid CSS and XHTML onto your client you simply need to encourage FF or even IE7 if need be.
A very good idea...
Carmelo Lisciotto
For the case of IE6, how about having a JS file that attaches a class to any tags that are deprecated, or have attributes that are deprecated?
This sounds like a very good idea. I´m gonna try this out immediately.
I love the idea, but alas it can't work here :(
The reason being that our WYSIWYG has a tendency to apply CSS classes using a <font class="whatever"> element, and the users don't have the HTML knowledge to fix it. As you can imagine, this is more than a little frustrating. I'd switch to a better editor, but this one is compiled into the application.
Good idea, but ... then the client picks up his phone and gives you a rant over the phone stating that his site is broken. sigh
This is a great concept and should really help get the point across to clients when they are using invalid code, especially when copying from Word and other applications.
Awesome, like it. "display: none" would help the surprise effect though.
What a fantastically impractical idea. Me: "when something in the editor is this color and bold it means the html code behind it is broken" client: "so what?" me: "well if the HTML code deosn't validate I don't get my warm fuzzies!" client: "that's nice, but the the site looks just fine even when the editor tells me it's broken" me: "yeah well it's only broken to some browsers some of the time, and some browsers ignore the 'broken' stuff anyways." client: "so what am I supposed to do here?" me: "go into the source code view... find the bit of text that start <font..."
The client quickly glazes over and starts thinking about cheese or something.
My point is, it's hard enough to educate the client about even using all of the buttons and menus in a CMS, let alone trying to explain some abstract concept of validity and why it matters and how to fix HTML code that they could just blame us for not making our system foolproof enough to remove.
Roger, Are you saying that the way you do it, is a way that only people creating and editing stuff in the CMS can see it and not on the live site users?
We have a huge ecommerce platform and the site managers were always using crap code, font tags and what not. the list of pages that have this kind of crap on it are in the hundreds.
The last year our internal development team has came about and we are stuck with all this crap and I have no clue on how to update all of these pages and of course setting styles for stuff like this would show live on our site not to mention the month it would take for us to go through every page in the database and edit it out.
It sucks because all of our development has web standards and accessibility in mind but it seems like a knife in the back when viewing the source. I just wish there was an easier solution.
Roger, it's great to try to provide help after the client has entered invalid markup, but it doesn't address the issue's root cause.
Your article today spotlights the inferior capabilities of the current crop of web site editing tools. What we ultimately need are tools that only generate valid semantic markup. Once that is accomplished, the need to detect invalid markup is eliminated.
Great idea, I will look into integrating this in future deliveries.
It is always sad to see users tear valid markup apart and it can be difficult to educate them in a polite manner. :)
I don't know what my current client does. He always inserts weird symbols into his PHP files and this is despite telling him so many times not to open his PHP files using a GUI. Although I have created a separate file for him where he can make the textual changes but whenever he makes those changes weird ascii characters begin to appear on all his pages. He tells me that he uses an apple computer to manage his affairs. Even when he repeatedly tells me that he is using a text editor he somehow manages to spoil his files. :-)
Great idea! Thanks for the heads up!
Good article, but perhaps there is a solution http://www.wymeditor.org/en/
This is a really good idea. I've been threatening to remove all of that stuff automatically but I know it'll break existing sites. This is a nice compromise. I've just added it to our CMS. We'll see what happens on Monday.
BTW, we allow WYSIWYG as well as both textile and markdown in our CMS... neither textile nor markdown is sufficient to prevent this kind of markup since both allow raw html to be entered by the user.
Teh only thing you can do is use page templates that have valid mark up, and disable any styles that work against the lay-out.
Mostly you have headers, body text, images that need to be aligned, and lists (ul and ol). What else??
That's my thinking too. Just disable all the features of your chosen WYSIWYG editor that users aren't s'posed to use and then you don't need to use CSS to highlight them.
This is a great post, I had not heard of BRAT and can see what a useful tool this will be. I plan to implement this on my next code-based site, but for CMS WYSIWYG's I do what others have suggested - just disable the features that the users aren't supposed to use.
Even so, I just checked out a site I launched about a month ago built in Website Baker CMS. There are already validation errors there even after disabling things in the WYSIWYG, and they're not on the deprecated list, mostly places where the user entered and deleted something but the source code wasn't cleaned up. It seems like a losing battle.
On the flip-side, if there's a button there to do a job, how wrong can it be?; particularly a simple function such as alignment.
"I want that image right aligned so why is it highlighting a warning?"
"Seems OK when I publish, so, whatever"
"If it warns me about alignment when I push the button, how else am I meant to get that image over there?"
@John Faulds: It would certainly work but in my experience you'll get every editor requesting those capabilities. They may never be used but they're there if needed. It is perhaps the lesser of the two evils though.
Thank you so much for the link R.Batalla
I spent an hour on friday trying to find something that would do exactly what wymeditor promises to do but found nothing.
Im going to try this one out as soon as possible. It looks very promising!
I think it will get clients to understand that markup != presentation as well, which can only be a good thing.
Our solution to the problem worked rather well for most clients, although it does have it's own hiccups from time to time.... What we did was this:
We started with just your normal HTML editor for content (I believe we've used both Xihna and FCKEditor). We disabled the font-size selections and taught them how to make use of the header drop downs instead. We also made sure that the font-color things worked on spans, bold worked on strong, and italic worked on em's.
This for the most part did the trick, but occasionally, they would still cause the code to invalidate, which then caused the site to break... So our solution was a nifty little PHP extension called Tidy. Tidy will clean up source code/xml (and make it look pretty). When combined with a WYSIWYG editor, we have had very little problems. We actually run this cleanup twice (once when they save, and once when the page loads into a cache). You could probably get away with once when they save, but we had some other features that needed it added as well.
Interesting approach, unfortunately it presumes that clients are willing to spend extra time on fixing things "that already work"...:(
I prefer more transparent approach with search & replace script that cleans up the results automatically. FCKEditor already has a javascript script for cleaning up the text pasted from Word, and it's really easy to make that function do anything you like (turning fonts to styles, <b> to <strong> or whatever). Or you can use similar php/perl/whatever function on a server side to clean up the data before saving it. Either way it fixes everything without asking any questions, and since clients ain't aware of it, they don't complain...:)
@Roger
It's an honour to have been mentioned. Many thanks! I'm a big fan of your work :)
The BRAT technique is something that I've had implemented at my work for some time now. It's definitely resulted in a greater awareness of a standards-based design and the impacts of certain WYSIWYG tools.
I have been questioned many times about the "in-your-face" technique. Honestly, I feel it's the best way to make people learn. If it's too subtle, then people don't notice it. If they don't notice it, they don't learn.
Sometimes, people can get set in their day to day routine at work. Occasionally, they need that bit of a wake up call. All for the greater good, of course :)
At work all our web content is stored as XML, so it's dead easy to lock down look-and-feel with complete precision. Content editors use an XML editor to author content.
A good idea - but 'p p' and 'p ul' shouldn't be a problem if you're sticking with HTML, because the closing tag for <p> is optional and is implicit when you start another block-level element.
Another approach is to 'disable' some tags and attributes using CSS. Then the client will stop using them since nothing happens, f.ex:
or even:
...but again we have a IE6 problem since it doesn't understand the inherit rule properly. A workaround would be to have a javascript that adds a 'disabled' class to the very same tags and attributes.
Marco, why should they learn? Do I have to be a technical engineer to drive a car? Do I have to be a baker to eat bread? Simplistic I know but I still feel this is the wrong approach. As you say you've been questioned about it. You're supplying a tool that doesn't do a job because of Web standards. If I were the client, I'd be looking elsewhere.
Every content editor I know does not know HTML, let alone valid, semantic HTML, and they won't want to learn it either. However, they do want to align their own images. I think Roger summed it up at the very end. It isn't ideal.
I'm not knocking the solution as it's a graceful way of highlighting errors should they care but the problem isn't the lack of knowledge of the client, the problem is the WYSIWYG editor, which in the clients eyes becomes your problem because you supplied it to them.
If I was your client David, I want those features put back.
There's a wider argument here too. How far would you go to either defy or educate your client to do things your way? Most designers / developers I know will 'advise' but ultimately deliver what the client wants, get paid, then deal with any problems later on.
You can all write HTML4, XHTML if you have to, but if you introduce a third party tool that outputs to the browser then you live by the consequences of that.
Sorry, comments are closed for this post.