Summary
WCAG 2.0 has a concept of a baseline to cater for the fact that the web is continually evolving, and has to remain technology agnostic to remain useful. I don't have a problem with the concept of a baseline; I think it's a good idea. I will write more about the baseline concept at a later date. The following is a conformance claim, along with the script and markup referenced by the conformance claim. Would you consider this accessible?
Author: Gez Lemon
Contents
Preamble
Imagine that we're one year into the future, and WCAG 2.0 has been released. The following is a conformance claim to WCAG 2.0 level 2, stating the baseline, followed by a script and some markup that are the subject of the conformance claim.
The Conformance Claim
- Date:
- 2005/11/18
- Guidelines title/version
- Web Content Accessibility Guidelines 2.0
- URI of the Guidelines
- http://www.w3.org/TR/WCAG20/
- Conformance Level
- Level 2
- Baseline
- HTML, and ECMAScript
- Scope of Claim
- comp.php
The Script (validateForm.js)
function postIt(objForm)
{
if (!document.getElementsByTagName ||
!document.createElement ||
!document.createTextNode)
return false;
if (!isEmail(objForm.email.value))
{
if (document.getElementById('error'))
return false;
var objBody = document.getElementsByTagName('body')[0];
var objError = document.createElement('p');
objError.id = 'error';
objShout = document.createElement('strong');
var objContent = document.createTextNode('Enter email address!')
objShout.appendChild(objContent);
objError.appendChild(objShout);
objBody.insertBefore(objError,
objBody.firstChild.nextSibling.nextSibling);
return false;
}
else
{
objForm.action = 'process.php';
return true;
}
}
function isEmail(strValue)
{
var objRE = /^[\w-\.\']{1,}\@([\da-zA-Z-]{1,}\.){1,}[\da-zA-Z-]{2,}$/;
return (strValue != '' && objRE.test(strValue));
}The Markup (comp.php)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-gb">
<head>
<title>Competition</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript" src="validateForm.js"></script>
</head>
<body>
<h1>Win Some Cash</h1>
<p>
Enter your email address below to enter the competition.
A random email address will win lots of cash.
</p>
<form method="post" onsubmit="return postIt(this);">
<p>
<label for="email">Email: </label>
<input type="text" name="email" id="email">
</p>
<p>
<input type="submit" value="Enter Competition">
</p>
</form>
</body>
</html>Opinions?
According to WCAG 2.0 (draft), that's accessible. Do you agree?
Category: Accessibility.
[this-is-accessible.php#comment1]
Yes, it is accessible. Any user can enter his email address, and the script is not necessary for this task to be executed.
That said, it's completely unclear how important the validation of the email address is. If it's very important, the site would need a server side script in addition to the JavaScript.
The example is correct, but non-real-life and incomplete.
Posted by ppk on
[this-is-accessible.php#comment2]
I agree, it is accessible. If validation is important it can also be done on the server. Its usable without script.
Posted by MarkS on
[this-is-accessible.php#comment3]
Are you suggesting it isn't accessible Gez? You say you agree with the idea of a baseline so I don't see a problem. Client side scripting is a good technique for validation and you haven't provided enough information to determine whether validation is also performed on the server. From the little information you have provided I agree it is accessible. Even without a baseline I think it is accessible.
Posted by Scott on
[this-is-accessible.php#comment4]
Surely the fact that it will *only* work with javascript enabled make it inaccessible to at least some users.
I can't comment on the javascript itself, as my knowledge of that could be stuck on the back of a postage stamp!
Posted by Rich Pedley on
[this-is-accessible.php#comment5]
For HTML 4.01 behavior is unspecified if the action attribute is forgotten. When JavaScript isn't supported, this could kill kittens on the other side of the world, which isn't very accessible. Also, process.php is never reached then.
For older browsers, with support for JavaScript but without support for document.getElementsByTagName (for example) the form doesn't do anything.
And there's no check for document.getElementById.
Posted by Krijn Hoetmer on
[this-is-accessible.php#comment6]
Rich and Krijn,
If scripting capabilities is a requirement specified in the baseline then it is accessible. The baseline requirement is a sensible suggestion so that certain web technologies are not effectively banned as they are in WCAG 1.0. Script enabled browsers are widely available and supported by AT. There is no reason why this should be considered inaccessible. It may cause usability problems for browsers without scripting but that is not an accessibility problem. It is a technology problem which WCAG 2.0 is quite rightly trying to avoid banning.
Posted by Scott on
[this-is-accessible.php#comment7]
I cannot see how it is that accessible since there isn't a proper helpful response to an invalid email address.
I assume this baseline is for desktop machines rather than mobile User Agents.
Posted by Robert Wellock on
[this-is-accessible.php#comment8]
Oh, right, I hadn't noticed the absence of the action attribute. That changes everything: the form is not accessible.
Posted by ppk on
[this-is-accessible.php#comment9]
As Scott rightly states, the technique outlined here would be considered accessible in WCAG 2.0, and yes, I am suggesting that I disagree.
Markup languages are designed with accessibility in mind. In HTML, the image element has an alt attribute. The alt attribute has obvious accessibility benefits, and so it is a required attribute. The form element has an action attribute, which specifies the server-side form handler. The action attribute is a required attribute, as it ensures that visitors are able to submit forms without relying on other client-side technology. We would all like to see scripting used in an unobtrusive way that degrades nicely when scripting isn't available, but this is more about best practice than accessibility. However, the above technique has added an unnecessary barrier.
WCAG 2.0 is based on 4 principles, and one of them is that content must be robust enough to work with current and future technologies. The above technique can hardly be described as robust, as it unnecessarily breaks if scripting isn't enabled. Yes, scripting is covered in the baseline, but this insurmountable barrier for people without scripting (as users of AT are so often asked to switch off) could so easily have been addressed by just adding a target attribute.
To measure robustness requires some means of quality assurance, and validity plays a part in this. However, in WCAG 2.0, validity isn't considered a necessary for accessibility. This poses a bit of a problem, as we now have no means of measuring robustness. If validity was a requirement, then the example here would be considered inaccessible. As it's not a requirement, then the above can be considered accessible despite the huge and unnecessary barrier that results from the technique.
Posted by Gez on
[this-is-accessible.php#comment10]
What accessibility benefits does an action attribute have - remembering the behavioral part is being added with scripting defined in the baseline?
Posted by Scott on
[this-is-accessible.php#comment11]
The missing target attribute means that the markup doesn't behave in accordance with the specification. It's broken. It's all well and good to have a baseline that includes scripting, but specifying a baseline shouldn't allow developers to abuse other specifications. In this case, the abuse means that the markup will not allow access to anyone whose user agent doesn't support scripting, or has scripting disabled - which is okay because scripting was specified in the baseline?
Don't get me wrong; I'm not suggesting that developers pander to people's whims. I'm merely stating that the abuse is just so unnecessary. I would expect guidelines that contain a principle for robustness to at least be able to catch something as fundamental as this, and stop perpetuating this kind of abuse.
For it's many weaknesses, WCAG 1.0 wasn't afraid to require validity, and I think the lack of requiring validity in WCAG 2.0 will be its downfall as it fails to deliver on one of its fundamental principles.
Posted by Gez on
[this-is-accessible.php#comment12]
Imposing the requirement that markup be valid may not be enough of a solution to correct the accessibility problem. A validator will pick up that there is no action attribute, so if I chuck action="getARealBrowserMuppet.php" into the form element, the page now validates, but it still as inaccessible as the invalid version above (with the baseline in place).
I haven't read much about the baseline requirement (apart from JavaScript is part of that baseline) - but does that include a provision for telling an assistive device that the DOM has been modified, as well as allowing the visitor to jump straight to the point where the document was modified? Without that requirement, I'd feel compelled to test whether the method used to present an error message is accessible to the assistive technologies and browser that meet the baseline.
Posted by Isofarro on
[this-is-accessible.php#comment13]
That is a valid point, but I don't think that developers who do things like assign action values through scripting are deliberately trying to make their content inaccessible. I would imagine that it's very rare that people take active steps to make content inaccessible. The example here is a real example I came across yesterday (different form and markup, but set the action attribute through scripting), where the developer thought this was a nifty trick to make sure that the form was validated before being sent. When the problems with this approach were explained, the developer was happy to change it, and a server-side script was added to cater for people without script-enabled browsers.
There isn't a predefined baseline. A baseline is a set of technologies set by the author (or more likely their company, or maybe a higher level like a government) that are assumed to be available in the client, such as HTML, CSS, scripting, gif, jpg, mpeg, etc. Scripting isn't automatically assumed to be part of a baseline, it has to be set by the author.
The baseline doesn't define how technologies should work. In your example here, that would be a User Agent Accessibility Guidelines issue that should be addressed by user agent manufacturers.
Agreed, testing is essential for measuring robustness. Techniques such as progressive enhancement and graceful degradation, regardless of what's in the baseline, do help, but developers should be encouraged to test with as many assistive technologies as possible.
Posted by Gez on
[this-is-accessible.php#comment14]
I would have to say that validation needs to be a part of any future standard.
It's necessary to keep tabs on complex application development and when building sites across many teams / offices / departments having xhtml validation as a basic requirement helps get everyone on board.
In a nutshell, I can use it to hammer lazy or uncooperative teams into getting closer to WAI, and that's a good thing
Re baseline, I agree in principle with the philosophy of not putting a blanket ban on new technologies, but we now know how to create useful JS that degrades well. There just isn't any reason I can think of to create an app that excludes non-JS users.
So at least, every instance of a JS method should be paralleled (is that a word) by a traditional html atribute (so if you want to use onsubmit or onclick, you also need to use action= or a href=)
Posted by Dug on
[this-is-accessible.php#comment15]
The lack of the action attribute on the form element, while it is invalid, means that the form will use the default action and submit to the current URI (comp.php) without scripting enabled/supported; but submit to process.php with scripting enabled/supported.
Although that is a very odd thing to do and tends to suggest that client side scripting is the only barrier against invalid user input (i.e. server side validation is unlikely to occur), the accessibility of the form is entirely dependent upon how the submission is processed by comp.php compared with process.php.
If both process the input in equivalent ways, the page is accessible. If it is the case that the comp.php does not process the input, then no, the form is not accessible.
Posted by Lachlan Hunt on
[this-is-accessible.php#comment16]
The behaviour you describe here is an error recovery technique implemented by some user agent manufacturers, but shouldn't be relied on. According to the HTML 4.01 specification, the behaviour of a form with a missing
actionattribute is unspecified.Leaving aside the fact that a missing
actionattribute is both invalid and the resulting behaviour is unspecified, comp.php does not process the input, as can be seen from the example.Posted by Gez on
[this-is-accessible.php#comment17]
Gez, I'm aware that it is technically error recovery, as I hinted at when I mentioned it was invalid. But regardless of what the spec says, reality indicates that the form will be submitted to the current URI.
As for comp.php, whether or not it would handle the input at all was not explicitly defined in the example. Although it is highly likely that, given that markup and script, comp.php would not do anything with the input (and I would generally not assume otherwise); without seeing the actual PHP code, we don't know exactly what comp.php does beyond outputting the sample markup provided.
Posted by Lachlan Hunt on
[this-is-accessible.php#comment18]
Sorry, I missed the hint. The only thing I read was that while a missing action attribute is invalid, it means that the form will use the default action and submit to the current URI. As that behaviour is unspecified, and there's no guarantee that every known user-agent and every future user-agent that is capable of rendering HTML will observe that behaviour, I thought it was worth pointing it out. I didn't mean to imply that you didn't already know that, but someone else reading this may appreciate knowing that in terms of robustness, it's better not to rely on quirks and stick with standards.
In the example here, if the user has disabled scripting, submitting the form will effectively blank the form for them. They will be asked to fill it out again with no explanation.
comp.php is complete, as is the script and the conformance claim. I'm a bit confused as to why you would believe otherwise. I've a history of not being clear, so I'm sure it's entirely due to the poor explanation I've provided, but comp.php doesn't do anything more than I've shown; neither does the script nor the conformance claim. The only thing that's not clear is what process.php does, but that's not important for this discussion. What's important is, assuming that I've provided all the information required to answer the question, do you agree that the technique used here is accessible.
Posted by Gez on
[this-is-accessible.php#comment19]
Shock horror - another accessibility site declaring that javascript is not accessible. Javascript has been around for years and isn't going to go away just because you don't like it...
Posted by Nathan on
[this-is-accessible.php#comment20]
Nathan, this discussion isn't about JavaScript as a technology, or at least it shouldn't have been. The discussion is about abusing one technology, and fixing it with another. I'm in favour of scripting as a technology, as is every one I know in this industry, and write about it positively.
Posted by Gez on
[this-is-accessible.php#comment21]
I was just being pedantic. Since there is no PHP code shown in the example, only HTML markup, and since it was not explicitly stated, it was possible that you were just showing the output, not the complete file.
To whom? If the question is "is it accessible to everyone", then no. If it's "is it accessible to users with user agents that meet the baseline requirements", then yes.
Posted by Lachlan Hunt on
[this-is-accessible.php#comment22]
I was reading this offline as an rss feed in safari. I am copying and pasting a snippit of what I saw and breathing a sigh of relief that we won't be seeing embedded tags.
The Markup (comp.php)
Posted by Don on
[this-is-accessible.php#comment23]
Sorry, I'm not sure what you mean, Don. WCAG 2.0 doesn't prohibit any elements, regardless of the DOCTYPE or schema.
Posted by Gez on