Line/element information not displayed

Well this is weird.

This at first looks like it is happening somewhere in the quail_api_problem generation process from the quail api module itself.
As the data is directly from the php quail library, I might be missing some step to properly handling the data with drupal.

In the quail_api.module file (in the function template_preprocess_quail_api_problem()), I am calling check_markup() against the code.
$variables['markup_format'] is getting passed to it from the theme function.

This points me back to node_accessibility.

What markup format have you using for the content type in question?

I will have to spend some more time snooping around to see how exactly I am passing the markup around between quail_api and node_accessibility.

I think I found the problem to be a logic mistake on my part.

In the quail_api module, I have the following code:

<?php
  if (!empty($variables['problem_data']['line'])) {
    $variables['problem_line'] = check_plain($variables['problem_data']['line']);

    if (isset($variables['problem_data']['element'])) {
      $variables['problem_description'] = check_markup($variables['problem_data']['element'], $variables['markup_format']);
    }
  }
?>

The problem here is that I was using the php function empty().
Based on the line number data from your debug output, the line number is 0.
The empty() function treats the numerical value of 0 as empty.

Which means the code does not get displayed..
The attached patch changes the !empty() calls in the said function into isset() calls.

Change the status to "Reviewed and tested by the community" if the attached patch fixes the problem.

#3: quail_api-issue_1401844-1.patch queued for re-testing.

The patch is against the 7.x-1.x-dev branch.
I have committed the attached patch, so you can use the development branch as the starting point for further patches.

I am starting to consider that the line number = 0 part of the issue may be a mysql bug.

I am wondering what the contents of the node_accessibility_problems table looks like in your database.
The line # is pulled directly from the quail php library and stored in the database such that validation does not have to repeatedly happen everytime the accessibility validation results are viewed.
If the line numbers are all 0, then that probably means the problem happens on INSERT/UPDATE or before it.
If the line numbers are not all 0, then that probably means the problems happens on SELECT or after pulling the data from the database.

I created a bare d7 server with only node_accessibility and its dependencies using a mysql database.
I was not able to reproduce the problem you mentioned in #4.

What validations method have you tried?
Does the problem happen in all of them?

Also, try re-installing the quail_api and node_accessibility modules.
Perhaps the switching from 7.x-alpha1 to 7.x-dev may have caused some weird glitch.

This just seems to get harder and harder to figure out whats wrong.

Which of the following are you using?
- "Immediately validate"
- "Manually Validate"
- "Immediately Validate & Save"
- "Manually Validate & Save"

What concerns me is that the "Save" choices above are the ones that save to the database.
If the others are being used, then the database would be empty.
If you are using the non-save ones, then we can rule out any sort of SQL/database issues and focus on whats left.

Okay, I doubt this information will help me, but I might as well ask.
What OS are you using?
What php version are you using?
What mysql version are you using?
What version of drupal are you using?
Are any other modules other than core modules and node accessibility dependencies enabled?
If so, what are they?

One thing I could do is make a custom patch that logs a lot of the information where I could guess the problems might occur.
If I do that, I could then ask for a watchdog log dump...that sounds like something I should write and add to my cf module.
It would be very handy to dump specific parts of the watchdog to an export file of some sort.

I shall do that, I haven't been able to get back to this issue this week, but I should be able to to either this weekend or early next week.

Here is the debug patch.

For some reason the 7.x-1.x-dev release is a couple of commits behind and it never regenerated it.
Here is a patch that you can try, it does fix A problem with the total test failures being reported but I have doubts that it is THE problem you are having.

With any luck this patch solves your problem.

After review everything I am getting from this bug report states that (after the bugs where fixed in 7.x-1.x), the line #0 is exactly what the quail library is reporting.
This points to a potential bug in quail library.

However, I am entertaining the idea that how the data is being sent to quail library could be part of the problem.
The current approach is to take the renderred output and scan that so that after all modules and theme hooks do their thing the content that gets validated is not what is written by the node author but instead what the end-user will see.

With that in mind, what I believe may be happening is that the renderred output is producing output in such a way that confuses the quail library.

Of particular note is that the code printed in the debug statements is incomplete. The closing tags are missing!
This could be an issue in how the quail library returns the data.
There is a known issue where quail library strips out all of the html markup when providing data about a table, making their output example completely useless in my opinion.

I am also curious as to the line numbering system you are hoping to get results from.
I am surprised this did not occur to me until now, but perhaps the line number in the code/editor area is what you are looking for, but the renderred output is what gets scanned.

What this all means is that I think the remaining problem is with quail library and not with either of my projects.
This also means that the logic in handling the quail library could be improved, somehow.

I intent to close this as fixed because there were problems fixed and then I suggest you open a feature request in the node accessibility module for improving the interpretation of the scanned data and the resulting reports.
In particular, the feature request could include giving the option to do a pre-scan as opposed to a post-scan of the data.
The post scan is what is currently in use as that scans the renderred output.
A pre scan would happen before the content gets renderred and so line numbering would be correct according to the typed in the body field of a given node. The pre-scan would be less accurate but could cover individual fields.