Validity: A Call To Arms
I think it's necessary for a document to be valid for us to be able to guarantee the future robustness of the accessibility of it, and I've blogged about it. I apologise for reproducing a cut-down version here, but I do think it's important (I'll soon find out if everyone else agrees).
Basically, at any given time, all the currently available web browsers may be able to support invalid markup. We cannot guarantee that this will always remain the case. The principle "Content should be robust enough to work with current and future user agents (including assistive technologies)" will be more easy to adhere to if things are produced to a standard.
To make this technologically neutral, we simply state that Web units or authored components are produced to the documented standard for that technology.
The reason this is such a concern is that if you don't need valid documents, you can use deprecated or even entirely new elements which may only be supported on a limited range of browsers/platforms. Netscape 4 added a layer element which caused problems in some cases when you had a browser that did not support it. Netscape and Internet Explorer each supported their own way of marking up shortened terms - either <acronym> or <abbr> but not both. If there is no requirements for documents to be valid, there is no reason for user agents further down the line not to add new elements that only they support.
Browser wars come at the expense of accessibility. Back accessibility, back standards, back validity. Send a comment to the W3C telling them we want validity back in. Please. Or if I'm wrong, put my mind at rest.
[winds head in, preparing to be shouted at]
Jack Pickard The Pickards Information Services| Blog | Twit
Share: 
| JackP wrote: |
| I think it's necessary for a document to be valid for us to be able to guarantee the future robustness of the accessibility of it, and I've blogged about it. I apologise for reproducing a cut-down version here, but I do think it's important (I'll soon find out if everyone else agrees).
|
I disagree. Well-formedness of markup is crucial to accessibility (orthogonal to validity, but still technically required for any SGML or XML application). But no browser has ever choked on an unrecognized attribute or unknown tag name. Similarly, the resulting HTML DOM tree with unknown attributes and elements is consistent and predictable (as for XHTML, it being XML there isn't a problem in the DOM with unknown elements or attributes).
If one relies upon custom attributes or unknown elements for page behavior/presentation/content/etc, then I would say it violates accessibility criterion. Otherwise, if it doesn't harm semantically encoded data, the page presentation, or anything - what is so bad about it? The whole concept of "unobtrusive scripting" I think can be extended to "unobtrusive markup" (though primarily with attributes, since using unknown elements generally introduces unknown semantics, which is bad joojoo).
| Quote: |
|
Basically, at any given time, all the currently available web browsers may be able to support invalid markup. |
As they must. A vast majority of the web is markup goo. It is, unfortunately, a situation we must deal with instead of happily ignore.
| Quote: |
|
We cannot guarantee that this will always remain the case. |
Yes we can. Those billions of web pages aren't going away anytime soon.
| Quote: |
|
The principle "Content should be robust enough to work with current and future user agents (including assistive technologies)" will be more easy to adhere to if things are produced to a standard. |
Agreed. Nobody is saying we should continue the practices of 1996. I don't know a single serious web developer who doesn't try very hard to meet those standards and expectations.
| Quote: |
|
To make this technologically neutral, we simply state that Web units or authored components are produced to the documented standard for that technology. |
Browsers must have error tolerance. The web is open, and an unstoppable vehicle of information liberation and freedom. Not everybody has the ability to sit down and learn every minute detail of XHTML and CSS required to put together a 100% standards-compliant website. What they might have access to instead is GeoCities or Google's page builder or Nvu or Frontpage or any number of tools available to easily put your ideas on the Internet. Philosophically, I would rather have a venue where anybody with access to even a 14.4 kbps satellite downlink in the middle of some 3rd world country or a cellphone on a data network can:
1) read what is already online (requiring a browser with error tolerance) and 2) contribute their own knowledge to the online mass (which, once again, unfortunately may require tools which don't produce spectacular markup and styling).
Once again, I stress that ideally every document on the web conforms to some open, published standard. And I encourage everyone to work towards that goal. But there is a reality to the situation too.
| Quote: |
|
The reason this is such a concern is that if you don't need valid documents, you can use deprecated or even entirely new elements which may only be supported on a limited range of browsers/platforms. Netscape 4 added a layer element which caused problems in some cases when you had a browser that did not support it. |
The layer tag didn't cause problems. Similarly, margintop/etc attributes on the <body> tag didn't cause problems. It was developers relying upon their support in the browser which caused problems. Back in the day I used plenty of <layer> tags which no problems in IE4 and other browsers, simply because I knew where and how to code fork, and not to expect its behavior in NS3 and IE3, etc.
| Quote: |
|
Netscape and Internet Explorer each supported their own way of marking up shortened terms - either <acronym> or <abbr> but not both. |
They're both in fact part of the XHTML specification, and every browser but IE supports them both. I don't know the NS4 behavior of those tags though, if that's what you are referring to.
| Quote: |
|
If there is no requirements for documents to be valid, there is no reason for user agents further down the line not to add new elements that only they support. |
That's wrong. In the very least, every browser (but IE... sort of...) support XML namespaces. People don't lambast Mozilla for inventing XUL. Why not? Because XUL is available only as an XML application, and you must use namespaces to integrate XHTML with it (and vice versa). In fact, compound XML documents are the future of the web. I have been routinely integrating SVG, MathML, and XHTML all together. But, wait for it, my pages will never validate, because DTD is simply too limited to meaningfully validate compound documents with (despite it entirely being written with web standards). (And yes, I do know about the XHTML+SVG+MathML doctype that W3C provides... it simply isn't extensible enough). To achieve validity on tomorrow's web, you are going to require XML Schemas and possibly RelaxNG support in every user-agent. DTD is big enough as it (Firefox doesn't even understand DTD's, it just parses out entity declarations and such.)
Ultimately, it will be too complicated to require validity of compound XML applications in my opinion. Well-formedness is more than adequate. If browser vendors want to add tags, they will do so via an XML namespace, which is entirely kosher by most people.
| Quote: |
|
Browser wars come at the expense of accessibility. |
Browser wars also spark innovation. See the jump from NS3/IE3 to NS4/IE4 (e.g. the beginning of the dynamic (client-side) web). Now we have the capability to create a new breed of accessible web applications (see some of the "accessible DHTML" stuff going on at the Mozilla camp), where we can provide a experience far superior to the static webpages of the old days, to both impaired and unimpaired users alike. I would say that in the long run, the browser wars of 199x elevated the playing field to a whole new level and made the web a better place overall, even if we are still dealing with the fallout of it today.[/list]
Share:
But until those "innovations" become standardised and widely supported, pages which use them will often fall apart or provide an inaccessible experience in other devices.
User agents must handle invalid documents otherwise their users won't be able to access Google, BBC, eBay, Amazon and loads of other major websites. As Jason points out, to ensure the web remains an open medium for people without technical knowledge UAs must continue to handle invalid and badly formed documents and general bad practise indefinitely.
Having said that, professionals must learn to do their job properly. Producing valid markup to a Strict document type is a minimum level of quality, along with a basic use of headings, paragraphs and the odd list. People unable to produce that sort of markup are not professionals, but they still have a right to publish on the web.
Last edited by Ben Millard on 19 Jun 2006 03:30 pm; edited 1 time in total
Share:
| Cerbera wrote: |
| Having said that, professionals must learn to do their job properly. Producing valid markup to a Strict document type is a minimum level of quality, along with a basic use of headings, paragraphs and the odd list. People unable to produce that sort of markup are not professionals, but they still have a right to publish on the web. |
Sorry, a bit of an I agree post with Jack and Cerbera. Browsers can and will continue to support dodgy mark-up, but that is not an excuse for professionals to produce dodgy mark-up and/or standards bodies to endorse the same.
Share:
| Cerbera wrote: |
| Having said that, professionals must learn to do their job properly. Producing valid markup to a Strict document type is a minimum level of quality, along with a basic use of headings, paragraphs and the odd list. People unable to produce that sort of markup are not professionals, but they still have a right to publish on the web. |
Yay, I'm not a professional!
Share:
| Cerbera wrote: |
| But until those "innovations" become standardised and widely supported, pages which use them will often fall apart or provide an inaccessible experience in other devices. |
Only if the developer relies upon them for the viewing experience. That's the whole point.
Progressive enhancement, usable fallback. It's no different than with complicated AJAX/DOM stuff.
| Quote: |
| Having said that, professionals must learn to do their job properly. Producing valid markup to a Strict document type is a minimum level of quality, along with a basic use of headings, paragraphs and the odd list. People unable to produce that sort of markup are not professionals, but they still have a right to publish on the web. |
I totally agree. Could not have said it better, in fact.
Share:
I agree that well-formed is more important than valid for accessibility. Though I think validity should also be required albet at a higher level. The importand thing is that all browseres, ATs and small-screen included, need to have some reliability in the code they are given in order to have some consistancy in interpretation.
I'm not saying that browsers shouldn't account for bad code, because they should. This, however, should be defined in the UAAG. As for the WCAG validity should be covered.
Jonathan Worent
The early bird gets the worm, but the second mouse gets the cheese.
Share:
| jw_developer wrote: |
| I agree that well-formed is more important than valid for accessibility. Though I think validity should also be required albet at a higher level. |
| Jason Davis wrote: |
| ..only if the developer relies on them for the viewing experience... |
If the developer relies on (for example) "layer" for the user experience, there's no fall back if it's not supported by a particular browser. It's not his fault that browser doesn't support the layer element. He's used HTML which is in his baseline, he just hasn't used VALID HTML, but that's perfectly all right, because no-one has asked him to.
| Cerbera wrote: |
| People unable to produce that sort of markup are not professionals, but they still have a right to publish on the web. |
...I do enjoy a good debate. The problem is most of us are in agreement on most of the points, meaning that any disagreement is being focussed on a small area (basically it seems to me we all agree validity is a good thing, but disagree at what level of accessibility compliance, if any, should it be required.)
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
| JackP wrote: |
|
If the developer relies on (for example) "layer" for the user experience, there's no fall back if it's not supported by a particular browser. It's not his fault that browser doesn't support the layer element. He's used HTML which is in his baseline, he just hasn't used VALID HTML, but that's perfectly all right, because no-one has asked him to. |
Right. However a browser not supporting the <layer> tag silently ignores it in a predictable way, so there is automatic fallback (it simply not doing anything). As long as <layer> is used for an enhancement and not core experience, I don't see anything wrong with that. And of course, the entire point is moot since no one uses <layer> anymore, and any custom tags would be inside XML-friendly namespaces, which have been specifically created by the W3C to combine XML applications (and subsequently combining markup from different specifications - XHTML and a hypothetical IEml (XAML?
) for example).
| Quote: |
|
The problem is most of us are in agreement on most of the points, meaning that any disagreement is being focussed on a small area (basically it seems to me we all agree validity is a good thing, but disagree at what level of accessibility compliance, if any, should it be required.) |
Totally. No one in their right mind would say validity is a bad thing. Similarly, everybody can recognize well-formedness as important (even crucial for a quality page, since there is well-documented craziness in browser parsing errors). I've always considered the question to be how much "quality" does a page must have in order to be deemed accessible. Validity does not seem to affect assistive devices too much (as long as the page was written with fallback in mind) - especially since the more popular screen readers piggy back IE (? yes?).
A poor analogy would be do we allow only 5-star crash tested, hybrid 40 mpg cars to drive our highways, or do we also allow the gas-guzzling rollover-happy SUV's to ride them too? They are both cars (well-formed in that respect), but a car that gets worse gas mileage than the original Ford Model T (the SUV) certainly doesn't do a good job at being called a car (valid?).
Share:
As we know even valid mark-up fails to render consistently sometimes but validating your mark-up should help to reduce the costs incurred during testing stage. So we create our mark-up prototypes and validate them before publishing or handing over to the programmers.
After a large site goes live it’s a new ball game and saying an invalid site is unprofessional can be an insult. Professional sites often fail to validate during use because of third party reasons e.g. unrecognised mark-up or characters provided by third party advert tracking or something done via the CMS. These are not really issues of less Accessibility and can be fixed over time. Testing and Usability is still the key to Accessibility be it an more expensive one than simply running a valuator through it has little effect.
Can some one provide us with a current example where invalid mark-up is detrimental to Accessibility?
Johan De Silva / Portfolio
Share:
Create documents that validate to published formal grammars.};-) http://www.xhtmlcoder.com/
WVYFC chose the Yorkshire Air Ambulance as the main charity to fund raise for in 2006
Share:
| Robert Wellock wrote: |
| Create documents that validate to published formal grammars. |
doesn't cut it, I'm afraid. While I disagree with Johan's thrust (because I think if we're talking about robustness, and future technologies, you can't ensure compatability unless you're working to spec), he's asking for an example where something invalid is a barrier to accessibility guidelines.
I'd refer back to my layer example - if it's not valid, why assume the designer will have provided reasonable fallback?
However, the "create documents..." one, while it is a failure of WCAG 1.0 Priority 2, is not in itself a barrier to accessibility. It is a failure of a WCAG checkpoint, but that's not the same thing. Something that fails a WCAG checkpoint is less likely to be accessible, but this is not because it fails the checkpoint, it's because it's not sufficiently flexible/robust etc.
I also half-disagree with Johann on the "unprofessional" thing. I think it is unprofessional for a web designer to produce a site that doesn't validate, even if it's a large site they maintain (and yes, there's been times my site hasn't validated, and I considered it unprofessional, despite the fact it's just a homesite). If they then hand over the site to someone else and it later becomes invalid, that's not the designers fault, but I still think it looks unprofessional.
Of course, I don't expect everyone to agree. This is a highly subjective judgement...
And I don't think anyone's trying to argue that accessibility and usability testing should be shunted to one side to allow the mighty validation to take over, merely that validation should be considered as part of the whole, rather than ignored entirely.
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
I'm with everyone who wants to see a greater requirement for validation, though as much from a purist and professionalism viewpoint than just for increased accessibility. I really hope that validation is put back into WCAG 2 before it's released.
I think authors should probably be able to define their own standards if they really want to (since there's essentially no way to define which standards are acceptable, or who is entitled to release them) but those standards must be codified and published by them (as part of their baseline). Of course this should be discouraged. I'd also like to go further than just validation, and require that formats are used strictly according to their specifications - so for HTML, tags must be used according to their semantic meanings.
Undoubtably the current situation with borken markup everywhere creates additional problems for accessibility tool makers, who have no choice but to cope with invalid markup and attempt to handle everything in a sensible way as dictated by other browser manufacturers. The sooner people start sticking to valid markup, the easier it is will become for all UA makers.
I came across a specific real-life example where invalid (yet well-formed -- assuming my understanding of well-formedness is correct) markup could cause an accessibility problem today with the DTI website. Each page has two <title> tags in the <head>. Firefox uses the first one which actually contains the document title. Presumably this is true of whichever browsers they tested the site in too. But who's to say which tag some other UAs will use. Lynx certianly doesn't display the page titles (presumably it's using the contents of the second tag, which is empty). A missing document title is certinaly an accessibility issue, and this problem could not have occured if the pages were valid.
(OK, so perhaps this would also have been caught by the current 'unambiguously parsed' guideline, but IMO you cannot guarentee unambiguous parsing unless your markup is valid -- UAs may have different ways of handling invalid markup.)
Share:
The DTI doesn't use formal grammar either. Coloured M$IE Scrollbar: black UA scroll-button on black scrollbar and the list can go on. Well-formed is the requirement of XML, validity isn't.
An XML document that meets the conditions defined in the XML 1.0 Recommendation must be readable without ambiguity and Syntax errors will be detected by a XML parser without schema of any type.
Mainstream validity isn't going to really happen its just a pipedream as would having all pages richly Semantic albeit I have to agree the WCAG 2.0 is mucked-up and markup validity is an important factor in ensuring a more robust page.
};-) http://www.xhtmlcoder.com/
WVYFC chose the Yorkshire Air Ambulance as the main charity to fund raise for in 2006
Share:
| chaos wrote: |
| I'd also like to go further than just validation, and require that formats are used strictly according to their specifications - so for HTML, tags must be used according to their semantic meanings. |
I'm not 100% sure about this - the HTML spec is almost a decade old. I'm pretty sure we're using HTML tags now for purposes which the authors of the HTML 4 spec did not envision, or intend, for the language. The only example I can think of, off the top of my head, is <ul> for site navigation menus. I seem to recall an old W3C document recommending that navigation should be marked up using <map>.
Anyway, my point is that if we demand that tags be used only as specified by the W3C, then the spec needs to be brought up to date and needs to be sufficiently flexible to cover any reasonable future use of the language.
There aren't very many tags in HTML so it's difficult to be completely semantic, all the time, without slightly bending the intended use of the tags. Or turning everything into a list of some sort
Share: