Can anybody give us some clues?
I've been working with Moodle now for 4 years (I work for Kineo and am good mates with Mark Aberdour who used to be my boss) and I am really interested in gathering best practice on how to make Moodle accessable.
I'm also nearly at the end of a MSC with City University, London in Human Centred Systems - which has featured modules on accessability and evaluation.
I'd really like to get involved in any work going on in the Moodle community regarding accessability so if you need any help with these issues this let me know. I am not a developer but can test or offer advice.
Thanks for your support. We're deciding how to report that, maybe we'll work on it for 2.6 so in the next weeks we will report some of the issues, If you like, we can add you as a watcher for that issues.
Your original idea of one main ticket with sub tasks is what we did with our commissioned accessibility review by Deque: https://moodle.org/mod/forum/discuss.php?d=226761
It works well if all of the sub tasks are related to one overall review. As we found more issues that were outside the original review we opened up separate tickets.
I would recommend performing the review and documenting all issues then creating the overall ticket with sub tasks based on areas of work. The easiest thing is to group like items into one subtask if the patch you are providing affects a single plugin. I would avoid tickets across multiple plugins unless they will save a reviewer time.
We also standardized a ticket format for our accessibility tickets.
Description of the issue.
What is the WCAG standard not being met, and link to documentation about the standard and/or its resolution
WCAG 2 (A) 
What is the WCAG severity of the issue
Link to a specific Moodle instance where another developer can see the issue.
Steps to reproduce or test the issue. These might be better places in the testing steps of the ticket not in the description.
This format seemed to work well to communicate the issue and focus on where a developer can read about how to resolve the issue. We were not supplying patches however. It was also useful because it may take developers time to review the patch so having all the logic for the fix really helps after a long period of not working with the issue.
I would say it would be really useful to educate others, myself for one, on the resolution of each issue. Providing the logic for how to fix the issue will help to avoid the issue in future development. Also I would say like Damyon's post Tim mentioned if you see a repetitive issue you may want to make a new policy ticket to discuss the proper development practice that should be followed going forward.