Jump to main navigation, main content

Archived entry | Matt Wilcox .net

Arguing against web standards

I’ve had a few experiences with people who argue against best practices and web standards, and I’ve found it’s generally because of a misunderstanding of how the web works, and what standards actually are and say. Here are a few arguments presented by such people, my response to them, and finally a very simple resolution that I hope actually helps clear up some of the misunderstandings such people seem to have.

On the lack of the anchor element’s target attribute in XHTML

Sometimes you don’t want to open a link to another site or page so that it uses the same space that yours does. This is how businesses work, and sites with “subwindows”, and we’re already to a point where target="_blank” is more likely to open a new tab. This was the intent of such an attribute.

Use of the target attribute has known issues for accessibility, and so has been removed from XHTML in favour of using JavaScript to perform the same operation. Preferably through a mechanism which allows the site visitor to decide if external links should open in a new window or not. Target in HTML may have a legitimate practical use, but the method is damaging. The same result can be achieved in a less damaging way (using JS), hence target’s removal from the XHTML specification. That means more work for developers, but there’s no loss of functionality there.

On accessibility demanding additional knowledge and effort on behalf of the web developer:

Screen readers throw a hissy fit over this [target="_blank"]? Tough luck - improve screen readers.

I agree with the sentiment in terms of how things ought to work, however it’s not solely for screen-reader users that target is a bad idea. target hijacks the behaviour of the link element in a way that a user may not like. It’s about choice as much as accessibility.

Getting back to screen readers, yes it really ought to be up to their software engineers to get their act together and handle things in a way that isn’t detrimental to the user. Unfortunately that seemingly hasn’t happened, and I believe the reason for that is a lack of monetary value with which to drive the effort. There are no Open Source screen readers to offer competition to the commercial ones. The commercial ones have a small audience so a businesses efforts at making a profit are better placed somewhere other than further refinement of ‘workable’ software. The problem is lethargy. It’s a similar situation that browsers were in before Firefox took off. There just isn’t a driving factor to create the change that screen reader users might wish to see.

With that being the case, do we (as web developers) leave these people to suffer, or do we start changing our practices so that we offer the same functionality to everyone but without penalising those users (for example, by using some JavaScript instead of HTML’s target)? Isn’t it worth ten minutes of our time to make a better solution? You could well answer no to that, and there’s nothing wrong with that answer as long as you know your audience, but it’s not the way I choose to work.

Screen readers are an adaptive technology by definition; don’t shift the job from the screen reader to the web developer.

See above. I agree with the sentiment, but it only works that way when there’s something driving software engineers and companies to change their software behaviour. There isn’t. So I think it’s OK to encourage the web developer to pick up the baton.

On image descriptions and accessibility guidelines

The question is whether you should be required by standards to write a 500 word or more “essay” on each image in an art gallery to accomodate [sic] for blind people. This is the direction you [as a web-standards developer and accessibility focused designer] are unwittingly proposing, and I call this impractical and slow, as doing such does indeed take time.

There is nothing unwitting about this at all. Again, it’s down to choice and a wise use of the technology. Is there a point trying to verbally explain the artistic values of a gallery image to a blind person? Probably not (most of the time). The specification doesn’t require you to either, developing to the XHTML specifications should not be confused with developing to accessibility guidelines. Is there a point in explaining the data contained in a complex graphical line-chart to blind users? Perhaps so, and definitely so if that information is not contained within the main article itself. Which is why accessibility guidelines suggest doing so for such situations.

On the misunderstanding of how the web works, and how W3C standards apply, now and in the future

If you’re drafting standards with the intent and hope of them being strictly enforced by browsers, you are thrusting these things on developers. If one day framesets, iframes, target attributes and window.open() are suddenly not supported by any browser because the W3C’s standards say so (and this day may be far off, but it will happen), this design change has essentially been thrusted on the developers.

Firstly, HTML4 is a W3C standard in exactly the same way as XHTML is - so it is not a case of ’standards bad’ vs ‘old-skool good’, any anti-standards argument that can be levelled at XHTML can be levelled at HTML. Secondly, HTML 4 support is going to be around for a very, very long time, and as part of the HTML 4 specification is an obligation for browsers to correct bad code, that also means that poorly authored HTML 4 will continue to work as it always has. The development of more modern versions of HTML in no way means anyone has to change the way they author their websites.

Getting to the crux of the matter

While it’s preferable that developers start using more modern and better considered versions of HTML, all developers have a choice of which doctype to use. Even if XHTML were to start getting enforced properly (As Gecko does when XHTML is sent with an XML MIME-type), any developer can just switch back to a HTML4 DOCTYPE and carry on as if it were 1999; completely ignoring everything that the W3C, WAI, WCAG, or any other organisation has had to say on the matter of responsible web development since then.

No one, anywhere, is being forced into using HTML properly. That’s the choice of the developer when they pick a DOCTYPE. Authoring in XHTML Strict means you’re signing up to the agenda of XHTML - which is all about cleaning up the bad practices of the past. If that’s not what an HTML author wants to get into, they ought to choose a HTML4 doctype. It works just as well as it always has. It’s a static environment. Of course, whether it’s wise to use a static and broken environment in an industry like ours is a matter for the reader to decide for themselves.


skip to comment form
  1. JackP posted 7 days, 21hrs, 13mins after the entry and said:

    Target not in XHTML? I think you'll find it is. It's in both HTML and XHTML providing you're using the TRANSITIONAL doctype - it's banned in either strict doctype as a deprecated attribute.

    Although I agree with you about opening new windows, I came across an example recently where I found that the use of target conveyed an accessibility benefit.

    I had a series of pages with a small IFRAME which contained an image/text linking off to some promotion somewhere. That way, I could change the promotion by changing one linked source page, instead of every page with the promotion on.

    However, any links open within the IFRAME unless you use the TARGET attribute to say target="_top", to open the link in the main page.

    If you use javascript to do that, then for anyone who doesn't have javascript, they are effectively unable to access the promotion because the promotion page opens only within the small space allocated to the IFRAME…

    …so don't assume that everyone who wants to use the target attribute wants to use it to open a new window!

  2. Matt Wilcox posted 8 days, 0hrs, 33mins after the entry and said:

    Sorry Jack, I should have been more clear about the versions I was talking about. You are correct, and I am indeed aware, that target is part of HTML Transitional and XHTML Transitional as you state; however I do not regard Transitional as being worth bothering with and have a habit of completely disregarding it. Transitional is a mis-mash intended for migrating DOCTYPEs in stages on projects that need it. It's not a good choice unless you absolutely need 'depreciated' attributes on your project (I've never found a compelling reason that would be the case, but imagine that in corporate environments or internal systems it's possible). Transitional is really a hack the W3C threw out to make migration easier, and to my mind should be used only as an absolute last resort.

    Target is not part of XHTML Strict or XHTML 1.1 (which this site is served as, if your browser can handle it), nor is it part of HTML4 Strict. I should have been more specific in my post that I was referring to the 'real' flavours of XHTML.


    As for iframes, you bring up a topic I am not very familiar with, as I have never had a need to use an iframe. Iframe is a special as I understand it, the contents are not actually part of the main document, and do not get parsed with the DOCTYPE of the parent page unless the iframe content doesn't have it's own doctype declaired (please someone let me know if I'm wrong about that - I couldn't find anything to clear it up on the W3C site). I believe you can have a HTML4 document happily living in a XHTML iframe, so there's nothing wrong with using target inside an iframe as long as the iframe document itself is of a Transitional doctype.

From the archives

Other enteries filed under:

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.