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.

Entry Information

Posted:

Fri, 30th Nov 2007 at 18:11 UTC

Filed under:

• Web Development

Tags:

• web development
• web standards