w3c Valid xhtml/Accessibility question
Home / Legal Issues & Web Standards / w3c Valid xhtml/Accessibility question
Hi,
A friend and I were having a discussion about xhtml validation and I thought I'd run it past you guys.
Does failing xhtml validation mean that your site is not accessible?
I know it's a broad question but that was the point of the discussion so I won't complicate it with details.
Appendix A on http://www.w3.org/... covers validation but it's not a guideline, and my interpretation of it is more as a recommendation of using a validator to alert you to any missing tags such as 'alt' on images etc.
Share: 
short answer - depends.
if the invalid xhtml is a missing closing tag for links then it sure as hell would affect accessibility - but even more so it would affect usability.
If it's a missing closing tag for a paragraph then probably not.
A valid xhtml page is not necessarily accessible. An invalid xhtml page is not necessarily inaccessible.
A good example is: Zen Garden - Geocities (Hi Bruce).
_________________
my mind is on a permanent tangent
Share:
You may find this relevant from the WAIG 2 guidelines.
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)"
The easiest way to fulfil this is by validating.
http://www.w3.org/...
_________________
If it can go wrong it will. So don't worry about it.
Share:
| Rich Pedley wrote: |
|
A good example is: Zen Garden - Geocities (Hi Bruce). |
Beautiful!
Well I guess the crux of my question is this; would a document that had a <br> instead of a <br /> tag fail an accessibility audit. I personally can't see how it would but the other person I was discussing this with implied it would (we didn't discuss the <br> example). His line was this 'if it's not valid XHTML 1.0 Transitional (or whatever doctype) then it's not accessible'
Share:
| Cormac Maher wrote: |
| the crux of my question is this; would a document that had a <br> instead of a <br /> tag fail an accessibility audit. I personally can't see how it would but the other person I was discussing this with implied it would |
It rather depends upon how the audit has been set up - it is in breach of WCAG 1.0, so even a single failure to validate under WCAG 1.0 would mean that you could not state that the site reached WCAG 1.0 at the AA level.
However, if you are looking at the practical accessibility to the end-user, then I would agree with you that it is not likely to cause any real world accessibility problems.
_________________
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
Valid markup was required in WCAG 1.0. The portion of WCAG 2.0 which AlunD quotes requires valid syntax and nesting. In this case, <br> in an XHTML 1.0 document would fail since that specification requires it be given an end tag. This is usually accomplished via a rather odd (imho) self-closing start tag syntax, so you do need <br />.
But if you use HTML 4.01 (which you should be) then <br> is correct and <br /> is incorrect.
Either one will work in text/html documents sent to any viable web browser. But the HTML 4.01 approach is more efficient.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Briefly: it doesn't always cause problems, but you should avoid it nevertheless.
With browsers as they are (i.e. dealing with the web as it is), invalid HTML is very unlikely to cause any serious accessibility problems unless it deforms the DOM in a way that would affect all users, impaired or otherwise. The earlier example of an improperly closed link is a good one; on the other hand, an unencoded ampersand in a URL probably won't be noticed by anyone who doesn't actually run your page through a validator.
Serving invalid pages is not an ideal proposition if you can possibly help it*, but invalid HTML is the reality of the web, and most browsers have fairly robust mechanisms for making sense out of it. Since screenreaders take the output from browsers, the accessibility of the page is as good as what sense a browser can make from it, which is usually "just enough".
* Some people dispute the practicality of validation. I myself find it very useful: I often catch errors through validation that messed up the DOM enough to cause the page to render improperly, or broke some Javascript. If I was using invalid HTML anyway, these errors would take longer to find because by this means because they would be buried among whatever other errors I decided to tolerate.
Share:
| Ben Millard (Cerbera) wrote: |
| But if you use HTML 4.01 (which you should be). |
_________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
| Johan007 wrote: |
| I also find HTML is also quicker to develop in (add this advantage to your list Ben?) |
Even if you're piecing the markup together in PHP, omitting optional tags simplifies the code. Especially for nested lists and any data tables.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Ben Millard (Cerbera) wrote: | ||
|
...and I'm the grumpy one sat in the corner who still likes XHTML as a markup language and couldn't really care whether it's served as text/html or not
_________________
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
oh oh oh another advantage... I think (therefore not an expert who may know better) that HTML4.01 sites are quicker to convert to HTML5 
Simply adding
| Code: |
| <!doctype html> |
_________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
| JackP wrote: |
| […]I'm the grumpy one sat in the corner who still likes XHTML as a markup language and couldn't really care whether it's served as text/html or not |
I like XHTML as a markup language for certain purposes (e.g. SVG, MathML), but not just for sending marked-up text to browsers.
I should note that my XHTML doesn't look much like the "Transitional" pseudo-XML that most people write. I always include the charset PI, stylesheets are attached in PIs and not links, and I don't bother with spaces before the closing slashes. If IE has to read my pages, IE gets them transformed into HTML.
Share:
| jordan wrote: |
| I like XHTML as a markup language for certain purposes (e.g. SVG, MathML) [...] |
| jordan wrote: |
| If IE has to read my pages, IE gets them transformed into HTML. |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Ben wrote: | ||
|
No, I did mean XHTML, although I can see why you thought otherwise. Specifically, I've had occasion to use rather complex equations in XHTML documents while I was working on my university coursework, and therefore used the XHTML 1.1 plus MathML 2.0 plus SVG 1.1 doctype.
| Ben wrote: | ||
|
Quite, we're in agreement that HTML is the best way to present marked-up text.
However, in my current pet project, I have marked-up text mixing intimately with SVG, so XHTML really is the only way. However, since I want it to work in IE, I'm using some rather curious XSLT and Javascript to make it all work with somewhat deformed HTML and VML, which is the closest IE gets to vector graphics in web pages.
Share:
In reply to the other XHTML thread:
In my opinion, and given that standard XHTML adds almost nothing to HTML 4.01, there are only a few reasons one should use XHTML:
- Your site, unlike 99.9% of websites ever made, actually uses other XML technologies such as MathML, SVG or client-side XSLT.
- The code you write has to be parsed as XML for some reason in your back-end. (It could be argued that, since you are using XML anyway, you should simply transform your output into valid HTML using XSLT.)
- Your site is specifically targeted at the very few mobile devices which only support XHTML—specifically, in this case, you should be using the XHTML Basic doctype which was written specifically for such devices, which very few people who use XHTML actually do. (And, again, you should arguably be transforming your output to HTML for the web anyway.)
This leaves a very restricted set of valid usecases for XHTML.
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum