I'm trying to convince my employer to let us use the Microsoft ASP/AJAX toolkit since it simplifies the implementation of many controls. However they have rejected the idea on the grounds that it produces "AJAX code" which is not ADA compliant. However the same employer requires webpages to be written in ASP.NET Web Forms which, as far as I can tell from the source, is very very far from ADA compliance.

I am new to both web programming and ADA compliance.

My questions are:

  1. Do ASP.Net Web Forms actually produce ADA compliant HTML?
  2. Will the ASP/AJAX toolkit undermine the goal of ADA compliance?
  • 2
    I think you'd have a better chance at producing ADA compliant code with ASP.NET MVC than you will with ASP.NET, since you have finer control over the markup. Ryan Hayes is right, though; it's not ASP.NET or ASP.NET MVC per se that makes the HTML ADA compliant, but your choice of tools will have an effect on how easy or difficult it will be to produce such HTML. – Robert Harvey Oct 22 '12 at 16:53

ASP.Net webforms is just a web technology. Nothing inherent in it, or the code it generates, is ADA compliant. While it could be compliant, Microsoft makes no guarantee of that. At the end of the day, it's all just markup and up to the developer to ensure that it complies with ADA. The same goes for the control toolkit. AJAX code does mean there are more moving pieces, but there's nothing to say you can't write compliant code using it (it just could potentially make it more difficult).

This is from Microsoft's ASP.NET documentation:

ASP.NET controls are designed to be accessible by default. This means that they automatically render accessible HTML if possible, or they expose properties that you can set to make the pages accessible. For example, ASP.NET controls offer the following features to support accessibility by default:

  • Generate HTML that uses CSS for visual formatting.

  • Use tables to present data, not to arrange visual elements on a page.

  • Provide indications of table structure by marking header and footer rows.

  • Associate labels with the controls that they pertain to.

  • Generate client script that is device independent, such as client script that responds both to mouse clicks and to keyboard actions.

  • Specify tab index settings for input elements.

  • Provide a way to specify a text equivalent for any non-text element.

Some controls generate HTML based on templates for which you provide the HTML. In those cases you must manually configure the markup in the templates so that the generated HTML complies with accessibility guidelines.

There are some exceptional situations in which controls generate HTML that may not comply with accessibility standards. ASP.NET 4 includes many enhancements that eliminate most of the exceptions that existed in earlier versions of ASP.NET, or that provide alternatives to them. For more information, see What's New in ASP.NET 4 and Visual Web Developer.

The following sections present techniques for creating accessible Web pages that conform to each WCAG guideline by using Visual Studio and ASP.NET. For some guidelines, there are no considerations that are specific to ASP.NET. Therefore, sections devoted to those guidelines are omitted in this part of the topic.

  • 1
    Well, you can modify the markup so that the output of that markup is more compliant, like using divs instead of tables for example (I don't know much about ADA compliance, so that may be a bad example). You can't necessarily modify the asp code, like <asp:Textbox/> too much, but you can do things to modify the look/attributes/structure of the output. Does that help? – Ryan Hayes Oct 22 '12 at 15:39
  • 2
    I updated my answer to include MS's official response. So essentially, ASP.NET is compliant where possible, which sounds like most of everything you would do. The AJAX control toolkit, which I've used before, essentially just updates your page with nearly identical code, as if you were doing a postback (it just does it async). So, I would assume that whatever compliance is built into default ASP.NET, it would also be true for those same controls updating inside of an AJAX panel, with the exception that the AJAX panel itself may introduce markup that may cause a collision of some kind. – Ryan Hayes Oct 22 '12 at 16:10
  • 2
    @Justin984 You should leave it open indefinitely for the benefit of all, it is a good question :) – maple_shaft Oct 22 '12 at 16:44
  • 1
    @Justin984 you said I was under the impression that much/most of the markup generation in web forms was a black box, not controllable by the developer. every WebControl has an Override-able Render method so you could always modify the behavior by deriving from a given class. Additionally you can modify the HTTP output with an Http Handler or Http Module but you'd have to process the whole response. See the Overview – Conrad Frix Oct 22 '12 at 17:13
  • 1
    @maple_shaft I meant I would leave it open for a while before I give this answer the green checkmark, I won't delete the question or anything (if that's possible?) – ConditionRacer Oct 22 '12 at 18:47

In my limited research of ADA compliance, the problem with AJAX was how screen-readers handled it. If I recall, since screen-readers read the markup from the top-down they may not be able to respond to dynamic markup that is later injected into an HTML form via an AJAX call (or other dynamic change, for that matter). So if you have a DIV that you want to use as a popup or fill with dynamic content, if the screen-reader has already parsed it, it will not necessarily 're-parse' it after you dynamically change the contents. So your user may not know the form has changed. Different readers had different limitations, but I do remeber thinking strict ADA compliance really restricted the convenience of AJAX.

However, ASP.NET does not force you to use AJAX, so ADA requirements should not disqualify the use of ASP.NET in any way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.