Here is my first attempt at converting Accessible Content to drupal 7. It is quite far from being usable, there are a lot of things that were not caught by the coder module and were not caught by me. As it is right now, this module does not work.

There are so many changes in how drupal 7 works in regards to the things this module is doing that I am considering using this as a guide to start writing a simpler version of this module from the ground up.

CommentFileSizeAuthor
#15 Screenshot - 092211 - 14:32:58.png101.05 KBthekevinday
#15 Screenshot - 092211 - 14:33:28.png194.08 KBthekevinday
#15 Screenshot - 092211 - 14:34:23.png80.07 KBthekevinday
#15 Screenshot - 092211 - 14:35:24.png55.95 KBthekevinday
accessible_content-d7_proposal-1.tar_.gz100.31 KBthekevinday

Comments

johnbarclay’s picture

johnbarclay commented

Thanks. looking good. Let me know if I can help at all. I work on the accessible module. I've done a lot of drupal 7 coding over the last year and upgraded several modules. This weekend, I'm looking at some simpletests for drupal core for drupal 8 and getting the drupal 7 accessible helper module (project/accessible) up to speed. Do you have any interest in moving some of the quail stuff into the accessible_api module? I need the quail code for some tests and hate to see it in more than one place. Likewise I could make accessible require this module if this module was divided up into accessible_quail and accessible_content modules.

Anonymous’s picture

Anonymous (not verified) commented

Thanks for this, lots of projects have taken me away from my issue queue, but I'm back and have a few thoughts:

First, QUAIL is getting a big rewrite: when the project started, PHP's DOMDocument was the only thing available for document manipulation, but it was kinda like doing JavaScript in 1998 all over again. The PHPQuery project has since matured quite a bit and QUAIL is moving all of the tests to PHPQuery to improve code quality and scalability.

The other big part of this effort is native integration with SimpleTest - so developers can get immediate feedback on severe accessbility errors rolled into the standard unit testing process.

All that being said, I think the D7 port should be split into the following:

1. A generalized API module that maintains guidelines and tests as their own entities. This could be used by other modules like Accessible Helper to access QUAIL.
2. A much smaller module for end-user UI that would just use a node_view version of the page - the regular test view we have now is not very helpful as it goes with the pre-filtered content, while many problems or solutions can be included after the filter process is complete.

thekevinday’s picture

thekevinday commented

It seems I was working in a similar manner as kevee.
I was in the middle of re-writing this, but I had to stop and focus on a few other things first.

I made a sandbox (http://drupal.org/sandbox/thekevinday/1107936) so I don't have to constantly submit patches.
The code is incomplete at this time and does have stale files, but I thought I should show you what I have done already before you get started on doing similar things.

johnbarclay’s picture

johnbarclay commented

It would be greate to have quail broken out with an api. I would think a good structure for all the accessibility modules might be:

tool and guideline specific apis

  • quail
  • guidelines (a container for all the guidelines with hooks for modules that provide their own)
  • accessible preferences (where admins select preferences that transcend individual modules such as guidelines sets they want for authors and content viewers.
  • functional accessibility evaluator and other evaluation toolsets if anyone took an interest in them.

Modules themselves (use cases)

  • accessible content (authoring help)
  • accessible fix (overrides and fixes for contrib and core deficiencies)
  • accessible helper (contextual help for authors. may belong in accesible content)
  • core simpletests that are not dependent on other modules.

I think we should skype or irc and come up with a design for d7 so we can collaborate better. Are either of you going to the drupal 8 meeting Tuesday (http://groups.drupal.org/node/139154)?

thekevinday’s picture

thekevinday commented

I think we could break this into multiple-modules.
One being an API.
Should the submodules be separate projects?

I will be available in #drupal-accessiblity for discussion.
Just prefix "thekevinday:" to any messages there and I should be able to find them.
With any luck, we will both be on at the same time and can have an easier discussion.

bowersox’s picture

bowersox commented

Does the version posted here run and work in D7? Does it just need refactoring or need more work than that?

thekevinday’s picture

thekevinday commented

The version posted here should work as-is.
However, based on johnbarclay's comments and my own sandbox, a more flexible approach is needed.

Unfortunately, I am being side-tracked from this project at the moment.

mgifford’s picture

mgifford
he/him
Primary language English
commented

Kevin, have you put your D7 changes into git?

Would be good to test this out and be able to put out a D7 version.

thekevinday’s picture

thekevinday commented

The sandbox is here: http://drupal.org/sandbox/thekevinday/1107936, but I right before I got side-tracked I was in the process of making major structural changes with #4 in consideration. I could push my changes, but I don't think they would work as-is. I amy be getting some time very soon to pick up on this project again.

mgifford’s picture

mgifford
he/him
Primary language English
commented

The structure in #4 is very good. Hopefully we'll be able to get a push on a few of these contributed D7 modules to enhance accessibility.

I do think we need to be able to have modules to allow us to implement best practices in D7 in real sites that we can then bring into D8 as a default install.

I had proposed something like this last week:

0. API & core framework (no UI)
1. Basic, known enhancements - say ARIA
2. Advanced, experimental contrib/developer tools
3. Accessible content

The main thing though is getting code to work together & collaborating more effectively to produce more accessible sites.

thekevinday’s picture

thekevinday commented

Then perhaps accessible content should be broken up as suggested by #4:

Instead of writing a new "accessible_content" module, my work at http://drupal.org/sandbox/thekevinday/1107936 will be redone to only focus on the quail part.
I may even turn it into a real project called quail api.
If I just focus on doing quail api, then I should be able to get this out before I have get side-tracked again.

johnbarclay’s picture

johnbarclay commented

Yeah. I thing if you focus/finish on quail that will be more informative than anything. I'm focusing on drupal 7 functionality in the accessible helper module, ignoring integration with this module and the api design.

Some functional d7 code will go a long way towards informing any api, not to mention giving giving some useable modules to site developers.

In #10, I think the division between 1 and 2 should be in the user interface, not divided up in the code base. This will make development easier and keep the code base smaller.

1. Basic, known enhancements - say ARIA
2. Advanced, experimental contrib/developer tools

thekevinday’s picture

thekevinday commented

I have a very rough, but functional, rewrite now available at the url mentioned in #11.

The module is broken up into a core and two submodules.
The core provides the "api" if you will. It should be all that is needed to perform manual validation.

Now the two submodules are quail_api_field and quail_api_node.

I believe both are important to have, but could also conflict and cause performance issues.
(Such as enabling the field validator on a node body field).

The quail_api_field module is not complete.
I was not able to figure out how to do what I needed to do. Perhaps I am looking in all the wrong places, but you can read the comment added to the modules/quail_api_field/quail_api_field.module file.

The quail_api_node module has basic functionality finished and a lot of unused 'todo' parts.
It uses a per content type specific enable/disable options and the ability to select which standards to validate against.
For performance reasons, this only performs a test against the generated node content and not the entire html page. It is expected that the website theme use a different method of testing. (Perhaps a theme-specific validator submodule?)

While working on this module, I found the following problems with quail-lib:
- http://code.google.com/p/quail-lib/issues/detail?id=29
- http://code.google.com/p/quail-lib/issues/detail?id=30
- http://code.google.com/p/quail-lib/issues/detail?id=31
Could anybody else confirm these and their fixes?
Are there any other known problems with quail-lib?

mgifford’s picture

mgifford
he/him
Primary language English
commented

Hey Kevin, any progress on this over the summer?

thekevinday’s picture

thekevinday commented
StatusFileSize
new Screenshot - 092211 - 14:35:24.png55.95 KB
new Screenshot - 092211 - 14:34:23.png80.07 KB
new Screenshot - 092211 - 14:33:28.png194.08 KB
new Screenshot - 092211 - 14:32:58.png101.05 KB

Yes, and as a reminder you can checkout the sandbox here: https://drupal.org/sandbox/thekevinday/1107936

Some of this will be already mentioned here, but here is the latest condition of the code.
The module is broken up into two parts:
1) A library
- This drupal module acts as a wrapper for the 3rd-party quail project and provides the necessary hooks for any other module or script in drupal to use.
2) A node validator
- This drupal module provides a way to mass-validate nodes. It provides a few different ways to do this, one being rules integration.
- There are choices to store or not to store the validation results into the drupal database so it can be used for analytical reasons and performance reasons.

They are stored in the same project because that made it easy for me to setup, use, and learn what I needed to put in the library and what I should not put in the library. I now am certain that the qual library part should be separate and the node validator should be a different drupal project that depends on the quail api.

What I have left to do:
1) split quail_api_node from quail_api and create separate projects, then turn quail_api into a full blown project.
2) give other developers a chance to use, test, and feature request for the qual_api module
3) I have recently learned I was using rules module in a rather inefficient way in other projects of mine and I need to review that my rules functionality is done properly.
4) I have the quail_api and quail_api_node functioning on a production system. Doing this gave me a lot of test cases and revealed a lot of problems in both my project and the 3rd-party quail project
- The 3rd-party quail library under a lot of conditions doesn't properly validate its variables before operating on them, resulting in a lot of errors and warnings. I have made patches to fix or work-around the problems, but these patches are not applied upstream. (there are bug reports, but I got tired of posting a new report on each problem). I need to make a single lumped patch, submit it upstream and also make the patch available from the drupal project.
- The 3rd-party quail library does much more than what most of the web-based validators do. That is, it does context-specific validation. This bad side of this is that there are false positives. I have not but need to write an exception case handling api in the quail_api module.

The production system I was talking about is a drupal system whose content comes directly from thousands of pages of a 5 year or older website with all the old school (and very much not accessible) content. This means I have a decent list of false positives at my fingertips. To be able to deal with this I created a sort of hackish combination of views + quail_api + quail_api_node + rules + 3rd-part graphing api + a number of hand-written/hardcoded scripts. I have attached screenshots of this in action.

mgifford’s picture

mgifford
he/him
Primary language English
commented

That's great news! Looks like there's been a great deal of progress since the last time I looked at it.

thekevinday’s picture

thekevinday commented
Status: Active » Needs review

I have now moved the quail_api_node code into a separate project at https://drupal.org/project/1293724/git-instructions (currently a sandbox).

The quail api is now an official project at https://drupal.org/project/quail_api and should be sporting a 7.x-1.x development release for download as soon as one is generated by the drupal scripts.

The api needs the code to be reviewed.
If you want to test the functionality, download the quail_api_node from the sandbox link above.

If you don't want to use my quail_api_node sandbox module, then you are free to build a new version of "Accessible Content" that depends on the quail api module.

Anonymous’s picture

Anonymous (not verified) commented

All, thanks for all the great work on this, I realize that I've been a bad maintainer as we've completely inundated with several projects for a while now.

Something that keeps coming up in my mind is whether it would instead make sense to leverage thekevinday's work with QuailAPI along with the Content Analysis module to provide a unified UI. That would probably be the most scalable long-term solution.

We're still committed to QUAIL and would also like to do a port to jQuery as well for a browser-level accessibility checking. Accessible Content started as a small thing that became a huge pile of features rather quickly, and I think a re-do is in order to ensure it's more small and maintainable.

thekevinday’s picture

thekevinday commented

The reason why I have broken it apart into multiple projects is to do just that, while still allowing end-users to pick and choose what they want.

Quail Api is simply a library.
This should allow one to integrate it into their own projects without the risk of including other (potentially conflicting) functionality.

Quail Api Node is pretty much my interpretation of the node validation functionality provided here.
If you don't like it than you can use and build your own front-end without having to write a new API.
Of particular note, because the api has not been finalized, now is the time to see if it does everything you or anybody else needs it to do.

It would be ideal to have each significant feature be a separate module altogether.
Which then brings into question, should this project "Accessible Content" be a project that pulls existing accessibility functionality together via its own hooking api such that if somebody wants a new feature they write an extending module using the said hooks?

mgifford’s picture

mgifford
he/him
Primary language English
commented

Did the quail_api_node code get moved from the sandbox and get put somewhere else?

thekevinday’s picture

thekevinday commented

Yes. I decided to call it node_accessibility.

See: https://drupal.org/project/node_accessibility

mgifford’s picture

mgifford
he/him
Primary language English
commented

Given the recent changes with QUAIL (moving to jQuery), does this need to be updated? Do these modules all still work with https://github.com/kevee/quail

Anonymous’s picture

Anonymous (not verified) commented

QUAIL API is still using the older PHP version of QUAIL. I'm not trying to diminish the direction that module is going, but I think there's a need for a larger conversation around all these efforts.

Now that QUAIL has hit a stable state, and I've shifted focus to this module, I think we need to address several use cases. Accessible Content has always been about helping content editors create accessible experiences for their uses. That's why the focus has been on building checking into the editing experience, and providing instant feedback to those users. Also, since AC is something that goes through the Field API, not an entity like a node, it allows us to expand it to any entity.

I'm not saying that reporting is not important, but that's never been the focus of this specific module, and I don't think that it makes much sense for the community to have a single, monolithic module. So how about this:

1. QUAIL API module becomes a simple module that is a wrapper around QuailJS.
2. QUAIL API also do the heavy lifting of creating a custom entity type for tests (that way a user's setting for a test would be exposed to any module).
3. Accessible Content then provide the user feedback and UI for content creation.
4. Node Accessibility handle things like reporting.

I'm just tossing this idea out there. It might still make sense for AC to maintain it's own entities as it does now, but some coordinated effort or at least strict delegation of duties by the community would help prevent duplicate efforts. How about a discussion on g.d.o?

tinsmon’s picture

tinsmon commented

I was invited by kevee to chime in here because I posted in the Accessible Content issue queue asking about site-wide accessibility testing. Apparently there is no module that can test an entire site against an accessibility standard (say Section 508) and provide a comprehensive report to facilitate compliance. At least not for Drupal 6 which is what I'm still on.

Kevee mentioned the conversation here about where "reporting" should live. So, I thought I'd provide my perspective as a site administrator.

First off, the focus on individual node checking as created or edited only works if Accessible Content (or something similar) is enabled from the very beginning of site/node creation. In our case, we had a massive project to move from a static HTML site to Drupal. Our concerns were getting all content moved over and looking correct with our themes, etc. Most of the nodes were created by bulk import and there was no thought given to accessibility. So, now we have a big Drupal site and would like to bring it into compliance.

So, any tests that focus on specific content types, users, etc. are not going to be adequate or relevant to what we need. It seems to me that focusing on individual nodes or content types misses the larger point of accessibility testing/compliance: either your whole website is compliant or it's not. So, it seems to me, a module capable of testing an entire website is far more useful than one that can only test individual nodes or content types.

Also, I don't understand the logic of separating reporting from testing. What good is a test without a report of the test's results?

Just my $.02....

Still looking for some way to test my site.

Good luck with your work.

Mike

Anonymous’s picture

Anonymous (not verified) commented

Mike, thanks for your feedback.

I think there is definitely a different between real-time testing and reporting. If this module works as I intend, you will be able to prevent content from being posted if certain accessibility tests fail. For many organizations, reporting is an inefficient way of enforcing compliance.

While the entire website should be accessible, only certain parts of content are under the purview of the current user. What use is there to point out accessibility issues on the theme layer to a content editor with no access to solve the problem? We go on a field-by-field basis because many fields (i.e. integer, plain text) do not provide any capability for formatting, and therefore cannot be under the purview of automatic accessibility checking.

Since QUAIL is JavaScript, unless you use something like Phantom.JS, there is little space for doing reporting server-side, unless you have regular readers doing accessibility testing (which I have played with and it works very well) a-la Google Analytics, and then post those results for reporting.

So in short, I see a real difference between reporting (giving an overview of what issues exist site-wide) and feedback (giving feedback to users in the content creation process). I think both are important, but I wonder if both should exist within the same module. Speaking as a site owner myself with tens of thousands of nodes and hundreds of authors, reporting is relatively useless, but I find value in preventing accessibility problems from being published in the first place.

mgifford’s picture

mgifford
he/him
Primary language English
commented

We're looking at migrating possibly hundreds of thousands of pages with http://drupal.org/project/migrate into a fresh Drupal site. As part of the process, it would be great to flag new nodes that have known accessibility concerns so that we can send someone back to review them in more depth.

If that were done, it would be nice to simply have a View that allows you to organize the errors and prioritize them. Being able to crawl a site & highlight problems is something that I could see as being quite useful.

There might be some commonalities with http://drupal.org/project/readability

EDIT: And yes, discussing this on GDO sounds good too.

cb’s picture

cb
Location Sydney
commented

Mike, that sounds great and I think would be particularly useful for people in the same situation (ie, migrating lots of content.)

Will keep up with this and see where I can lend a hand (I dont have many hand-lending opportunities at the moment though unfortunately.)

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

I agree, there is definitely a use case for reporting, it just won't be as cut-and-dry a process with QUAIL now since it's not something which can run server-side in a normal Drupal environment.

Here's a few ideas on how a reporting feature could work:

1. For all content authors, when they view a page, QUAIL gets run and silently passes the results to the site for reporting. That way new pages or updates are always captured, as the author usually ends up viewing a page right after an edit.
2. Since tests are entities now, we could store results using the Relation module, or maintain our own data structure.
3. We could put together an interface for site maintainers to basically bulk-update content by loading it dynamically and walking through it (a-la our Qunit tests). That wouldn't be something I would suggest doing all the time, but could support bulk-updating.

I'm going to startI have started a discussion on GDO about what architecture the community would like to see for accessibility checking.