Hacking Textpattern for WCAG accessibility validation

Jan 15 2005

There are some minor niggling problems with the default Textpattern installation that mean that your site will never be able to claim WCAG accessibility compliance (and won’t validate using the W3C validation service) – but implement the changes below and all will be right with the world!

Unescaped ampersands

Although some may feel that it is not deserving of attention (witness the recent discussions surrounding Mike Davidson’s ABC News redesign), leaving your ampersands unescaped can cause serious problems for your site (see Ampersands and Validation over at 456 Berea Street for a more detailed explanation why).

The Textpattern comments form uses the REQUEST_URI server variable to create a hidden form field which holds the URL of the page you are commenting on, which it then uses to redirect the commenter back to the relevant entry when their comment is submitted. However, if the URL has an ampersand in (there may be querystring variables generated by a calendar widget, for example), it is not escaped – to fix this, just find this line in the publish/comment.php file (around line 218):

? fInput('hidden','backpage',serverset("REQUEST_URI"))

and replace it with this (remove the space in “& amp;”):

? fInput('hidden','backpage',str_replace("&","& amp;",serverset("REQUEST_URI")))

Voila – instant escaped ampersands in all your comment forms, and no validation errors.

Deprecated target element

If you are using an XHTML Strict DOCTYPE, the target attribute of the anchor tag is deprecated. This means that you can’t do things like this:

<a href="example.html" target="_blank">Example page</a>

Unfortunately that is exactly what Textpattern does throughout the source code. Specifically, there are multiple instances where links that are intended to pop-up are constructed like this:

<a target="_blank" href="example.html" onclick="window.open(this.href, 'popupwindow', 'width=400,height=500'); return false;">Example page</a>

The code is written in such a way as to be more accessible – if the visitor is using a browser that doesn’t support Javascript (or has Javascript turned off), the link will still work and open in a new window as intended. If they have Javascript enabled, the window.open function will work, and the “return: false;” command tells the browser not to follow the value in the href attribute of the link.

So we have something of a dilemma. If we remove the target attribute the page will validate, but if Javascript is disabled the link will not pop-up any more; instead it will open in the same window (and possibly cause the visitor to lose what they are typing). For guidance we can turn to the Web Content Accessibility Guidelines – checkpoint 10.1 states that:

Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

But we are doing this to retain a pop-up window! As with many accessibility issues it becomes something of a judgement call – pop-ups are not specifically banned, but the guidelines do hint that avoiding them is preferable. I think I’ll choose a halfway-house solution – remove the target attribute to ensure validation, but add a title attribute to any links that previously had a target to alert visitors to the fact that the link will open in a new window.

In the lib/classTextile.php file, locate the textile_popup_help function (around lines 903-908), and replace the target=”_blank” code with the following (the wording can be changed to suit your own site or style):

title="Opens a new window containing details of the Textile shortcuts you may use in your comments"

Summary

These two quick fixes to the Textpattern source will address two minor bugs that can affect your accessibility and validation. I will be adding more as and when they become apparent – if you are aware of any issues, please let me know.

Filed under: Accessibility, Textpattern.

Digg this article

Bookmark this article with del.icio.us

Previously: @media 2005

Next: GAWDS have a new member


Comments

Stuart
1329 days ago
Very handy though I think I may wait till after v.1.0 is out before I do anymore hacking. I have enough problems to be going on with. :grin:
#1
c. s.
1318 days ago
When escaping strings in form elements (textarea, input type=”text”), it’s better to use htmlspecialchars(), rather than just str_replace to encode the ampersand… it catches other things, too, like quotes and greater/less than signs. Less typing, too.
#2