Rant on W3C Accessibility and XHTML guidelines

I believe the bit about pages working with "scripts, applets, or other programmatic objects are turned off or not supported," is due to the fact that since screen readers can only read text, many people who use them, use them with ancient text-only browsers, which also lack support for scripts, applets, etc.

I have no explaination for the prohibition on "target".

I've read over the various xhtml specs, and I've come to the conclusion that xhtml 1.1 is completely useless for people writing real world web applications. It breaks with history entirely too much. Completely pointless changes, like requiring hidden inputs to be surrounded by a visible element, seem to be changes just for religious reasons.
That said, I think xhtml 1.0 Transitional is a good goal. It clears out the tag-soup problem, without destroying very useful html constructs.

Seems to me that one possible compromise would be to simply make it possible, either at the page or application level, to specify which standard you want generated markup to comply with. Those who are concerned with accessibility could specify that, while those who want valid XHTML could specify that (perhaps including *which* XHTML version). If the two are in conflict, the best you can really do is to give developers a clear choice, and make as clear as possible which you are generating by default (I'd opt for XHTML by default, with the ability to validate for and/or generate markup for accessiblity as an option).

The obvious downside to this is that it potentially adds a lot of work in writing the code that generates the markup.

I would most certainly prefer that in the web.config a devloper could set his/her target output standard. HTML 4.0, 4.01, XHTML 1.0, 1.1. I would personally consider this a huge step forward for the project. So hear, hear for XHTML support. Thank You.

The thing that bugs me about Visual Studio.NET at the moment is the way it changes your code for you. Why can't this option be disabled so we can create XHTML compliant code? Suppose you bring this new version out; what happens when we need to render a tag differently? Why should we have to find complex ways to override the controls? Why not let us control that ourselves. :) Just my 2p's worth.

From your comments it seems as if you are fairly new to XHTML. I agree w/ most of the comments here that the best approach would be to give the user a choice. If the developer choose 1.1 Strict, then do not include the target attribute as a valid attribute for the HyperLink control. If the user chooses HTML 4.01, then include the target attribute in the schema.

There are some very egregious violations that should be easily correctable. The addition of the type attribute on <script> tags. The invalid naming of hidden variables starting w/ __, and, yes, enclosing <input> tags with a proper block element. You are confusing "accessibility" with "usability." Client side script may make the page easier to use, but is rarely used to make a page more accessible. True accessibility in your example would present the user with a page containing only a message explaining the error, the necessary control to fix it, and submit/go-back buttons. No other controls and, therefore, no script necessary to set the focus on the control in error.

Wide use of XHTML 1.1 won't start happening until all browsers start using the ContentType header value of "text/xml". However, day by day more and more developers are latching onto XHTML 1.0 ( Transitional and Strict ) and demanding tools that support it, despite the necessary workarounds for IE6. It would be a big big failing for the next version of ASP.net to not include support for it.

Why on earth would you want to target XHTML 1.1, when that spec explicitly states it is to be served as application/xhml+xml, and IE at this point has no clue about how to handle that MIME type?

There are other good reasons to avoid 1.1. Just because it's the latest, doesn't mean it's necessarily the greatest (and although you *can* -- using modularization techniques -- add the target attribute to that DTD). For example, for apparently no other reason other than theology, you can't use the "lang" attribute any more, with 1.1 it has to be the more verbose "xml:lang".

The deprecation of the target attribute comes from XHTML 1.0 Strict. The main purpose for that DTD (and then 1.1) was for *content*, not window behavior or presentation inside the markup. The problem is, the W3C didn't give us a way to replicate 'target' with a CSSish mechanism. No 'class="new_window"' (where ".new_window" would be declared in the style section), and no CSS way of saying "new window". (Some folks at the W3C are quite aware of this conundrum. Whether a good solution is reached for XHTML 2.0 will, as usual, be a matter of politics, committees, and miraculous accidents.)

So, what to do? You could

a) Use XHTML 1.0 Transitional. As Andy Smith recommended above. This not only gives you 'target', you even get 'font' and other old Netscapisms. It must be well-formed, but you can *serve* it as text/html (which is a euphemism for tag soup, and which means everything from Netscape 2 to IE6 can slurp it up just fine) provided the guidelines in Appendix C of that Rec are met.

http://www.w3.org/TR/xhtml1/#guidelines

b) Use XHTML 1.0 Strict. Ah, but no target. Still, wouldn't it be nice if developers could *pick* the DTD they wanted to use? (Hint, hint :)

c) Let the developer use his or her *own* DTD. That's what I've been doing for new pages. It's XHTML 1.0 Strict, minus the xmlns="..." theology on the <html> element, plus the 'target' attribute on the <a> element.

Again, the key is to allow the user the option to decide which DTD to use (1.0 Transitional, 1.0 Strict, 1.1, or their own). If you make Transitional the default, this would satisfy the no doubt vast majority that don't give a hoot about anything except whether "it looks good in IE", but the *choice* would tantalize everybody else -- believe me, you would have earned some real respect! :)

Note: if they choose HTML 4 (Strict or Transitional), you'll have to emit SGML syntax (<br>, <meta ...>, etc.), whereas if they choose XHTML (whatever flavor), it's XML syntax (<br />, <meta ... />).

What if they don't want any DTD at all? Probably ought to give them the choice of which syntax to use (SGML or XML).

Accessibility is another issue, and probably shouldn't be conflated too much with the vocabulary (DTD) you're writing against, except insofar as to note that people who are writing XHTML Strict (or some close variant) are generally more likely to be concerned with accessibility than the "looks good in IE, must be OK" crowd.

Excellent thread. I for one would like to know why we are still persisting with the explicit forbidden-ness of script when there are plenty of screen readers now available which are script-savvy - this rule was made in the days when browsers were an emerging technology - that plainly appears to no longer be so. So why can't we change the standard to reflect the modern world of assistive technologies and move on?

Target was also useful for frames (which are still in XHTML 1.1). Doesn't make sense to me either.

I suppose I'm a bit late on commenting this item, but I feel different about some of the things discussed here. I personally like (most of) XHTML 1.1, and think that the removal of the target attribute is a Good Thing. What you write in XHTML is the logical structure of your document, and information about whether to open a link in a new window or not is doesn't belong there. Perhaps W3C should give a way to do that in CSS, although I'm not convinced about that myself. I think the world would be a better place without the attribute alltogether. If I see a link, and *wants* it to be opened in another window, I am perfectly capable of doing it myself. If I click a few links on different pages (without opening them in new windows) I expect to only have one window. I don't want those pages to open new ones whenever they feel like it.

Then, although it's tragic, the problem that IE cannot handle "application/xhtml+xml" ins't *really* a problem with XHTML 1.1, but with IE. Unfortunately though, it may very well be a reason not to use XHTML 1.1.

I suppose it's really late now, but I, along with everybody else I assume, would really like to be able to specify what doctype I'm targeting (no pun intended) in VS.NET.

I have found a number of articles and postings pertaining to XHTML violations of asp.net. However none of them appear address one of the most blatant XHTML violations. When using SmartNavigation, the page renders the following tag:

<IFRAME ID=__hifSmartNav NAME=__hifSmartNav STYLE=display:none src="javascript:smartnav=1"></IFRAME>

Notice the absence of quotes around the attribute values for the ID, NAME and STYLE attributes. Not only is this invalid XHTML, it isn't even well formed XML.

This problem is actually preventing me from using smart navigation in my apps becasue I need to load the rendered page output into an XMLDocument object. XHTML1.1 compliance is not tremendously important to me personally, but XML well-formedness is paramount.

Bravo Jelks Cabaniss.

Nothing annoys me more than mindless abuse of web standards such as XHTML. Too many people read sites like zeldman.com and think it is a good idea to serve XHTML up as text/html.

As Andy smith said "I've read over the various xhtml specs, and I've come to the conclusion that xhtml 1.1 is completely useless for people writing real world web applications." I could not have put it better myself.

I was one of the early adopters of tier abstraction, i.e. separation of structure, style, behaviour et al. But people seem miss the concept entirely (i.e. why the hell use content negotiation with HTTP accept flags).

Well here is some good reading material: http://www.hixie.ch/advocacy/xhtml

To be honest I haven’t got anything else to say. It’s a subject that depresses me no end.

Its a shame that some people are still clinging tightly to the old ways when they've been so obviously discredited. No-one is forcing you to use XHTML 1.1, you are completely free to combine content and presentation to your hearts delight!

That said, if you insist on forcing the user to open your link in a new window, you can easily do this with JavaScript, where behavior like this belongs.

There's absolutely no reason to use XHTML 1.1. You get exactly the same from XHTML 1.0 Strict, only you can (if you need to) serve it as 'text/html'. Also, the Strict DTD (without all the visual and behavioural attributes) has existed since HTML 4, and isn't new with XHTML 1.0 (Strict).

The point about scripting is that there's absolutely no reason for it to be there in the first place. It's a really great addition to regular HTML functionality in browsers that support it, but it's no point in replacing perfectly good HTML functionality (like 'href') with JavaScript. Instead, just add the JavaScript as an alternative to the HTML functionality, so it will gracefully degrade to browsers without JavaScript support.

Hidden inputs can be made valid with the 'fieldset' element or with a 'div' inside the form, which have been mandatory since HTML 4.01 Strict. Making the 'div' containing the hidden fields invisible ('display: none' in CSS) is easy, and not really necessary (it will be invisible as it has no content).

When it comes to choosing what standard you want to use for your HTML, I would hope this was just a matter of changing DOCTYPE. The types of HTML you should choose from should at least not be as today with 'Internet Explorer 5.0' and such, but the actual HTML DOCTYPE versions, ranging from HTML 3.2 to XHTML 1.1 (with all the different DTD's in there).

Lastly, XHTML 1.1 has no such thing as 'frame' or 'iframe' defined. XHTML 1.0 Frameset is a DOCTYPE that allows frame usage, and XHTML 1.0 Transitional allows iframe usage, but as XHTML 1.1 is virtually the same as XHTML 1.0 Strict (and HTML 4.01 Strict), it doesn't have any legacy elements or attributes defined at all. There is only one DTD for XHTML 1.1, and that DTD is just about the same as for XHTML 1.0 Strict.

Accessibility means EQUAL access for all, that includes, but it not limited to people with disabilities. Core functionality of the site that relies purely on Javascript to be triggered is a failure in good development practice. Even today i can go to any number of large sites on my powerbook and am totally unable to navigate because they use 'option-jump' lists that arn't cross browser or cross platform friendly. Neither 508 or SENDA over here in the UK specify that Accessibility == Disability and should never be treated as such. In the end it is all about marginalising other browsers and platforms by attempting to impose internal, proprietary, standards, something that goes against all sense of good practice.

Whenever you use smartnavigation, make sure you use absolute paths in your scripts, or else css gets ripped off. Take a look at my blog on this topic http://sanjaykattimani.blogspot.com/2005/10/net-smartnavigation.html