Back in the early days of DotNetNuke (1.08 from memory), a community member came forward with the series of changes needed to make DotNetNuke ADA-508 compliant. These were merged into the codebase and for a couple of releases the core was fully compliant. Maintaining core compliance wasn't too difficult, as in those days the ability to change look and feel was relatively limited (you had to hack the files directly in most cases)
With version 2.0 and the introduction of the rich skinning architecture, this compliance slipped a little. Over time as the modules became more powerful, and the portal more complex, we became less compliant with common accessibility standards. Whilst it was possible for skin designers and developers to create and release compliant sites (e.g. this and this describe 2 recent efforts), DotNetNuke didn't necessarily make it as easy as we would like. As a portal framework our aim is always to provide you with as much rich functionality as we can out of the box, but not to impact your efforts to create websites and applications exactly as you intended.
This is an area we've been wanting to revisit, and recently I've been scoping out requirements for this, prior to it being added as an official roadmap item. Due to the degree of interest, I thought it best to blog briefly about it whilst the scope is finalised. I've done this in a series of Q&A points that hopefully address the main queries.
Q. Are you going to create a version of DotNetNuke that is ADA/WCAG/XHTML compliant?
A. Frequently accessibility standards, xhtml and css based skins are all lumped together as the same thing, but whilst theres a large degree of cross-over, they're not an exact match e.g. you can have a site that passes common accessibility criteria without being xhtml compliant. The key deliverable for this roadmap item is to try and ensure that out of the box DotNetNuke can pass common accessibility standards such as W3C WAI Level A, and ADA 508 (as this either is, or soon will be a legal requirement in many countries or for particular sites e.g. Government/Council sites). During this work, where possible efforts will be made to alter markup to be xhtml compliant, but Accessibility compliance will have priority.
Q. Will upgrading to this new version make my site look different?
A. No. One of the aims is to make this a non-breaking change with regards look and feel. In cases where we need to alter hardcoded values, we will add enhancements that default to the current values but allow the value to be overriden i.e. DotNetNuke has a fixed DOCTYPE on default.aspx. Altering this would effect look and feel, so we will add an enhancement to allow skin DOCTYPE to be altered e.g. through a skin level setting either on the ascx or in the skin.xml
Q. Will these changes be for both 3.x and 4.x.
A. Ideally yes. Sadly, asp.net 1.1 emitts invalid markup in many cases, making it much more difficult to create compliant sites (whereas asp.net 2.0 can emit xhtml), but we will try to update both code bases equally.
Q. What release are we likely to start seeing changes in?
A. They've already started in some cases e.g in 4.3 some of the uppercase HEAD and LINK tags were changed to using the asp.net 2.0 control equivalents (which emit valid html). There are a number of projects that will help with the efforts including the new menu provider that's xhtml compliant, as well as an official release of the xhtml compatible FCKeditor provider. The next release of DotNetNuke will be a stability release, expect to see most of the changes in a release after that.
Q. Will you be fixing the core modules too?
A. The modules are the responsibility of their own project teams, but we'll certainly be offering suggestions/advice/code fixes and encouraging them to incorporate them.
Q. Do you have a list of items potentially in scope?
A. The full scope hasn't been defined yet, but you can expect to see some of the following
- Utilising some of the accessibility support in asp.net
- adopting some of the recommendations from the MS guidelines
- removing any barriers for entry (e.g. hardcoded non-compliant html or replacing linkbuttons where possible with non-postback methods)
- addition of access keys at the page level and a way to easily expose a list of these to screen readers (e.g. via an ACCESSKEYS skinobject)