I am involved with the building of a site that requires that content creators have tools for both W3C validation and accessibility checking. The plan of action is to use this module as well as W3C Analyzer (http://drupal.org/project/w3canalyzer). Interestingly the W3C Analyzer takes advantage of the Content Analysis
(http://drupal.org/project/contentanalysis), a general API that handles functions common to content analysis while also providing a nice unified UI.

From a user's perspective, having your tool leverage Content Analysis would be positive as it would centralize the UI. It may also be helpful for you as a developer. Finally, it is my hope that by combining efforts the general Content Analysis API could be improved. For example, the W3C Validator does not have Views integration for reporting. It would be excellent to allow any analysis engine to expose their statistics to Views.

I realize that this is a large issue that touches on many areas. Overall, is this something that you would consider? (maybe if time/$ was not an option)

Comments

Anonymous’s picture

The content analysis module came around after this one, although I did take a look at it when it came out. There are a number of reasons why I don't think this would work, namely the accessibility of the modal ctools dialog it uses, as well as the fact that the API of content analysis doesn't support returning form elements so that the Accessible Content module can render the 'override' feature for accessibility reviewers to turn off specific errors.

That being said, perhaps the better approach would be to just implement the content analysis API as well within the Accessible Content module as an option for people who would like to use it. The calls are really easy, and the module already has a generic callback that could be wrapped in a helper function to expose to content analysis API. I'll keep this issue open to track progress.

Anonymous’s picture

Status: Active » Postponed

After a review of the content analysis API, it seems this should be supported in a sub-module. There's some significant overhead that can complicate the core code. Will add in dev, but not high priority unless start hearing others requesting it.

rickvug’s picture

Kevee - Thank you for taking the time to look into this. Having this added in dev would be greatly appreciated. To let you know, I'm presently part of a team working on a project that will leverage accessible content. We also have built W3C validation (separate from Content Analysis). In a future iteration we would like to unify the interfaces and functionality. The ideal situation for us would be for our work to flow back into contrib so we aren't stuck maintaining the code just for our own usage.

Anonymous’s picture

I've got a demo working; however, there are some issues with rolling in accessible content with Content Analysis that I'd like to outline.

First, the formatting is pretty rigid, and therefore I cannot do things like highlighted errors or code highlighting - only static reports.

Second, because of the way that content analysis works, I cannot have nested reports. So, for example, I can't break reports down to level 1: Severity level 2: test, level 3: errors - there are only error categories and reports.

Third, the very nature of the way Content Analysis works ignores the way Accessible Content structures content types and settings per content-type. Instead, we would have to provide a global guideline setting for just content analysis, and provide a different UX than what we typically provide.

Fourth, the very accessibility of they way content analysis works with ctools modal API would make the way this module works inaccessible. I've pledged to keep Accesible Content module as strictly adherent to ATAG as possible, and going the route of providing it within a ctools dialog (which gives an untitled iframe with no ARIA role) is a little problematic.

I'm open to discussing this further, but I think that this requires a longer discussion with the maintainers of content analysis first.