Wikka Accessibility


Attaining Accessibility conformance

WikkaWiki currently features valid XHTML 1.0 Transitional and valid CSS.
We should try to understand whether Wikka is compliant with any of the following Accessibility Conformance levels:

Level A conformance, 
	      W3C-WAI Web Content Accessibility Guidelines 1.0 Level Double-A conformance, 
	      W3C-WAI Web Content Accessibility Guidelines 1.0 Level Triple-A conformance, 
	      W3C-WAI Web Content Accessibility Guidelines 1.0

If it's already the case (which I doubt), we should add this accessibility conformance to the list of our features.
If it's not, we should try to see what changes are needed to attain the highest possible level.
--DarTar

How to get there

Thanks for bringing this up, DarTar.

No, it's not.

But any system that generates HTML based on end-user input would have a very hard time to attain full WCAG 1.0 AAA-level compliance for its output. The first requirement for accessibility is valid (X)HTML - but most HTML is generated based on Wikka markup: how do we ensure that results in valid XHTML? A simple nesting error in the Wikka markup could result in the same nesting error in XHTML. Worse, we allow people to embed HTML - how are we going to ensure the embedded HTML is valid (let alone conforms to the stated document type in the DOCTYPE declaration)? One option might be to run all code through HTMLtidy but even that has its limitations.

It would probably be better to distinguish between Wikka's user interface itself (or at least the default version out of the box) and how Wikka deals with user input to generate page content. Any system that generates HTML should not only conform to WCAG 1.0 (if the system is implemented in HTML) but also ATAG 1.0 (because any wiki - as well as any blog and any CMS - is an authoring tool). ATAG 1.0 has guidelines for the system's interface itself as well as for how an authoring tool takes care that it creates code that conforms to WCAG 1.0.

By distinguishing between the Wikka user interface itself (which should conform to WCAG) and how Wikka works as a code-authoring tool (which should conform to ATAG) it will actually be easier to evaluate where we are and to improve upon that.

Maybe a separate page listng each of the items in each of the two guidelines, together with where we stand for each of those, could help us attain as high a level of conformance as humanly possible.

There are conformance "buttons" for ATAG as well (I also fixed the alt text of these examples and made them into valid XHTML):
Level A conformance, 
	      W3C-WAI Authoring Tool Accessibility Guidelines 1.0 Level Double-A conformance, 
	      W3C-WAI Authoring Tool Accessibility Guidelines 1.0 Level Triple-A conformance icon, 
	      W3C-WAI Authoring Tool Accessibility Guidelines 1.0
--JavaWoman

References



CategoryDevelopmentDiscussion
Comments
Comment by NilsLindenberg
2005-04-25 19:29:02
I doubt that we reach even the lowest level while we have inline-images (Could be made an option).

And we shouldn't forget anyway that what is produced by users is not necessary valid and/or accessible (or does for example the formatter take care for nested formattings? Haven't tried).
Comment by DarTar
2005-04-26 06:56:10
I dont'think WAI-A forbids inline images per se, it forbids using images in place of proper markup and forbids non-accessible images (lacking alt attributes). But I still have to read the whole guidelines.
Comment by JavaWoman
2005-04-26 15:48:21
No - inline images are fine (and can actually help with accessibility). But we don't conform to level A because we *generate* alt texts for images which are (by definition) not meaningful. That means we should 1) not create an image link out of a "bare" URL and 2) require an alt attribute in the image action (though it may be an empty string for a purely decorative image) - and generate an error message if the alt attribute is missing.
(As I've argued many times :))
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki