XHTML and Accessibility in ASP.NET Whidbey

Folks on my team setup a good set of reviews for me last Friday to go over our final plans on Accessibility and XHTML compliance for ASP.NET Whidbey.  I left the meetings feeling really good about where we'll end up when Whidbey ships.

XHTML Compliance

I've been pushing my team hard over the last few months to come up with a plan whereby we can definitely say that all output generated by the built-in ASP.NET Server Controls is XHTML (and HTML 4.01) compliant by default. 

Identifying all of the various XHTML rules (and the varying levels of support: XHTML 1.0, 1.1 and strict/transitional) and how these impacted our controls took some time.  Thankfully we had the help of Stephen Walther (www.aspworkshops.com), who did a great job working with us part-time to come up with a detailed list of issues with our current markup implementations, and in identifying a list of changes necessary to support it. 

At our meeting on Friday we signed off on making the appropriate code changes.  We spent some time debating the level of XHTML we'd end up supporting (I confess I went into the meeting ready to push only for XHTML 1.0 support).  In the end we walked away though with a plan that will enable us to output XHTML 1.1 by default. 

There are about 15 or so classes of changes we need to make throughout the framework.  The most interesting/unususal is the requirement to wrap our hidden viewstate tags within a hidden div -- since hidden inputs are apparently no longer allowed immediately under a tag.  The good news is that we have time on our schedule to get all of these done in the next few weeks before our final feature milestone ends. 

We'll also have appropriate device specific adaptation in place for our server controls, so that if a page gets hit with an older non-XHTML friendly browser (for example: one that barfs on xhtml conventions) -- we'll be able to optionally render markup that works around its short-comings while still maintaining visual fidelity on the page (giving us a great compatibility story).

To compliment these runtime changes, we are also adding support inside Visual Studio to better validate XHTML markup for static elements.  Some of this work is already in the VS Whidbey Alpha (you can change the target schema to XHTML Transitional or Strict).  We'll then provide realtime intellisense (red squigglies and task list errors) everytime you try to author non-XHTML compliant markup on the page (along with friendly error messages that help identify how to fix it).  Below is a screen-shot of what this looks like on a recent build:

In the meeting Friday we also decided to provide new “Add Item” templates that enable developers to add pages to their applications with an XHTML namespace and DOCTYPE value set (we'll probably have this be a drop-down on the new item dialog to enable devs to easily pick between the different standards when adding either dynamic or static pages to their sites).

Accessibility Compliance

Accessibility compliance is another key feature (and now a requirement for all goverment work) that I've been pushing the team on to make sure we'll be able say “just works” out of the box. 

In Whidbey, all ASP.NET Server Control will now generate Section 508 compliant markup by default, no coding or config changes required to enable it.

Our controls will also support automatically emitting WCAG compliant markup as well.  The one issue with making WCAG output the default is the requirement that WCAG has for the site to work without client-scripting.  Some of our controls use client-side script for up-level browsers (while optionally emitting script-less downlevel versions for older browsers).  Rather than disable script support by default for all browsers, we'll have a WCAG option you can set at either the page or site level which will enable users to turn off uplevel client scripting for accessibility compliance reasons. 

To further help developers check compliance on a site, we have also built-in a compliance checking tool into Visual Studio that can automatically validate for both 508 and WCAG (level 1 and 2) compliance within a web site.  This can be run either manually, or configured to run automatically as part of the Solution Build and/or F5 process.  The accessibility checker will verify both static html markup, as well as attributes on ASP.NET Server Controls (for example: if you use an control both don't specify an “AlternateText“ property).  Below is a screen-shot of it working in a recent build:

Hopefully the net result of both the XHTML and Accessibility work will be a platform and tool that enables web developers to build accessible, standards compliant, web applications easier than ever.

30 Comments

  • Top stuff! Every little helps. Not sure what relevance Section 508 has outside of the US though?



    Kevin

  • Valid and accessible markup. FANTASTIC! No more of the 'targetschema=Internet Explorer 5.0' nonsense, but developing for the standards.



    The more help you can give with developing accessible websites the better. I do my best and am aware of the issues and what I should be doing, but stuff always slips past me.

  • This is incredible news! I'm very glad to hear this is being given due attention. This was one of the issues that kept me from moving forward with ASP.Net. I of course moved forward, as the advantages of ASP.Net heavily outweighed the disadvantage of invalid markup, but it has always sat there in my head nagging me.



    So again, this is great! Thanks for the news!

  • I've been complaining about lack of (or even an attempt at) compliance with the XHTML standard in ASP.Net for years. When I first viewed server control output, I was wondering if there was some kind of anti-XHTML camp at Microsoft... it was so blatantly non-compliant. Is there a history to this lack of XHTML support in the original model? Anyway, better late than never (and what a joyous Thanksgiving gift for those of us without lives)...

  • WOW! This is definetly something what I have been waiting for Visual Studio. Is that "Section 508" covering W3c WAI or why it's not there?

  • Scott, XHTML, WCAG, XAML etc looks good, feels good but it would be really beneficial to have a "true" multi-lingual support not limiting to culture-aware globalization. This is a real time requirement in our projects wherein we opened a branch office in Canada and we're required by regulations to port our entire web-site to French. This is a tremendous undertaking for the IS team as there is no such support built into the framework that can address this requirement.

  • "hidden inputs are apparently no longer allowed immediately under a tag."



    By this, do you mean that hidden form fields are not allowed as direct children of form elements? It would be much easier to understand you if you used standard terminology.



    BTW, this requirement is not new at all - it's been present since 1997 (and even longer if you count proposed recommendations).



    By talking about XHTML 1.1 output by default, do you mean that you'll be serving it as text/html? That's against spec - the only XHTML you can serve as text/html is XHTML 1.0 that follows Appendix C.

  • Great news! Your work sounds like it will remove a constant daily frustration from working with Visual Studio and ASP.NET. The option not to rely on unnecessary client scripting is especially good.



    A couple of points though:



    Will the assumption for unknown browsers be changed to "uplevel"? This is important as the list of browsers which do not support XHTML is known, and is unlikely to grow significantly. However, new, compliant user agents arrive on the market all the time. The current "downlevel" assumption results in browsers like Mozilla Firebird, which is more standards compliant than the browsers identified as "uplevel", being served table layout. This is ludicrous.



    Secondly, please make sure that this new focus on standards extends throughout VS. The reason I say this is that a screenshot of the table dialogue on Microsoft.com shows support for deprecated attributes like "bgcolor", but no sign of required attributes and elements like "summary" and "caption". I wrote to MS and they've logged a job to redesign that dialogue, but how many others in VS have similar issues?

  • I've heard of several Portal deals that wouldn't go through unless the vendor was 508 compliant. I spent weeks researching 3rd party controls, and only found one that was 508 compliant.



    It might not be used much outside of government, but it should keep MS at the top of the pact competing against WSAS.

  • I'm quite curious about your plan to support XHTML 1.1 *by default*. Since 1.1 requires pages to be served as application/xhtml+xml (instead of the well-known text/html), and IE does not grok application/xhtml+xml, does this mean that an IE revamp is on the way to support that MIME type (and all that implies, including not even attempting to render non-well-formed markup)?



    1.1 support quite a drastic change, and I'm wondering if the MIME type issues were even considered in this decision. It's a lot more than just a new DOCTYPE declaration and correspondingly valid "tags"...

  • Awesome! I like when the words "accessible" and "ASP.net" are in the same sentence.

    WOOT!

  • I beg you, *PLEASE* don't make it output XHTML 1.1 by default.



    No browser has full support for XHTML 1.1. You can't have 1.1-compliant image maps which work in IE. You will no doubt also end up sending 1.1 as text/html.



    That would be very, very bad for the Web. There is absolutely no point in going for 1.1, and a whole lot of reasons against it.

  • Much of the concern over 1.1 obviously has to do w/ the issue of the doctype sent by the server. As far as I know, the developer has control over how the doctype is sent through iis or httpmodules. Thus, one can send the appropriate doctype setting to the supporting clients.



    I'd personally love to hear some news concerning desired standards support from Internet Expolorer. I mean...don't you guys have lunch with these guys sometimes?

  • You're right, I misspoke. I should have said "MIME" type.



    Is this not just a matter of setting the Content-Type response header?

    Content-Type: application/xhtml+xml

    If so, this is trivial and can easily bet set up in IIS or can be programatically set per response ( after examining the user agent, perhaps ). This is a very common practice and is done when one sends pdfs, streams video, csv files, etc.

  • We won't automatically set a DOCTYPE or change the Mime type (note: I think the mime type is a recommendation as opposed to a requirement in the current XHTML spec).



    Both of these can be declaratively set in the .aspx (no code required -- you can set the contenttype using the page directive's contenttype attribute), and we'll have an XHTML template in the add new dialog that pre-sets this for you.



    This gives developers the flexibility of choosing to mark their pages as XHTML or not (up to them). The markup generated by the controls, though, will be XHTML compliant regardless -- while still working with all existing browsers.

  • Don't worry -- the html re-formatting feature/bug of VS.NET today goes away in the Whidbey timeframe. VS now no longer (EVER) reformats your html when you switch into design-view or change any content within it.

  • Don't worry -- the html re-formatting feature/bug of VS.NET today goes away in the Whidbey timeframe. VS now no longer (EVER) reformats your html when you switch into design-view or change any content within it.

  • This is great news, Scott! It's been such a struggle to properly format markup pages just to find later that VS.NET totally destroyed them. All of my friends-developers have been very frustrated with this "feature".

  • Hey Scott!



    Will the navigation links in the datagrid work without client-side JavaSript?



    Dwight.

  • Any plans to build in an implementation of Dave Ragett's HTML Tidy, to enable ASP.NET developers to convert their non-conforming HTML to XHTML at the push of a button?



    That would be a fantastic feature and would really help move Microsoft-based developers towards standards compliance.



    There is a COM implementation of Tidy available so it shouldn't be too much work to build a configuration dialog box etc. and add a menu option?

  • How about including an option in the new IDE to turn off Design view altogether?

  • I second the request to turn off design view.

  • Wonderful! I've been wanting to get into authoring ASP.NET in Visual Studio (having prior experience with Windows Forms applications) but have hesitated as I haven't thought that the markup would be particularly standards compliant. It looks like this is going to be addressed. Great job!!!

  • Would it be correct to say that ASP.NET apps written against 1.1 - if compiled to 2.0 - will become XHTML and web standards compliant ?

    That would be cool !

  • Assuming your static html is xhtml/accessible compiant with ASP.NET 1.1 today -- then upgrading to Whidbey would make you fully compliant.

  • So how is paging and sorting a DataGrid going to work without JavaScript? It could be handled by the QueryString, but that would mean the ViewState would have to be as well - rather than having the entire ViewState in the URL perhaps the SessionID would be passed and the ViewState stored on the server?

  • >We'll also have appropriate device specific

    >adaptation in place for our server controls,

    >so that if a page gets hit with an older

    >non-XHTML friendly browser (for example: one

    >that barfs on xhtml conventions) -- we'll be

    >able to optionally render markup that works

    >around its short-comings while still

    >maintaining visual fidelity on the page

    >(giving us a great compatibility story).



    Er, you mean Internet Explorer? XML

    declaration puts it in quirks mode? Can't

    handle correct content type?

  • I have a problem with "wrap our hidden viewstate tags within a hidden div". I have a css class that looks like: "div { padding: 10px 0;}".
    How do I get rid of the blank space that will be generated on the place where the hidden fields are located?
    thank you

  • Hi Paul,

    You could modify your CSS to exclude the we create by default immediately underneath the form tag.

    In general I'd probably recommend having as broad a CSS rule as the one you have above - since it will effect lots of content on the page. Can you instead have it apply to a CSS class only?

    Thanks,

    Scott

  • Can anyone tell me how I can run Asp.Net application in IE 7.0

Comments have been disabled for this content.